Καταστροφική. *Γιατί* θέλεις να χρησιμοποιήσεις REST και Json? Έχεις κάποιο *πραγματικό* θέμα που θέλεις να λύσεις ή άκουσες ότι το REST είναι καλή ιδέα ?
Αξίζει να διαβάσεις το Premature Scalability and the Root of All Evil του Dino Esposito για να δεις τους μπελάδες που αντιμετώπισαν κάποιοι που θεώρησαν καλό να βάλουν REST πάνω από τη βάση "γιατί είναι καλή ιδέα".
Στην ερώτηση τώρα:
Πρώτον, αυτό δεν είναι συγχρονισμός είναι αντιγραφή δεδομένων. Ο συγχρονισμός απαιτεί να ξέρεις τι είναι καινούριο, παλιό, αλλαγμένο ή *διαγραμμένο*. Πως θα καταλάβεις ότι πρέπει να σβήσεις κάτι αν απλά στέλνεις τις αλλαγμένες εγγραφές? Το πως θα μιλήσουν δύο serves μεταξύ τους είναι το 10% της δουλειάς
Δεύτερον, *ήδη* υπάρχουν μηχανισμοί για συγχρονισμό. Γιατί να εφεύρεις ένα νέο? Replication υπάρχει, sync frameworks υπάρχουν.
Τρίτον, η χρήση REST και JSon για επικοινωνία με τη βάση είναι τραγικά αναποτελεσματική:
- Τραγικά αργή καθώς μεταφέρεις 10άδες φορές περισσότερα δεδομένα από τα πραγματικά λόγω text serialization. Τα περί Load balancing είναι άκυρα, όπως περιγράφει και ο Esposito, καθώς η παρέμβαση HTTP, text, web servers μεταξύ των βάσεων εξαφανίζει όποιο όφελος θα μπορούσες να έχεις.
- Τραγικά ανακριβής, καθώς χάνεις κάθε έννοια τύπου δεδομένων. Τί πάει να πει "34.45" ? Είναι κείμενο, float, double, decimal? Μην πω για ημερομηνίες.
- Τραγική καθυστέρηση ακόμα και για λίγα δεδομένα, καθώς το κάθε roundtrip παίρνει σημαντικό χρόνο ενώ η μία και μόνο απαιτούμενη κλήση στη βάση για να σταλούν όλα τα δεδομένα θα μπορούσε να πάρει millisecond.
- Μηδενικό scalabitliy. Δεν μπορείς να μεταφέρεις ουσιαστικό όγκο δεδομένων με ένα PUT, και λόγω περιορισμών του ίδιου του HTTP αλλά και λόγω του εξωφρενικά μεγάλου χρόνου που θα κρατήσει η διαδικασία. Οι servers είναι φτιαγμένοι για να χειρίζονται μικρομεσαία requests που τελειώνουν γρήγορα, όχι θηρία των δεκάδων ή εκατοντάδων MB που μπλοκάρουν threads και μνήμη για πολλά λεπτά. Αναγκαστικά θα πρέπει να το σπάσεις σε πολλές διαφορετικές κλήσεις, το οποίο μετά δημιουργεί θέματα consistency.
- Εξαιρετικά εύθραυστο. Από τη στιγμή που θα αναγκαστείς να σπάσεις τα PUT, θα πρέπει να χειριστείς χαμένα PUT, να μαζέψεις όλα τα κομμάτια πριν κάνεις τις αλλαγές, να τα *αποθηκεύσεις* κάπου μέχρι να μαζευτούν όλα.
Αν έχεις έτοιμο όλο το μηχανισμό του synchronization, μπορείς να φτιάξεις ένα πακέτο με τις αλλαγές που θα πρέπει να στείλεις στον άλλο server για επεξεργασία, να το συμπιέσεις και να το στείλεις με το *κατάλληλο* πρωτόκολλο, το FTP, ή ακόμα και με HTTP. λαμβάνοντας υπόψη partial uploads, restarts κλπ. Αυτό όμως δεν μπορείς να το πεις REST σε καμία περίπτωση,
Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos