Επιτρέψτε μου να πω μια τεχνική ιστορία.
Πριν από πολλά χρόνια, ανέπτυζα μια εφαρμογή με ενσωματωμένες δυνατότητες συνεργασίας. Ήταν μια φιλική προς τον χρήστη πειραματική στοίβα που εκμεταλλεύτηκε πλήρως τις δυνατότητες του πρώιμου React και του CouchDB. Συγχρονίζει δεδομένα σε πραγματικό χρόνο μέσω JSON . Χρησιμοποιήθηκε εσωτερικά εντός της εταιρείας, αλλά η ευρεία εφαρμογή και οι δυνατότητές του σε άλλους τομείς ήταν σαφείς.
Ενώ προσπαθούσαμε να πουλήσουμε αυτήν την τεχνολογία σε πιθανούς πελάτες, συναντήσαμε ένα απροσδόκητο εμπόδιο. Στο βίντεο επίδειξης, η τεχνολογία μας φαινόταν και λειτούργησε τέλεια, χωρίς προβλήματα. Το βίντεο έδειξε πώς ακριβώς λειτουργεί και δεν μιμήθηκε τίποτα. Καταλήξαμε και κωδικοποιήσαμε ένα ρεαλιστικό σενάριο για τη χρήση του προγράμματος.
Στην πραγματικότητα, αυτό έγινε το πρόβλημα. Το demo μας λειτούργησε ακριβώς όπως όλοι οι άλλοι προσομοίωσαν τις εφαρμογές τους. Συγκεκριμένα, οι πληροφορίες μεταφέρονταν άμεσα από το Α στο Β, ακόμα κι αν ήταν μεγάλα αρχεία πολυμέσων. Μετά τη σύνδεση, κάθε χρήστης είδε νέες καταχωρήσεις. Χρησιμοποιώντας την εφαρμογή, διαφορετικοί χρήστες μπορούσαν να συνεργαστούν σαφώς για τα ίδια έργα, ακόμα κι αν η σύνδεση στο Διαδίκτυο είχε διακοπεί κάπου στο χωριό. Αυτό υπονοείται σιωπηρά σε οποιοδήποτε βίντεο προϊόντος που κόβεται στο After Effects.
Παρόλο που όλοι γνώριζαν σε τι χρησιμεύει το κουμπί Ανανέωση, κανείς δεν κατάλαβε πραγματικά ότι οι εφαρμογές ιστού που μας ζητούσαν να δημιουργήσουμε υπόκεινται συνήθως στους δικούς τους περιορισμούς. Και ότι αν δεν χρειάζονται πλέον, η εμπειρία χρήστη θα είναι εντελώς διαφορετική. Παρατήρησαν κυρίως ότι μπορούσαν να «κουβεντιάσουν» αφήνοντας σημειώσεις για τους ανθρώπους με τους οποίους μιλούσαν, γι' αυτό αναρωτήθηκαν πώς ήταν διαφορετικό από, για παράδειγμα, το Slack. Φτου!
Σχεδιασμός καθημερινών συγχρονισμών
Εάν έχετε εμπειρία στην ανάπτυξη λογισμικού, πρέπει να θυμάστε ότι οι περισσότεροι άνθρωποι δεν μπορούν απλώς να δουν μια εικόνα μιας διεπαφής και να καταλάβουν τι θα κάνει όταν αλληλεπιδρούν μαζί της. Για να μην αναφέρουμε τι συμβαίνει μέσα στο ίδιο το πρόγραμμα. Να το ξέρεις κουτί να συμβεί είναι σε μεγάλο βαθμό το αποτέλεσμα της γνώσης του τι δεν μπορεί να συμβεί και τι δεν πρέπει να συμβεί. Αυτό απαιτεί όχι μόνο τι κάνει το λογισμικό, αλλά και πώς τα επιμέρους μέρη του συντονίζονται και επικοινωνούν μεταξύ τους.
Ένα κλασικό παράδειγμα αυτού είναι ένας χρήστης που κοιτάζει επίμονα ένα spinner.gif, αναρωτιούνται πότε τελικά θα ολοκληρωθούν οι εργασίες. Ο προγραμματιστής θα είχε συνειδητοποιήσει ότι η διαδικασία μάλλον είχε κολλήσει και ότι το gif δεν θα εξαφανιζόταν ποτέ από την οθόνη. Αυτό το κινούμενο σχέδιο προσομοιώνει την εκτέλεση μιας εργασίας, αλλά δεν σχετίζεται με την κατάστασή της. Σε τέτοιες περιπτώσεις, ορισμένοι τεχνικοί αρέσκονται να κάνουν τα στραβά μάτια, έκπληκτοι από την έκταση της σύγχυσης των χρηστών. Ωστόσο, παρατηρήστε πόσοι από αυτούς δείχνουν προς το περιστρεφόμενο ρολόι και λένε ότι είναι στην πραγματικότητα ακίνητο;
Αυτή είναι η ουσία της αξίας σε πραγματικό χρόνο. Σήμερα, οι βάσεις δεδομένων σε πραγματικό χρόνο εξακολουθούν να χρησιμοποιούνται ελάχιστα και πολλοί άνθρωποι τις βλέπουν με καχυποψία. Οι περισσότερες από αυτές τις βάσεις δεδομένων κλίνουν σε μεγάλο βαθμό προς το στυλ NoSQL, γι' αυτό συνήθως χρησιμοποιούν λύσεις που βασίζονται σε Mongo, οι οποίες είναι καλύτερα να ξεχαστούν. Ωστόσο, για μένα αυτό σημαίνει να νιώθω άνετα να δουλεύω με το CouchDB, καθώς και να μαθαίνω να σχεδιάζω δομές τις οποίες μπορεί να γεμίσει με δεδομένα κάτι περισσότερο από γραφειοκράτης. Νομίζω ότι αξιοποιώ καλύτερα τον χρόνο μου.
Αλλά το πραγματικό θέμα αυτής της ανάρτησης είναι αυτό που χρησιμοποιώ σήμερα. Όχι από επιλογή, αλλά λόγω αδιάφορα και τυφλά εφαρμοζόμενων εταιρικών πολιτικών. Επομένως, θα παρέχω μια εντελώς δίκαιη και αμερόληπτη σύγκριση δύο στενά συνδεδεμένων προϊόντων βάσης δεδομένων Google σε πραγματικό χρόνο.
Και οι δύο έχουν τη λέξη Fire στα ονόματά τους. Ένα πράγμα θυμάμαι με αγάπη. Το δεύτερο πράγμα για μένα είναι ένας διαφορετικός τύπος φωτιάς. Δεν βιάζομαι να πω τα ονόματά τους, γιατί μόλις το πω, θα αντιμετωπίσουμε το πρώτο μεγάλο πρόβλημα: τα ονόματα.
Το πρώτο λέγεται Βάση δεδομένων σε πραγματικό χρόνο Firebaseκαι δεύτερον - Firebase Cloud Firestore. Και τα δύο είναι προϊόντα από Σουίτα Firebase Google. Τα API τους καλούνται αντίστοιχα firebase.database(…) и firebase.firestore(…).
Αυτό συνέβη επειδή Βάση δεδομένων σε πραγματικό χρόνο - είναι απλώς το πρωτότυπο Firebase πριν από την αγορά του από την Google το 2014. Τότε η Google αποφάσισε να δημιουργήσει ως παράλληλο προϊόν αντίγραφο Το Firebase βασίζεται σε εταιρεία μεγάλων δεδομένων και το ονόμασε Firestore με σύννεφο. Ελπίζω να μην έχετε μπερδευτεί ακόμα. Εάν εξακολουθείτε να είστε μπερδεμένοι, μην ανησυχείτε, εγώ ο ίδιος ξαναέγραψα αυτό το μέρος του άρθρου δέκα φορές.
Γιατί πρέπει να υποδείξεις Firebase στην ερώτηση Firebase και Firestore σε μια ερώτηση για το Firebase, τουλάχιστον για να καταλάβετε πριν από μερικά χρόνια στο Stack Overflow.
Αν υπήρχε ένα βραβείο για τη χειρότερη εμπειρία ονοματοδοσίας λογισμικού, αυτό θα ήταν σίγουρα ένας από τους υποψήφιους. Η απόσταση Hamming μεταξύ αυτών των ονομάτων είναι τόσο μικρή που μπερδεύει ακόμη και έμπειρους μηχανικούς των οποίων τα δάχτυλα πληκτρολογούν ένα όνομα ενώ τα κεφάλια τους σκέφτονται ένα άλλο. Αυτά είναι καλοπροαίρετα σχέδια που αποτυγχάνουν παταγωδώς. εκπλήρωσαν την προφητεία ότι η βάση δεδομένων θα έπαιρνε φωτιά. Και δεν αστειεύομαι καθόλου. Το άτομο που σκέφτηκε αυτό το σχέδιο ονομασίας προκάλεσε αίμα, ιδρώτα και δάκρυα.
Πύρρειος νίκη
Θα νόμιζε κανείς ότι το Firestor είναι αντικατάσταση Firebase, ο απόγονος της επόμενης γενιάς, αλλά αυτό θα ήταν παραπλανητικό. Το Firestore δεν είναι εγγυημένο ότι θα είναι κατάλληλος αντικαταστάτης του Firebase. Φαίνεται ότι κάποιος έκοψε όλα τα ενδιαφέροντα από αυτό και μπέρδεψε τα περισσότερα από τα υπόλοιπα με διάφορους τρόπους.
Ωστόσο, μια γρήγορη ματιά στα δύο προϊόντα μπορεί να σας μπερδέψει: φαίνεται να κάνουν το ίδιο πράγμα, μέσω βασικά των ίδιων API και ακόμη και στην ίδια περίοδο λειτουργίας βάσης δεδομένων. Οι διαφορές είναι λεπτές και αποκαλύπτονται μόνο με προσεκτική συγκριτική μελέτη εκτεταμένης τεκμηρίωσης. Ή όταν προσπαθείτε να μεταφέρετε κώδικα που λειτουργεί τέλεια στο Firebase, ώστε να λειτουργεί με το Firestore. Ακόμη και τότε, ανακαλύπτετε ότι η διεπαφή της βάσης δεδομένων ανάβει μόλις προσπαθήσετε να κάνετε drag and drop με το ποντίκι σε πραγματικό χρόνο. Επαναλαμβάνω, δεν αστειεύομαι.
Το πρόγραμμα-πελάτη Firebase είναι ευγενικό με την έννοια ότι αποθηκεύει τις αλλαγές και επαναλαμβάνει αυτόματα ενημερώσεις που δίνουν προτεραιότητα στην τελευταία λειτουργία εγγραφής. Ωστόσο, το Firestore έχει όριο 1 λειτουργίας εγγραφής ανά έγγραφο ανά χρήστη ανά δευτερόλεπτο και αυτό το όριο επιβάλλεται από τον διακομιστή. Όταν εργάζεστε με αυτό, εξαρτάται από εσάς να βρείτε έναν τρόπο να το αντιμετωπίσετε και να εφαρμόσετε έναν περιοριστή ρυθμού ενημέρωσης, ακόμη και όταν προσπαθείτε απλώς να δημιουργήσετε την εφαρμογή σας. Δηλαδή, το Firestore είναι μια βάση δεδομένων σε πραγματικό χρόνο χωρίς πελάτη σε πραγματικό χρόνο, η οποία μεταμφιέζεται σε μια βάση δεδομένων που χρησιμοποιεί ένα API.
Εδώ αρχίζουμε να βλέπουμε τα πρώτα σημάδια του λόγου ύπαρξης του Firestore. Μπορεί να κάνω λάθος, αλλά υποψιάζομαι ότι κάποιος υψηλόβαθμος στη διοίκηση της Google κοίταξε το Firebase μετά την αγορά και είπε απλώς: «Όχι, ω Θεέ μου, όχι. Αυτό είναι απαράδεκτο. Απλώς όχι υπό την ηγεσία μου».
Εμφανίστηκε από την κάμαρά του και είπε:
«Ένα μεγάλο έγγραφο JSON; Οχι. Θα χωρίσετε τα δεδομένα σε ξεχωριστά έγγραφα, καθένα από τα οποία δεν θα έχει μέγεθος μεγαλύτερο από 1 megabyte."
Φαίνεται ότι ένας τέτοιος περιορισμός δεν θα επιβιώσει από την πρώτη συνάντηση με οποιαδήποτε βάση χρηστών με επαρκή κίνητρα. Ξέρεις ότι είναι. Στη δουλειά, για παράδειγμα, έχουμε περισσότερες από μιάμιση χιλιάδες παρουσιάσεις, και αυτό είναι εντελώς φυσιολογικό.
Με αυτόν τον περιορισμό, θα αναγκαστείτε να αποδεχτείτε το γεγονός ότι ένα "έγγραφο" στη βάση δεδομένων δεν θα μοιάζει με οποιοδήποτε αντικείμενο που ένας χρήστης μπορεί να αποκαλέσει έγγραφο.
"Πίνακες πινάκων που μπορούν να περιέχουν αναδρομικά άλλα στοιχεία; Οχι. Οι πίνακες θα περιέχουν μόνο αντικείμενα ή αριθμούς σταθερού μήκους, όπως ήθελε ο Θεός».
Επομένως, εάν ήλπιζα να βάλετε το GeoJSON στο Firestore σας, θα διαπιστώσετε ότι αυτό δεν είναι δυνατό. Τίποτα μη μονοδιάστατο δεν είναι αποδεκτό. Ελπίζω να σας αρέσει το Base64 και/ή το JSON εντός JSON.
«Εισαγωγή και εξαγωγή JSON μέσω HTTP, εργαλείων γραμμής εντολών ή πίνακα διαχείρισης; Οχι. Θα μπορείτε να εξάγετε και να εισάγετε δεδομένα μόνο στο Google Cloud Storage. Έτσι λέγεται τώρα, νομίζω. Και όταν λέω "εσείς", απευθύνομαι μόνο σε αυτούς που έχουν διαπιστευτήρια Ιδιοκτήτη Έργου. Όλοι οι άλλοι μπορούν να πάνε και να δημιουργήσουν εισιτήρια».
Όπως μπορείτε να δείτε, το μοντέλο δεδομένων FireBase είναι εύκολο να περιγραφεί. Περιέχει ένα τεράστιο έγγραφο JSON που συσχετίζει τα κλειδιά JSON με τις διαδρομές URL. Αν γράφεις με HTTP PUT в / Το FireBase είναι το εξής:
{
"hello": "world"
}
Αυτός GET /hello θα επιστρέψει "world". Βασικά λειτουργεί ακριβώς όπως θα περίμενες. Συλλογή αντικειμένων FireBase /my-collection/:id ισοδύναμο με ένα λεξικό JSON {"my-collection": {...}} στη ρίζα, τα περιεχόμενα της οποίας είναι διαθέσιμα στο /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Αυτό λειτουργεί καλά εάν κάθε ένθετο έχει ένα αναγνωριστικό χωρίς σύγκρουση, για το οποίο το σύστημα διαθέτει μια τυπική λύση.
Με άλλα λόγια, η βάση δεδομένων είναι 100% συμβατή με JSON(*) και λειτουργεί εξαιρετικά με HTTP, όπως το CouchDB. Αλλά βασικά το χρησιμοποιείτε μέσω ενός API σε πραγματικό χρόνο που αφαιρεί υποδοχές ιστού, εξουσιοδοτήσεις και συνδρομές. Ο πίνακας διαχείρισης έχει και τις δύο δυνατότητες, επιτρέποντας τόσο την επεξεργασία σε πραγματικό χρόνο όσο και την εισαγωγή/εξαγωγή JSON. Εάν κάνετε το ίδιο στον κώδικά σας, θα εκπλαγείτε με το πόσο εξειδικευμένος κώδικας θα σπαταληθεί όταν συνειδητοποιήσετε ότι η ενημέρωση κώδικα και η διαφορά JSON επιλύει το 90% των εργασιών ρουτίνας του χειρισμού της επίμονης κατάστασης.
Το μοντέλο δεδομένων Firestore είναι παρόμοιο με το JSON, αλλά διαφέρει με ορισμένους κρίσιμους τρόπους. Ανέφερα ήδη την έλλειψη συστοιχιών μέσα σε πίνακες. Το μοντέλο για τις υποσυλλογές είναι να είναι έννοιες πρώτης κατηγορίας, ξεχωριστές από το έγγραφο JSON που τις περιέχει. Δεδομένου ότι δεν υπάρχει έτοιμη σειριοποίηση για αυτό, απαιτείται μια εξειδικευμένη διαδρομή κώδικα για την ανάκτηση και εγγραφή δεδομένων. Για να επεξεργαστείτε τις δικές σας συλλογές, πρέπει να γράψετε τα δικά σας σενάρια και εργαλεία. Ο πίνακας διαχείρισης σάς επιτρέπει να κάνετε μικρές αλλαγές μόνο ένα πεδίο κάθε φορά και δεν έχει δυνατότητες εισαγωγής/εξαγωγής.
Πήραν μια βάση δεδομένων NoSQL σε πραγματικό χρόνο και τη μετέτρεψαν σε μια αργή μη SQL με αυτόματη σύνδεση και μια ξεχωριστή στήλη χωρίς JSON. Κάτι σαν GraftQL.
Hot Java
Εάν το Firestore υποτίθεται ότι ήταν πιο αξιόπιστο και επεκτάσιμο, τότε η ειρωνεία είναι ότι ο μέσος προγραμματιστής θα καταλήξει σε μια λιγότερο αξιόπιστη λύση από την επιλογή του FireBase από το κουτί. Το είδος του λογισμικού που χρειάζεται ο Διαχειριστής της Βάσης Δεδομένων Grumpy απαιτεί ένα επίπεδο προσπάθειας και ταλέντου που είναι απλώς μη ρεαλιστικό για τη θέση στην οποία υποτίθεται ότι είναι καλό το προϊόν. Αυτό μοιάζει με το πώς ο καμβάς HTML5 δεν αντικαθιστά καθόλου το Flash εάν δεν υπάρχουν εργαλεία ανάπτυξης και πρόγραμμα αναπαραγωγής. Επιπλέον, το Firestore είναι βυθισμένο σε μια επιθυμία για καθαρότητα δεδομένων και στείρα επικύρωση που απλά δεν ευθυγραμμίζεται με τον τρόπο με τον οποίο ο μέσος επιχειρηματίας χρήστης λατρεύει να δουλεύει: για αυτόν όλα είναι προαιρετικά, γιατί μέχρι το τέλος όλα είναι ένα ντραφτ.
Το κύριο μειονέκτημα του FireBase είναι ότι ο πελάτης δημιουργήθηκε αρκετά χρόνια νωρίτερα από την εποχή του, πριν οι περισσότεροι προγραμματιστές ιστού μάθουν για το αμετάβλητο. Εξαιτίας αυτού, το FireBase υποθέτει ότι θα αλλάξετε τα δεδομένα και επομένως δεν εκμεταλλεύεται την αμετάβλητη κατάσταση που παρέχεται από τον χρήστη. Επιπλέον, δεν επαναχρησιμοποιεί τα δεδομένα στα στιγμιότυπα που μεταβιβάζει στον χρήστη, γεγονός που καθιστά τη διαφορά πολύ πιο δύσκολη. Για μεγάλα έγγραφα, ο μεταβλητός μηχανισμός συναλλαγής που βασίζεται στη διαφορά είναι απλώς ανεπαρκής. Παιδιά, έχουμε ήδη WeakMap σε JavaScript. Είναι άνετο.
Εάν δώσετε στα δεδομένα το επιθυμητό σχήμα και δεν κάνετε τα δέντρα πολύ ογκώδη, τότε αυτό το πρόβλημα μπορεί να παρακαμφθεί. Αλλά είμαι περίεργος εάν το FireBase θα ήταν πολύ πιο ενδιαφέρον εάν οι προγραμματιστές κυκλοφόρησαν ένα πολύ καλό API πελάτη που χρησιμοποιούσε το αμετάβλητο σε συνδυασμό με ορισμένες σοβαρές πρακτικές συμβουλές για το σχεδιασμό της βάσης δεδομένων. Αντίθετα, φαινόταν ότι προσπαθούσαν να διορθώσουν ό,τι δεν είχε σπάσει και αυτό το έκανε χειρότερο.
Δεν ξέρω όλη τη λογική πίσω από τη δημιουργία του Firestore. Η εικασία για τα κίνητρα που προκύπτουν μέσα στο μαύρο κουτί είναι επίσης μέρος της διασκέδασης. Αυτή η αντιπαράθεση δύο εξαιρετικά όμοιων αλλά ασύγκριτων βάσεων δεδομένων είναι αρκετά σπάνια. Είναι σαν να σκέφτηκε κάποιος: "Το Firebase είναι απλώς μια λειτουργία που μπορούμε να μιμηθούν στο Google Cloud", αλλά δεν έχει ακόμη ανακαλύψει την έννοια του προσδιορισμού των απαιτήσεων του πραγματικού κόσμου ή της δημιουργίας χρήσιμων λύσεων που πληρούν όλες αυτές τις απαιτήσεις. «Αφήστε τους προγραμματιστές να το σκεφτούν. Απλώς κάντε το UI όμορφο... Μπορείτε να προσθέσετε περισσότερη φωτιά;»
Καταλαβαίνω μερικά πράγματα σχετικά με τις δομές δεδομένων. Βλέπω σίγουρα την έννοια "τα πάντα σε ένα μεγάλο δέντρο JSON" ως μια προσπάθεια αφαίρεσης οποιασδήποτε έννοιας δομής μεγάλης κλίμακας από τη βάση δεδομένων. Το να περιμένουμε το λογισμικό να αντιμετωπίσει απλώς οποιοδήποτε αμφίβολο φράκταλ δομής δεδομένων είναι απλώς τρελό. Δεν χρειάζεται καν να φανταστώ πόσο άσχημα μπορεί να είναι τα πράγματα, έχω κάνει αυστηρούς ελέγχους κώδικα και Είδα πράγματα που εσείς οι άνθρωποι δεν ονειρευτήκατε ποτέ. Αλλά ξέρω επίσης πώς μοιάζουν οι καλές δομές, и . Μπορώ να φανταστώ έναν κόσμο όπου το Firestore θα φαινόταν λογικό και οι άνθρωποι που το δημιούργησαν θα πίστευαν ότι έκαναν καλή δουλειά. Δεν ζούμε όμως σε αυτόν τον κόσμο.
Η υποστήριξη ερωτημάτων του FireBase είναι ανεπαρκής για οποιοδήποτε πρότυπο και είναι πρακτικά ανύπαρκτη. Χρειάζεται σίγουρα βελτίωση ή τουλάχιστον αναθεώρηση. Αλλά το Firestore δεν είναι πολύ καλύτερο επειδή περιορίζεται στα ίδια μονοδιάστατα ευρετήρια που βρίσκονται στην απλή SQL. Εάν χρειάζεστε ερωτήματα που εκτελούν οι χρήστες σε χαοτικά δεδομένα, χρειάζεστε αναζήτηση πλήρους κειμένου, φίλτρα πολλαπλών εύρους και προσαρμοσμένη παραγγελία που καθορίζεται από τον χρήστη. Μετά από προσεκτικότερη επιθεώρηση, οι λειτουργίες της απλής SQL είναι πολύ περιορισμένες από μόνες τους. Επιπλέον, τα μόνα ερωτήματα SQL που μπορούν να εκτελέσουν οι άνθρωποι στην παραγωγή είναι τα γρήγορα ερωτήματα. Θα χρειαστείτε μια προσαρμοσμένη λύση ευρετηρίασης με προσεγμένες δομές δεδομένων. Για όλα τα άλλα, θα πρέπει τουλάχιστον να υπάρχει σταδιακή μείωση χάρτη ή κάτι παρόμοιο.
Εάν κάνετε αναζήτηση στα Έγγραφα Google για πληροφορίες σχετικά με αυτό, ελπίζουμε ότι θα σας οδηγήσουν σε κάτι όπως το BigTable και το BigQuery. Ωστόσο, όλες αυτές οι λύσεις συνοδεύονται από τόσο πυκνή ορολογία εταιρικών πωλήσεων που γρήγορα θα γυρίσετε πίσω και θα αρχίσετε να ψάχνετε για κάτι άλλο.
Το τελευταίο πράγμα που θέλετε με μια βάση δεδομένων σε πραγματικό χρόνο είναι κάτι που φτιάχνεται από και για άτομα με διοικητικές κλίμακες αμοιβών.
(*) Αυτό είναι ένα αστείο, δεν υπάρχει τέτοιο πράγμα .
Σχετικά με τα Δικαιώματα Διαφήμισης
Ψάχνω για έργα εντοπισμού σφαλμάτων, διακομιστή για ανάπτυξη και φιλοξενία; Είστε σίγουρα ο πελάτης μας 🙂 Η ημερήσια τιμολόγηση για διακομιστές διαφόρων διαμορφώσεων, οι άδειες anti-DDoS και Windows περιλαμβάνονται ήδη στην τιμή.
Πηγή: www.habr.com