Πάντα με ενδιέφερε πώς είναι δομημένο το Habr εκ των έσω, πώς δομείται η ροή εργασίας, πώς δομούνται οι επικοινωνίες, ποια πρότυπα χρησιμοποιούνται και πώς γενικά γράφεται ο κώδικας εδώ. Ευτυχώς, είχα μια τέτοια ευκαιρία, γιατί πρόσφατα έγινα μέλος της ομάδας habra. Χρησιμοποιώντας το παράδειγμα μιας μικρής ανακατασκευής της έκδοσης για κινητά, θα προσπαθήσω να απαντήσω στην ερώτηση: πώς είναι να εργάζεσαι εδώ στο μπροστινό μέρος. Στο πρόγραμμα: Node, Vue, Vuex και SSR με σάλτσα από σημειώσεις για προσωπική εμπειρία στο Habr.
Το πρώτο πράγμα που πρέπει να γνωρίζετε για την ομάδα ανάπτυξης είναι ότι είμαστε λίγοι. Δεν είναι αρκετό - αυτά είναι τρία μπροστινά, δύο πίσω και το τεχνικό προβάδισμα όλων των Habr - Baxley. Υπάρχει φυσικά και ένας δοκιμαστής, ένας σχεδιαστής, τρεις Vadim, μια θαυματουργή σκούπα, ένας ειδικός στο μάρκετινγκ και άλλοι Bumburum. Αλλά υπάρχουν μόνο έξι άμεσοι συνεισφέροντες στις πηγές του Habr. Αυτό είναι αρκετά σπάνιο - ένα έργο με κοινό πολλών εκατομμυρίων δολαρίων, το οποίο από έξω μοιάζει με μια γιγάντια επιχείρηση, στην πραγματικότητα μοιάζει περισσότερο με μια άνετη startup με την πιο επίπεδη οργανωτική δομή.
Όπως πολλές άλλες εταιρείες πληροφορικής, η Habr δηλώνει Agile ιδέες, πρακτικές CI και αυτό είναι όλο. Αλλά σύμφωνα με τα συναισθήματά μου, το Habr ως προϊόν αναπτύσσεται περισσότερο σε κύματα παρά συνεχώς. Έτσι, για πολλά σπριντ στη σειρά, κωδικοποιούμε επιμελώς κάτι, σχεδιάζουμε και επανασχεδιάζουμε, σπάμε κάτι και το διορθώνουμε, επιλύουμε εισιτήρια και δημιουργούμε νέα, πατάμε σε τσουγκράνα και πυροβολούμε τους εαυτούς μας στα πόδια, για να απελευθερώσουμε τελικά το χαρακτηριστικό στο παραγωγή. Και μετά έρχεται μια ορισμένη ηρεμία, μια περίοδος ανάπλασης, χρόνος να κάνουμε αυτό που βρίσκεται στο τεταρτημόριο «σημαντικό-όχι επείγον».
Είναι ακριβώς αυτό το σπριντ «εκτός σεζόν» που θα συζητηθεί παρακάτω. Αυτή τη φορά περιελάμβανε μια ανακατασκευή της έκδοσης για φορητές συσκευές του Habr. Σε γενικές γραμμές, η εταιρεία έχει μεγάλες ελπίδες για αυτό και στο μέλλον θα πρέπει να αντικαταστήσει ολόκληρο τον ζωολογικό κήπο των ενσαρκώσεων του Habr και να γίνει μια καθολική λύση cross-platform. Κάποτε θα υπάρξει προσαρμοστική διάταξη, PWA, λειτουργία εκτός σύνδεσης, προσαρμογή χρήστη και πολλά άλλα ενδιαφέροντα πράγματα.
Ας βάλουμε το καθήκον
Κάποτε, σε ένα συνηθισμένο stand-up, ένας από τους μπροστινούς μίλησε για προβλήματα στην αρχιτεκτονική του στοιχείου σχολίων της έκδοσης για κινητά. Με αυτό το σκεπτικό, οργανώσαμε μια μικρο-συνάντηση σε μορφή ομαδικής ψυχοθεραπείας. Όλοι εναλλάξ έλεγαν όπου πονούσε, κατέγραψαν τα πάντα στο χαρτί, συμπόνεσαν, καταλάβαιναν, μόνο που κανείς δεν χειροκροτούσε. Το αποτέλεσμα ήταν μια λίστα με 20 προβλήματα, τα οποία κατέστησαν σαφές ότι το κινητό Habr είχε ακόμα μια μακρά και ακανθώδη πορεία προς την επιτυχία.
Με απασχολούσε πρωτίστως η αποτελεσματικότητα της χρήσης των πόρων και αυτό που ονομάζεται ομαλή διεπαφή. Κάθε μέρα, στη διαδρομή σπίτι-εργασία-σπίτι, έβλεπα το παλιό μου τηλέφωνο να προσπαθεί απεγνωσμένα να εμφανίσει 20 τίτλους στη ροή. Έμοιαζε κάπως έτσι:
Διασύνδεση Mobile Habr πριν από την ανακατασκευή
Τι συμβαίνει εδώ? Εν ολίγοις, ο διακομιστής εξυπηρετούσε τη σελίδα HTML σε όλους με τον ίδιο τρόπο, ανεξάρτητα από το αν ο χρήστης ήταν συνδεδεμένος ή όχι. Στη συνέχεια, το πρόγραμμα-πελάτη JS φορτώνεται και ζητά ξανά τα απαραίτητα δεδομένα, αλλά προσαρμόζεται για εξουσιοδότηση. Δηλαδή, στην πραγματικότητα κάναμε την ίδια δουλειά δύο φορές. Η διεπαφή τρεμόπαιξε και ο χρήστης κατέβασε εκατοντάδες επιπλέον κιλομπάιτ. Αναλυτικά όλα έμοιαζαν ακόμα πιο ανατριχιαστικά.
Παλιό σχήμα SSR-CSR. Η εξουσιοδότηση είναι δυνατή μόνο στα στάδια C3 και C4, όταν το Node JS δεν είναι απασχολημένο με τη δημιουργία HTML και μπορεί να διαμεσολαβήσει αιτήματα στο API.
Η αρχιτεκτονική μας εκείνης της εποχής περιγράφηκε με μεγάλη ακρίβεια από έναν από τους χρήστες του Habr:
Η έκδοση για κινητά είναι χάλια. Το λέω όπως είναι. Ένας τρομερός συνδυασμός SSR και CSR.
Έπρεπε να το παραδεχτούμε, όσο λυπηρό κι αν ήταν.
Αξιολόγησα τις επιλογές, δημιούργησα ένα εισιτήριο στο Jira με μια περιγραφή στο επίπεδο "είναι κακό τώρα, κάνε το σωστά" και αποσυνέθεσα την εργασία με μεγάλες πινελιές:
- επαναχρησιμοποίηση δεδομένων,
- ελαχιστοποίηση του αριθμού των επαναλήψεων,
- εξάλειψη διπλών αιτημάτων,
- κάνουν τη διαδικασία φόρτωσης πιο προφανή.
Ας επαναχρησιμοποιήσουμε τα δεδομένα
Θεωρητικά, η απόδοση από την πλευρά του διακομιστή έχει σχεδιαστεί για να λύνει δύο προβλήματα: να μην υποφέρει από περιορισμούς στις μηχανές αναζήτησης όσον αφορά και βελτιώστε τη μέτρηση (αναπόφευκτα επιδεινώνεται ). Σε ένα κλασικό σενάριο που τελικά έτος (ακόμα στο Backbone.js), το SSR είναι η ίδια ισομορφική εφαρμογή JS που εκτελείται στο περιβάλλον Node. Ο διακομιστής απλώς στέλνει τη διάταξη που δημιουργείται ως απάντηση στο αίτημα. Στη συνέχεια, πραγματοποιείται επανυδάτωση στην πλευρά του πελάτη και, στη συνέχεια, όλα λειτουργούν χωρίς επαναφόρτωση σελίδων. Για το Habr, όπως και για πολλούς άλλους πόρους με περιεχόμενο κειμένου, η απόδοση διακομιστή είναι ένα κρίσιμο στοιχείο για τη δημιουργία φιλικών σχέσεων με τις μηχανές αναζήτησης.
Παρά το γεγονός ότι έχουν περάσει περισσότερα από έξι χρόνια από την έλευση της τεχνολογίας, και κατά τη διάρκεια αυτής της περιόδου πολύ νερό έχει πραγματικά πετάξει κάτω από τη γέφυρα στον κόσμο του front-end, για πολλούς προγραμματιστές αυτή η ιδέα εξακολουθεί να καλύπτεται από μυστικότητα. Δεν μείναμε στην άκρη και παρουσιάσαμε μια εφαρμογή Vue με υποστήριξη SSR στην παραγωγή, χάνοντας μια μικρή λεπτομέρεια: δεν στείλαμε την αρχική κατάσταση στον πελάτη.
Γιατί; Δεν υπάρχει ακριβής απάντηση σε αυτό το ερώτημα. Είτε δεν ήθελαν να αυξήσουν το μέγεθος της απόκρισης από τον διακομιστή, είτε λόγω πολλών άλλων αρχιτεκτονικών προβλημάτων, είτε απλά δεν απογειώθηκε. Με τον ένα ή τον άλλο τρόπο, η απόρριψη της κατάστασης και η επαναχρησιμοποίηση όλων όσων έκανε ο διακομιστής φαίνεται αρκετά κατάλληλη και χρήσιμη. Το έργο είναι στην πραγματικότητα ασήμαντο - στο περιβάλλον εκτέλεσης και το Vue το προσθέτει αυτόματα στη διάταξη που δημιουργείται ως καθολική μεταβλητή: window.__INITIAL_STATE__.
Ένα από τα προβλήματα που έχει προκύψει είναι η αδυναμία μετατροπής κυκλικών δομών σε JSON () επιλύθηκε με απλή αντικατάσταση τέτοιων κατασκευών με επίπεδες αντίστοιχες.
Επιπλέον, όταν ασχολείστε με περιεχόμενο UGC, θα πρέπει να θυμάστε ότι τα δεδομένα πρέπει να μετατραπούν σε οντότητες HTML για να μην σπάσουν το HTML. Για αυτούς τους σκοπούς χρησιμοποιούμε .
Ελαχιστοποίηση επανασχεδίων
Όπως μπορείτε να δείτε από το παραπάνω διάγραμμα, στην περίπτωσή μας, ένα στιγμιότυπο Node JS εκτελεί δύο λειτουργίες: SSR και "proxy" στο API, όπου λαμβάνει χώρα η εξουσιοδότηση χρήστη. Αυτή η περίσταση καθιστά αδύνατη την εξουσιοδότηση ενώ ο κώδικας JS εκτελείται στον διακομιστή, καθώς ο κόμβος είναι μονού νήματος και η συνάρτηση SSR είναι σύγχρονη. Δηλαδή, ο διακομιστής απλά δεν μπορεί να στείλει αιτήματα στον εαυτό του ενώ το callstack είναι απασχολημένο με κάτι. Αποδείχθηκε ότι ενημερώσαμε την κατάσταση, αλλά η διεπαφή δεν σταμάτησε να συσπάται, καθώς τα δεδομένα στον πελάτη έπρεπε να ενημερωθούν λαμβάνοντας υπόψη την περίοδο λειτουργίας χρήστη. Χρειάστηκε να μάθουμε την εφαρμογή μας να βάζει τα σωστά δεδομένα στην αρχική κατάσταση, λαμβάνοντας υπόψη τη σύνδεση του χρήστη.
Υπήρχαν μόνο δύο λύσεις στο πρόβλημα:
- να επισυνάψετε δεδομένα εξουσιοδότησης σε αιτήματα μεταξύ διακομιστών·
- χωρίστε τα επίπεδα Node JS σε δύο ξεχωριστές περιπτώσεις.
Η πρώτη λύση απαιτούσε τη χρήση καθολικών μεταβλητών στον διακομιστή και η δεύτερη επέκτεινε την προθεσμία για την ολοκλήρωση της εργασίας κατά τουλάχιστον ένα μήνα.
Πώς να κάνετε μια επιλογή; Το Habr συχνά κινείται κατά μήκος της διαδρομής της ελάχιστης αντίστασης. Ανεπίσημα, υπάρχει μια γενική επιθυμία να μειωθεί ο κύκλος από την ιδέα στο πρωτότυπο στο ελάχιστο. Το μοντέλο στάσης απέναντι στο προϊόν θυμίζει κάπως τα αξιώματα του booking.com, με τη μόνη διαφορά ότι η Habr λαμβάνει πολύ πιο σοβαρά υπόψη τα σχόλια των χρηστών και εμπιστεύεται εσάς, ως προγραμματιστή, να λαμβάνετε τέτοιες αποφάσεις.
Ακολουθώντας αυτή τη λογική και τη δική μου επιθυμία να λύσω γρήγορα το πρόβλημα, επέλεξα καθολικές μεταβλητές. Και, όπως συμβαίνει συχνά, πρέπει να πληρώσετε για αυτά αργά ή γρήγορα. Πληρώσαμε σχεδόν αμέσως: δουλέψαμε το Σαββατοκύριακο, ξεκαθαρίσαμε τις συνέπειες, γράψαμε και άρχισε να χωρίζει τον διακομιστή σε δύο μέρη. Το σφάλμα ήταν πολύ ανόητο και το σφάλμα που το αφορούσε δεν ήταν εύκολο να αναπαραχθεί. Και ναι, είναι κρίμα γι' αυτό, αλλά με τον έναν ή τον άλλον τρόπο, παραπατώντας και στεναχωρώντας, το PoC μου με καθολικές μεταβλητές παρ' όλα αυτά μπήκε στην παραγωγή και λειτουργεί αρκετά επιτυχημένα περιμένοντας τη μετάβαση σε μια νέα αρχιτεκτονική "δύο κόμβων". Αυτό ήταν ένα σημαντικό βήμα, γιατί επισήμως ο στόχος επιτεύχθηκε - η SSR έμαθε να παρέχει μια εντελώς έτοιμη προς χρήση σελίδα και η διεπαφή χρήστη έγινε πολύ πιο ήρεμη.
Διασύνδεση Mobile Habr μετά το πρώτο στάδιο της ανακατασκευής
Τελικά, η αρχιτεκτονική SSR-CSR της έκδοσης για κινητά οδηγεί σε αυτήν την εικόνα:
Κύκλωμα SSR-CSR «δύο κόμβων». Το Node JS API είναι πάντα έτοιμο για ασύγχρονη I/O και δεν μπλοκάρεται από τη συνάρτηση SSR, καθώς η τελευταία βρίσκεται σε ξεχωριστή παρουσία. Η αλυσίδα ερωτημάτων #3 δεν χρειάζεται.
Εξάλειψη διπλών αιτημάτων
Αφού έγιναν οι χειρισμοί, η αρχική απόδοση της σελίδας δεν προκαλούσε πλέον επιληψία. Αλλά η περαιτέρω χρήση του Habr σε λειτουργία SPA εξακολουθεί να προκαλεί σύγχυση.
Δεδομένου ότι η βάση της ροής χρήστη είναι οι μεταβάσεις της φόρμας λίστα άρθρων → άρθρο → σχόλια και αντίστροφα, ήταν σημαντικό να βελτιστοποιηθεί η κατανάλωση πόρων αυτής της αλυσίδας εξαρχής.
Η επιστροφή στη ροή ανάρτησης προκαλεί νέο αίτημα δεδομένων
Δεν χρειαζόταν να σκάψω βαθιά. Στην παραπάνω εκπομπή οθόνης, μπορείτε να δείτε ότι η εφαρμογή ζητά ξανά τη λίστα των άρθρων όταν σύρετε προς τα πίσω και κατά τη διάρκεια της αίτησης δεν βλέπουμε τα άρθρα, πράγμα που σημαίνει ότι τα προηγούμενα δεδομένα εξαφανίζονται κάπου. Φαίνεται ότι το στοιχείο λίστας άρθρων χρησιμοποιεί μια τοπική κατάσταση και τη χάνει κατά την καταστροφή. Στην πραγματικότητα, η εφαρμογή χρησιμοποιούσε μια παγκόσμια κατάσταση, αλλά η αρχιτεκτονική Vuex χτίστηκε κατά μέτωπο: οι μονάδες συνδέονται με σελίδες, οι οποίες με τη σειρά τους συνδέονται με διαδρομές. Επιπλέον, όλες οι ενότητες είναι "μιας χρήσης" - κάθε επόμενη επίσκεψη στη σελίδα ξαναέγραφε ολόκληρη την ενότητα:
ArticlesList: [
{ Article1 },
...
],
PageArticle: { ArticleFull1 },
Συνολικά, είχαμε μια ενότητα Λίστα άρθρων, το οποίο περιέχει αντικείμενα τύπου Άρθρο και ενότητα PageArticle, που ήταν μια εκτεταμένη έκδοση του αντικειμένου Άρθρο, περίπου Πλήρες άρθρο. Σε γενικές γραμμές, αυτή η υλοποίηση δεν φέρει τίποτα τρομερό από μόνη της - είναι πολύ απλή, θα μπορούσε να πει κανείς και αφελής, αλλά εξαιρετικά κατανοητή. Εάν επαναφέρετε τη μονάδα κάθε φορά που αλλάζετε τη διαδρομή, τότε μπορείτε ακόμη και να ζήσετε μαζί της. Ωστόσο, η μετακίνηση μεταξύ ροών άρθρων, για παράδειγμα /feed → /all, εγγυάται ότι θα πετάξει ό,τι σχετίζεται με την προσωπική τροφοδοσία, αφού έχουμε μόνο ένα Λίστα άρθρων, στο οποίο πρέπει να βάλετε νέα δεδομένα. Αυτό μας οδηγεί και πάλι σε επικάλυψη αιτημάτων.
Έχοντας συγκεντρώσει όλα όσα μπόρεσα να ανακαλύψω για το θέμα, διατύπωσα μια νέα κρατική δομή και την παρουσίασα στους συναδέλφους μου. Οι συζητήσεις ήταν μακρές, αλλά τελικά τα επιχειρήματα υπέρ υπερίσχυσαν των αμφιβολιών και άρχισα την εφαρμογή.
Η λογική μιας λύσης αποκαλύπτεται καλύτερα σε δύο βήματα. Πρώτα προσπαθούμε να αποσυνδέσουμε τη μονάδα Vuex από τις σελίδες και να συνδεθούμε απευθείας σε διαδρομές. Ναι, θα υπάρχουν λίγο περισσότερα δεδομένα στο κατάστημα, οι λήπτες θα γίνουν λίγο πιο σύνθετοι, αλλά δεν θα φορτώνουμε άρθρα δύο φορές. Για την έκδοση για κινητά, αυτό είναι ίσως το ισχυρότερο επιχείρημα. Θα μοιάζει κάπως έτσι:
ArticlesList: {
ROUTE_FEED: [
{ Article1 },
...
],
ROUTE_ALL: [
{ Article2 },
...
],
}
Τι γίνεται όμως αν οι λίστες άρθρων μπορούν να επικαλύπτονται μεταξύ πολλών διαδρομών και τι γίνεται αν θέλουμε να επαναχρησιμοποιήσουμε δεδομένα αντικειμένων Άρθρο για απόδοση της σελίδας ανάρτησης, μετατρέποντάς την σε Πλήρες άρθρο? Σε αυτήν την περίπτωση, θα ήταν πιο λογικό να χρησιμοποιήσετε μια τέτοια δομή:
ArticlesIds: {
ROUTE_FEED: [ '1', ... ],
ROUTE_ALL: [ '1', '2', ... ],
},
ArticlesList: {
'1': { Article1 },
'2': { Article2 },
...
}
Λίστα άρθρων εδώ είναι απλώς ένα είδος αποθήκης άρθρων. Όλα τα άρθρα που λήφθηκαν κατά τη διάρκεια της περιόδου λειτουργίας χρήστη. Τους αντιμετωπίζουμε με τη μέγιστη προσοχή, επειδή πρόκειται για κίνηση που μπορεί να έχει μεταφορτωθεί λόγω πόνου κάπου στο μετρό μεταξύ σταθμών και σίγουρα δεν θέλουμε να προκαλέσουμε ξανά αυτόν τον πόνο στον χρήστη αναγκάζοντάς τον να φορτώσει δεδομένα που έχει ήδη κατεβάσει. Ενα αντικείμενο Αναγνωριστικά άρθρων είναι απλώς μια συστοιχία αναγνωριστικών (σαν «δεσμοί») προς αντικείμενα Άρθρο. Αυτή η δομή σάς επιτρέπει να αποφύγετε την αντιγραφή δεδομένων που είναι κοινά σε διαδρομές και την επαναχρησιμοποίηση του αντικειμένου Άρθρο κατά την απόδοση μιας σελίδας ανάρτησης με τη συγχώνευση εκτεταμένων δεδομένων σε αυτήν.
Το αποτέλεσμα της λίστας των άρθρων έχει γίνει επίσης πιο διαφανές: το στοιχείο επαναλήπτη επαναλαμβάνει μέσω του πίνακα με αναγνωριστικά άρθρων και σχεδιάζει το στοιχείο teaser άρθρου, περνώντας το αναγνωριστικό ως στηρίγμα και το στοιχείο θυγατρικό, με τη σειρά του, ανακτά τα απαραίτητα δεδομένα από Λίστα άρθρων. Όταν μεταβείτε στη σελίδα δημοσίευσης, λαμβάνουμε την ήδη υπάρχουσα ημερομηνία από Λίστα άρθρων, κάνουμε ένα αίτημα λήψης των δεδομένων που λείπουν και απλά τα προσθέτουμε στο υπάρχον αντικείμενο.
Γιατί είναι καλύτερη αυτή η προσέγγιση; Όπως έγραψα παραπάνω, αυτή η προσέγγιση είναι πιο ήπια σε σχέση με τα δεδομένα λήψης και σας επιτρέπει να τα επαναχρησιμοποιήσετε. Αλλά εκτός από αυτό, ανοίγει το δρόμο σε μερικές νέες δυνατότητες που ταιριάζουν απόλυτα σε μια τέτοια αρχιτεκτονική. Για παράδειγμα, δημοσκόπηση και φόρτωση άρθρων στη ροή όπως εμφανίζονται. Μπορούμε απλά να βάλουμε τις πιο πρόσφατες αναρτήσεις σε έναν "αποθηκευτικό χώρο" Λίστα άρθρων, αποθηκεύστε μια ξεχωριστή λίστα με νέα αναγνωριστικά Αναγνωριστικά άρθρων και ειδοποιήστε τον χρήστη σχετικά. Όταν κάνουμε κλικ στο κουμπί "Εμφάνιση νέων δημοσιεύσεων", απλώς θα εισαγάγουμε νέα αναγνωριστικά στην αρχή του πίνακα της τρέχουσας λίστας άρθρων και όλα θα λειτουργήσουν σχεδόν μαγικά.
Κάνοντας τη λήψη πιο ευχάριστη
Το κερασάκι στην τούρτα της ανακατασκευής είναι η έννοια των σκελετών, που κάνει τη διαδικασία λήψης περιεχομένου σε ένα αργό Διαδίκτυο λίγο λιγότερο αηδιαστική. Δεν έγιναν συζητήσεις για αυτό το θέμα· η διαδρομή από την ιδέα στο πρωτότυπο κράτησε κυριολεκτικά δύο ώρες. Η σχεδίαση ουσιαστικά σχεδιάστηκε και διδάξαμε τα στοιχεία μας να αποδίδουν απλά μπλοκ div που μόλις τρεμοπαίζουν ενώ περιμένουμε δεδομένα. Υποκειμενικά, αυτή η προσέγγιση στη φόρτωση μειώνει στην πραγματικότητα την ποσότητα των ορμονών του στρες στο σώμα του χρήστη. Ο σκελετός μοιάζει με αυτό:
Habraloading
Αντανακλαστικός
Δουλεύω στο Habré εδώ και έξι μήνες και οι φίλοι μου εξακολουθούν να ρωτούν: καλά, πώς σου αρέσει εκεί; Εντάξει, άνετα - ναι. Υπάρχει όμως κάτι που κάνει αυτό το έργο διαφορετικό από άλλα. Δούλεψα σε ομάδες που ήταν εντελώς αδιάφορες για το προϊόν τους, δεν ήξεραν ή καταλάβαιναν ποιοι ήταν οι χρήστες τους. Εδώ όμως όλα είναι διαφορετικά. Εδώ νιώθεις υπεύθυνος για αυτό που κάνεις. Κατά τη διαδικασία ανάπτυξης μιας λειτουργίας, γίνεστε εν μέρει κάτοχός της, συμμετέχετε σε όλες τις συναντήσεις προϊόντων που σχετίζονται με τη λειτουργικότητά σας, κάνετε προτάσεις και παίρνετε αποφάσεις μόνοι σας. Το να φτιάξετε ένα προϊόν που χρησιμοποιείτε καθημερινά μόνοι σας είναι πολύ ωραίο, αλλά το να γράφετε κώδικα για άτομα που είναι πιθανώς καλύτεροι σε αυτό από εσάς είναι απλά ένα απίστευτο συναίσθημα (χωρίς σαρκασμό).
Μετά την κυκλοφορία όλων αυτών των αλλαγών, λάβαμε θετικά σχόλια και ήταν πολύ, πολύ ωραία. Είναι εμπνευσμένο. Ευχαριστώ! Γράψε περισσότερα.
Επιτρέψτε μου να σας υπενθυμίσω ότι μετά από καθολικές μεταβλητές αποφασίσαμε να αλλάξουμε την αρχιτεκτονική και να εκχωρήσουμε το επίπεδο διακομιστή μεσολάβησης σε ξεχωριστή παρουσία. Η αρχιτεκτονική "δύο κόμβων" έχει ήδη κυκλοφορήσει με τη μορφή δημόσιας δοκιμής beta. Τώρα οποιοσδήποτε μπορεί να μεταβεί σε αυτό και να μας βοηθήσει να κάνουμε το κινητό Habr καλύτερο. Αυτά για σήμερα. Θα χαρώ να απαντήσω σε όλες τις ερωτήσεις σας στα σχόλια.
Πηγή: www.habr.com