Η σύγχρονη στοίβα συναλλαγών

Οι βάσεις δεδομένων συναλλαγών είναι από καιρό το πιο κρίσιμο στοιχείο του σχεδιασμού εφαρμογών. Γιατί; Επειδή μια σταθερή βάση δεδομένων είναι γενικά το απόλυτο σημείο επιβολής της ορθότητας σε έναν ακατάστατο, κατανεμημένο κόσμο. Χωρίς αυτούς θα πληρώναμε υπερβολικά και θα υποχρεώναμε. Θα χάναμε αναβάτες που προσπαθούσαν να επιστρέψουν στο σπίτι από το αεροδρόμιο και θα χάναμε αντικείμενα στα καλάθια αγορών μας. Οι διαδικτυακοί μας λογαριασμοί θα χάνονταν, θα αντιγραφούν ή θα καταστραφούν και θα καθίστανται ανενεργοί. 

Στην πραγματικότητα, η βάση δεδομένων συναλλαγών (γενικά αποκαλούμενη OLTP — συντομογραφία για την ηλεκτρονική επεξεργασία συναλλαγών — βάση δεδομένων) ήταν τόσο κεντρική στην ανάπτυξη εφαρμογών που, με την πάροδο του χρόνου, κατανάλωνε όλο και περισσότερες λειτουργίες εφαρμογής. Ωστόσο, οι μικροϋπηρεσίες και άλλες σύγχρονες αρχιτεκτονικές εφαρμογών εισήγαγαν νέες πολυπλοκότητες στο σχεδιασμό εφαρμογών: Οι προγραμματιστές χρειάζονταν να διαχειρίζονται δεδομένα σε διαφορετικές υπηρεσίες και να διασφαλίζουν τη συνοχή μεταξύ τους, γεγονός που τους ανάγκασε να δημιουργήσουν σύνθετους μηχανισμούς συγχρονισμού και επεξεργασίας δεδομένων εσωτερικά. 

Και έτσι, ως κλάδος, παρατηρούμε αυξανόμενη συνειδητοποίηση ότι απαιτούνται εγγυήσεις συναλλαγών εκτός του παραδοσιακού μοντέλου. Βλέπουμε το εμφάνιση συστημάτων που επεκτείνουν ισχυρές εγγυήσεις συναλλαγών πέρα ​​από τη βάση δεδομένων, στις ίδιες τις κατανεμημένες εφαρμογές. 

Παρακολουθούμε αυτές τις λύσεις τα τελευταία χρόνια. Γενικά, προσπαθούν να επιτρέπουν τη διαχείριση συναλλαγών της κατάστασης σε μια μεγάλη κατανεμημένη εφαρμογή, χωρίς να δημιουργούν προκλήσεις κλιμάκωσης και ενώ παρέχουν ένα σύγχρονο περιβάλλον προγραμματισμού. 

Βρίσκουμε ότι αυτές οι λύσεις χωρίζονται χονδρικά σε δύο κατηγορίες. Μια κατηγορία είναι ενορχήστρωση ροής εργασιών. Αυτό ουσιαστικά εγγυάται ότι ένα μπλοκ κώδικα θα ολοκληρωθεί, ακόμη και σε περίπτωση αποτυχίας. Έτσι, μπορεί να χρησιμοποιηθεί για τον σκοπό της ντετερμινιστικής διαχείρισης μιας μηχανής κατανεμημένης κατάστασης χωρίς να αγχώνεται. Η δεύτερη κατηγορία είναι βάση δεδομένων + ροή εργασιών, το οποίο επεκτείνει τον παραδοσιακό σχεδιασμό της βάσης δεδομένων OLTP, επιτρέποντας την εκτέλεση αυθαίρετου κώδικα για τον ίδιο σκοπό. 

Αυτός είναι ακόμα ένας πολύ εκκολαπτόμενος τομέας και υπάρχει μεγάλη σύγχυση σχετικά με την ονοματολογία, το πώς χρησιμοποιείται κάθε εργαλείο στην πράξη και ποιος πρέπει να το χρησιμοποιεί. Για να σας βοηθήσουμε να κατανοήσουμε καλύτερα, ρωτήσαμε επαγγελματίες από κορυφαίους μηχανικούς οργανισμούς σχετικά με τη στοίβα συναλλαγών τους και πώς σκέφτονται τρεις βασικές έννοιες για τον φόρτο εργασίας συναλλαγών: κατάσταση εφαρμογής, επιχειρηματική λογική και επιχειρηματικά δεδομένα. 

Ωστόσο, πριν εξετάσετε αυτές τις νέες στοίβες, ακολουθεί μια γρήγορη ημιτεχνική παρέκκλιση για να κατανοήσουμε πώς φτάσαμε εδώ.

Συναλλαγές, εγγυήσεις και σύγχρονες εφαρμογές 

Η πολύ πρόχειρη εκδοχή είναι η εξής: Υπάρχει ένα σύνολο εργασιών — συναλλαγών — που είτε θέλετε να κάνετε όλες είτε καμία. Οτιδήποτε ενδιάμεσο (αν το έχει γίνει εν μέρει) θα καταλήξει σε διεφθαρμένη κατάσταση. Είναι δύσκολο να το εγγυηθεί κανείς οτιδήποτε σε ένα κατανεμημένο σύστημα, αλλά οι βάσεις δεδομένων το κάνουν καλά με τις συναλλαγές. Επομένως, ο ευκολότερος τρόπος για να χειριστείτε τις εγγυήσεις σε πολλά συστήματα είναι απλώς να κάνετε τις περισσότερες συναλλαγές και να αφήσετε τη βάση δεδομένων να τις χειριστεί.

Οι σύγχρονες εφαρμογές είναι μεγάλα κατανεμημένα συστήματα με πολλούς χρήστες να κάνουν πολλά πράγματα. Έτσι, ακόμη και η διατήρηση της κατάστασης της εφαρμογής συνεπής (όπως η παρακολούθηση των σημείων που βρίσκονται διαφορετικοί χρήστες σε μια ροή check-out) μετατρέπεται σε πρόβλημα κατανεμημένης συναλλαγής. Στις παραδοσιακές μονολιθικές αρχιτεκτονικές, η διαχείριση συναλλαγών χρησιμοποιώντας SQL με βάση δεδομένων OLTP ήταν κάπως αποτελεσματική. Αλλά στον νέο, πολύπλοκο κόσμο των μικροϋπηρεσιών που αλληλεπιδρούν μέσω API υψηλότερου επιπέδου (π.χ. REST ή gRPC), οι ανάγκες συναλλαγών έχουν κατανεμηθεί στη φύση. 

Ωστόσο, πολλές εταιρείες που πηγαίνουν στο ταξίδι προς τις μικροϋπηρεσίες δεν έχουν κάνει πολλά για να επεκτείνουν ισχυρές εγγυήσεις συναλλαγών πέρα ​​από τη βάση δεδομένων. Και, στην πράξη, αυτό είναι σχεδόν πάντα ΕΝΤΑΞΕΙ. Όμως, καθώς οι εφαρμογές κλιμακώνονται, οι ασυνέπειες στα δεδομένα αυξάνονται, όπως και τα σφάλματα που προκύπτουν και τα ασυμβίβαστα σφάλματα στα επιχειρηματικά δεδομένα. Κάτι που, φυσικά, μπορεί να είναι εξαιρετικά προβληματικό. Αυτό αναγκάζει τους προγραμματιστές εφαρμογών να αντιμετωπίσουν ένα ευρύ φάσμα σεναρίων αποτυχίας και στρατηγικών επίλυσης συγκρούσεων και να εξασφαλίσουν τη συνοχή της κατάστασης δημιουργώντας τις δικές τους στρατηγικές μέσω διαφορετικών αρχιτεκτονικών προτύπων.

Ορισμοί Δεδομένα επιχείρησης ("δεδομένα") αναφέρεται στα κρίσιμα για την επιχείρηση δεδομένα που παραδοσιακά αποθηκεύονται σε μια βάση δεδομένων OLTP για επιμονή και επεξεργασία (π.χ. πληροφορίες προφίλ χρήστη όπως όνομα, διεύθυνση, πιστωτική βαθμολογία κ.λπ.). Κατάσταση εφαρμογής αναφέρεται στην τρέχουσα κατάσταση του συστήματος· η κατάσταση της εφαρμογής καθορίζεται από μια τιμή που είναι αποθηκευμένη σε ένα σύστημα αποθήκευσης δεδομένων και ποιο βήμα είναι η εκτέλεση του προγράμματος σε μια μηχανή πεπερασμένης κατάστασης (π.χ. η κατάσταση μιας παραγγελίας, όπως "λήφθηκε η παραγγελία", "ελέγχθηκε το απόθεμα", "ελέγχθηκε η πίστωση" , "απεστάλη", "επιστράφηκε"). Επαγγελματική λογική αναφέρεται στο τμήμα του προγράμματος που ασχολείται με το πώς λειτουργεί πραγματικά η εφαρμογή ή τι κάνει, αντί για τις λεπτομέρειες εκτέλεσης (π.χ. «Εάν user_income > $100K & credit_score >650 ⇒ mortgage_approved = TRUE»).

Για τους σκοπούς αυτής της συζήτησης, είναι σημαντικό να γίνει διάκριση των δεδομένων κατάστασης εφαρμογής και επιχείρησης. Για παράδειγμα, το να γνωρίζεις ότι ένας πελάτης έχει εισαγάγει την πιστωτική του κάρτα αλλά δεν έχει κάνει check out αποτελεί κατάσταση αίτησης. Τα δεδομένα για την πιστωτική κάρτα και τα στοιχεία στο καλάθι της εφαρμογής είναι τα επιχειρηματικά δεδομένα. 

Σε μια τυπική ροή, ένα αίτημα προέρχεται από το front-end, επαληθεύεται και στη συνέχεια δρομολογείται μέσω μιας πύλης API ή GraphQL στο σχετικό τελικό σημείο. 

Αυτό το μεμονωμένο τελικό σημείο API πρέπει τώρα να ενορχηστρώσει δεκάδες ή εκατοντάδες μικροϋπηρεσίες για να παραδώσει την επιχειρηματική συναλλαγή στον τελικό πελάτη. Αυτό είναι όπου οι προγραμματιστές συνήθως συγκεντρώνουν τα πάντα σε κηλίδες επιχειρηματικής λογικής και, στη συνέχεια, χρησιμοποιούν έναν συνδυασμό ουρών, κρυφής μνήμης και χειροκίνητου κωδικοποιημένους μηχανισμούς επανάληψης δοκιμής για να μεταφέρουν τα δεδομένα στη βάση δεδομένων — ελπίζουμε να πραγματοποιηθεί ως πλήρης συναλλαγή.

Καθώς αυξάνεται η κλίμακα της εφαρμογής, αυξάνεται και η πολυπλοκότητα της διαχείρισης των ουρών και της κρυφής μνήμης, καθώς και ο αριθμός των αιχμηρών άκρων στη λογική συμφιλίωσης όταν προκύπτουν προβλήματα. 

Η άνοδος των στοίβων συναλλαγών με επίκεντρο τη ροή εργασίας και τη βάση δεδομένων

Εντάξει, επομένως οι συναλλαγές είναι σημαντικές. Η LAMP σε μια βάση δεδομένων δεν ήταν επαρκής για κλίμακα. Και μια γιγάντια τριχοφυΐα από ουρές και λογική επανάληψης είναι πολύ εύθραυστη. Για να αντιμετωπίσουμε αυτό, έχουμε δει, τα τελευταία χρόνια, την εμφάνιση νέων λύσεων που επαναφέρουν τη λογική στη συναλλακτική λογική. Μπορούν να κατηγοριοποιηθούν χονδρικά είτε ως προσεγγίσεις με επίκεντρο τη ροή εργασίας είτε ως προσεγγίσεις με επίκεντρο τη βάση δεδομένων.

Μέχρι σήμερα, οι μηχανές ροής εργασίας λειτουργούν κυρίως στην κατάσταση της εφαρμογής και όχι στα επιχειρηματικά δεδομένα και συχνά απαιτούν κάποια πολυπλοκότητα όταν ενσωματώνονται με παραδοσιακές βάσεις δεδομένων. Οι προσεγγίσεις με επίκεντρο τη βάση δεδομένων προσθέτουν τη λογική της εφαρμογής παράλληλα με τα επιχειρηματικά δεδομένα, αλλά δεν έχουν ακόμη την ίδια πολυπλοκότητα εκτέλεσης κώδικα με τους κινητήρες ροής εργασίας. 

Το παρακάτω διάγραμμα παρέχει μια πρόχειρη σκιαγράφηση του τρόπου με τον οποίο χρησιμοποιούνται προσεγγίσεις με επίκεντρο τη ροή εργασίας και/ή τη βάση δεδομένων σε μια εφαρμογή Javascript/Typescript, με την προϋπόθεση ότι χρησιμοποιούνται και οι δύο. Αν και είναι ξεχωριστά κομμάτια αυτής της αρχιτεκτονικής σήμερα, έχουμε δει πρώιμα σημάδια μιας τάσης όπου οι βάσεις δεδομένων ενσωματώνουν χαρακτηριστικά ροής εργασίας και οι ροές εργασίας αρχίζουν να υιοθετούν ανθεκτική αποθήκευση. Αυτή η συγχώνευση δυνατοτήτων δείχνει ότι οι γραμμές μεταξύ των δύο προσεγγίσεων θολώνουν και γίνονται λιγότερο διακριτές στις σύγχρονες αρχιτεκτονικές. 

Λεπτομερείς προσεγγίσεις με επίκεντρο τη ροή εργασίας 

Μια ροή εργασίας είναι απλώς μπλοκ κώδικα που εκτελούνται με βάση συμβάντα ή χρονόμετρα που εξελίσσουν τη μηχανή κατάστασης εφαρμογής. Η ροή εργασιών συναλλαγών διασφαλίζει την εκτέλεση κώδικα με ισχυρές εγγυήσεις, αποτρέποντας μερικές ή ακούσιες καταστάσεις στην εφαρμογή. Οι προγραμματιστές γράφουν τη λογική και η μηχανή ροής εργασιών χειρίζεται συναλλαγές, μεταλλάξεις και αδυναμία. Διαφορετικές μηχανές ροής εργασιών κάνουν διαφορετικούς συμβιβασμούς όσον αφορά το πόσο από τις λεπτομέρειες της συναλλαγής εκτίθενται στους προγραμματιστές. 

Για παράδειγμα, παρακάτω είναι μια οπτική αναπαράσταση μιας ροής εργασιών check-out που εκτελείται στο Orkes (Conductor): 

Υπάρχουν δύο σκληρές προσεγγίσεις με την οποία οι κινητήρες ροής εργασίας αποκτούν πρόσφυση. Σε ένα (που χαρακτηρίζεται από το Temporal.io), οι προγραμματιστές γράφουν κώδικα χρησιμοποιώντας τυπικές γλώσσες προγραμματισμού back-end (π.χ. Go ή Java) και το το σύστημα θα διασφαλίσει ότι ο κώδικας τρέχει μέχρι την ολοκλήρωση, ακόμα και σε περίπτωση αποτυχίας. Σε αυτό το μοντέλο, η στοίβα κλήσης προγράμματος διατηρείται ακόμη και αν ο κωδικός περιμένει να ολοκληρωθεί μια κλήση αποκλεισμού (π.χ. ανάγνωση ή εγγραφή). Για να γίνει αυτό, ο χρόνος εκτέλεσης της γλώσσας τροποποιείται για να αποτραπεί η μερική εκτέλεση κώδικα κατά τη διάρκεια αποτυχιών. Το πλεονέκτημα αυτής της προσέγγισης είναι ότι οι προγραμματιστές μπορούν να γράφουν σε γνωστές γλώσσες και να εντοπίζουν εύκολα σφάλματα με μια διατηρημένη στοίβα κλήσεων. Βλέπουμε αυτή την προσέγγιση πιο δημοφιλή σε ομάδες back-end που ασχολούνται με μεγάλες, εξελιγμένες εφαρμογές. 

Το μειονέκτημα είναι ότι συχνά απαιτεί πολλή εργασία ενοποίησης και κώδικα περιτυλίγματος για να εκτεθούν χρήσιμες και ασφαλείς διεπαφές στους προγραμματιστές εφαρμογών. Ένα άλλο μειονέκτημα είναι ότι βασίζεται σε ένα προσαρμοσμένο επίπεδο εκτέλεσης και όχι στη γυμνή γλώσσα, και υπάρχουν περιπτώσεις αιχμής όπου η εκτέλεση θα διαφέρει από τον χρόνο εκτέλεσης της μητρικής γλώσσας. Έτσι, ενώ οι προγραμματιστές μπορούν να χρησιμοποιούν γλώσσες με τις οποίες είναι εξοικειωμένες, πρέπει να καταλάβουν πώς λειτουργεί το υποκείμενο σύστημα.  

Η άλλη προσέγγιση, η οποία είναι πιο δημοφιλής στους προγραμματιστές εφαρμογών (ιδιαίτερα Typescript/Javascript) είναι η μηχανή ροής εργασιών να χρησιμεύει ως ενορχηστρωτής ασύγχρονων λειτουργιών (π.χ. Inngest, Defer και Trigger). Σε αυτό το μοντέλο, συμβάντα ή λειτουργίες τρίτων κατευθύνονται στη μηχανή ροής εργασιών, η οποία στη συνέχεια θα αποστείλει τη λογική που έχει καταχωριστεί από τους προγραμματιστές της εφαρμογής, οι οποίοι πρέπει να επιστρέψουν τον έλεγχο μόλις προκύψει η ανάγκη αποκλεισμού μιας άλλης συνάρτησης ασυγχρονισμού. Το θετικό είναι ότι αυτή είναι μια πολύ πιο ελαφριά μέθοδος ενσωμάτωσης σε ένα πρόγραμμα. Επιβάλλει επίσης αρκετή δομή στον κώδικα ώστε η ομάδα που εργάζεται σε αυτόν να μπορεί να τον κατανοήσει πιο εύκολα. Ωστόσο, αυτή η προσέγγιση μπορεί να είναι πιο δύσκολη στον εντοπισμό σφαλμάτων χωρίς υποστήριξη εργαλείων, επομένως ο εντοπισμός σφαλμάτων τείνει να είναι συγκεκριμένη για την πλατφόρμα.

Οι μηχανές ροής εργασίας είναι ιδιαίτερα ισχυροί καθώς επιτρέπουν τη σταδιακή υιοθέτηση από τις υπάρχουσες εφαρμογές. Μπορούν να εφαρμοστούν αποσπασματικά σε ορισμένες ροές εργασίας με ελάχιστο αποτύπωμα. Τούτου λεχθέντος, οι δύο μεγαλύτερες ελλείψεις των μηχανών ροής εργασίας πηγάζουν από το γεγονός ότι δεν επεκτείνονται στη βάση δεδομένων. Ως αποτέλεσμα, δεν υπάρχει μια ενιαία, αμφισβητήσιμη πηγή αλήθειας στα δεδομένα κατάστασης εφαρμογής και επιχείρησης. Επίσης, η σημασιολογία των συναλλαγών είναι γενικά διαφορετική από τη σημασιολογία της βάσης δεδομένων, απαιτώντας από τους προγραμματιστές εφαρμογών να χειρίζονται τις συνθήκες ακμών. 

Αν και δεν είναι ο κανόνας σήμερα, θέλουμε να παρουσιάσουμε τις εννοιολογικές αρχιτεκτονικές του τρόπου με τον οποίο οι ροές εργασίας μπορούν σε πολλές περιπτώσεις να χρησιμοποιηθούν ως μόνιμες αποθήκες δεδομένων:

Προσεγγίσεις με επίκεντρο τη βάση δεδομένων αναλυτικά 

Οι προσεγγίσεις με επίκεντρο τη βάση δεδομένων ξεκινούν με μια βάση δεδομένων, αλλά την επεκτείνουν για να υποστηρίξουν την αυθαίρετη εκτέλεση κώδικα για να επιτρέψουν ροές εργασίας παράλληλα με τη διαχείριση δεδομένων. Το κάνουν αυτό δίνοντας τον έλεγχο στους προγραμματιστές, ώστε να μπορούν να λαμβάνουν σαφείς αποφάσεις για μεταλλάξεις, συναλλαγές και ανικανότητα για κανονικά μπλοκ κώδικα — ουσιαστικά εκθέτοντας απευθείας τη σημασιολογία OLTP. Ο προγραμματιστής είναι υπεύθυνος για τη διατήρηση της επιχειρηματικής λογικής και των επιχειρηματικών δεδομένων ξεχωριστά από την κατάσταση της εφαρμογής. 

Πράγματι, η καθαρή άποψη βάσης δεδομένων είναι ότι η κατάσταση της εφαρμογής μπορεί πάντα να προέρχεται από επιχειρηματικά δεδομένα. Αυτό γίνεται συνήθως με την αποθήκευση της κατάστασης της εφαρμογής ως ένα σύνολο συναλλαγών που τροποποιούν τα επιχειρηματικά δεδομένα στη βάση δεδομένων. Είναι πιο εύκολο να το σκεφτούμε ως μια βάση δεδομένων που μπορεί να εκτελέσει μπλοκ κώδικα με τις ίδιες ισχυρές εγγυήσεις όπως τα συστήματα ροής εργασιών που περιγράφονται παραπάνω. 

Εσωτερικά, το ονομάζουμε αυτό το πλατφόρμα συναλλαγών λογικής εφαρμογής (ALTP) προσέγγιση επειδή, τελικά, επεκτείνει τις συναλλαγές OLTP στην εφαρμογή. Αλλά αυτό που πραγματικά χαρακτηρίζει το ALTP είναι ότι, για τις εφαρμογές Greenfield, μπορεί να εξαλείψει εντελώς την ανάγκη για τους προγραμματιστές εφαρμογών να διαχειρίζονται άμεσα την υποδομή back-end.  

Από τον φακό ALTP, η πιο συχνά χρησιμοποιούμενη προσέγγιση ξεκίνησε με το Firebase, το οποίο προσφέρει α πλήρης υπηρεσία "back-end εμπειρία", συμπεριλαμβανομένου του auth, του χώρου αποθήκευσης δεδομένων, των βάσεων δεδομένων και άλλων. Το Firebase και οι πιο πρόσφατοι συμμετέχοντες, όπως το Supabase, παραμένουν πολύ δημοφιλείς πλατφόρμες για έργα Greenfield. Και ενώ τείνουν να μένουν πιστοί στις ρίζες τους OLTP — και επομένως δεν υποστηρίζουν αυθαίρετη εκτέλεση κώδικα για συναλλαγές back-end συναρτήσεων — το Supabase αρχίζει ήδη να προσθέτει υποστήριξη για ροές εργασίας.

Ωστόσο, προσφορών ALTP επόμενης γενιάς όπως το Convex επιτρέπουν την εκτέλεση αυθαίρετου κώδικα ως συναλλαγή παράλληλα με τη βάση δεδομένων. Αυτές οι προσφορές επιτρέπουν τη σύνταξη κώδικα πλήρως συμβατό με συναλλαγές σε μια κανονική γλώσσα (π.χ. Javascript/Typescript), όπου ένα μόνο μπλοκ κώδικα μπορεί να διαβάσει, να γράψει και να μεταλλάξει δεδομένα — τόσο δεδομένα κατάστασης εφαρμογής όσο και επιχειρηματικά. Κατά μία έννοια, δίνει στους προγραμματιστές μια ενιαία πηγή αλήθειας με δυνατότητα αναζήτησης και παρέχει πρωτόγονες ροές εργασίας όπως οι συνδρομές. 

Το ALTP επιλύει το πρόβλημα που αντιμετωπίζουν οι μηχανές ροής εργασίας κατά την αποσύνδεση από τη βάση δεδομένων, αλλά, ως αποτέλεσμα, απαιτεί από τους χρήστες να βασίζονται στην προσφορά της βάσης δεδομένων τους και όχι σε ένα τυπικό OLTP για να έχουν τα οφέλη. Ως αποτέλεσμα, βλέπουμε κυρίως ομάδες να υιοθετούν το ALTP για εφαρμογές greenfield, αντί να το ενσωματώνουν σε υπάρχοντα, πολύπλοκα backend.

Το παραπάνω διάγραμμα είναι ένα κράμα των πολλών χειριστών με τους οποίους μιλήσαμε. Μερικοί θα χρησιμοποιήσουν απλώς έναν κινητήρα ροής εργασίας. Μερικοί θα χρησιμοποιήσουν απλώς μια προσέγγιση με επίκεντρο τη βάση δεδομένων. Αλλά πολλοί θα χρησιμοποιήσουν και τα δύο — ειδικά όταν μόλις αρχίζουν να υιοθετούν ροές εργασίας. Οι χρήστες των μηχανών ροής εργασίας σήμερα τείνουν να είναι ομάδες back-end που ασχολούνται με μεγάλες, πολύπλοκες εφαρμογές, αν και έχουμε δει επίσης πολλές ομάδες full-stack να τις υιοθετούν. Οι λύσεις back-end-as-a-service τείνουν να είναι πιο φιλικές προς τους προγραμματιστές και χρησιμοποιούνται πιο συχνά όταν η εφαρμογή οδηγεί την επιλογή τεχνολογίας. 

Η σύγκλιση

Γίνεται σαφές ότι οι προσεγγίσεις με επίκεντρο τη ροή εργασίας και οι προσεγγίσεις με επίκεντρο τη βάση δεδομένων βρίσκονται σε τροχιά σύγκρουσης. Ο κύριος λόγος για αυτό είναι ότι, ενώ η κατάσταση της εφαρμογής και η κατάσταση της βάσης δεδομένων είναι λογικά διακριτές, εξαρτώνται η μία από την άλλη και ένα σύστημα που δεν καλύπτει και τα δύο είναι πολύπλοκο να διορθωθεί και να διορθωθεί.  

Για παράδειγμα, θεωρήστε μια μηχανή ροής εργασίας που χρησιμοποιείται για την παρακολούθηση του μηχάνημα κατάστασης για τη διαδικασία ολοκλήρωσης αγοράς ενός χρήστη και αυτός ο χρήστης προσθέτει ένα αντικείμενο σε ένα καλάθι. Συνήθως, οι μηχανές ροής εργασίας διασφαλίζουν ότι ένα βήμα κώδικα θα εκτελεστεί ακόμη και σε περίπτωση αποτυχίας. Ωστόσο, μπορεί να υπάρξουν περιπτώσεις όπου ο κινητήρας πρέπει να επαναλάβει ένα δεδομένο βήμα κατά τη διάρκεια μιας βλάβης, επειδή δεν είναι απολύτως βέβαιο εάν το βήμα ολοκληρώθηκε πλήρως. Εάν αυτό το βήμα περιλαμβάνει την εγγραφή επιχειρηματικών δεδομένων σε μια παραδοσιακή βάση δεδομένων (σε αυτήν την περίπτωση, το αντικείμενο στο καλάθι) και η βάση δεδομένων δεν γνωρίζει τη διπλότυπη επανάληψη, θα καταλήξει σε μια διπλότυπη καταχώριση. 

Υπάρχουν δύο τρόποι για να το αντιμετωπίσετε αυτό. Ένας τρόπος είναι να προωθήσετε το πρόβλημα στον προγραμματιστή της εφαρμογής, ο οποίος θα χρησιμοποιήσει ένα nonce που παρέχεται από το σύστημα ροής εργασιών για να διασφαλίσει ότι έχει γραφτεί μόνο ένα στοιχείο. Αλλά αυτό προϋποθέτει ότι ο προγραμματιστής κατανοεί την ανικανότητα, η οποία είναι γνωστό ότι είναι δύσκολο να γίνει σωστά, και αυτό εξαλείφει πολλά από τη μαγεία της ύπαρξης ενός συστήματος ροής εργασιών. Ο άλλος τρόπος είναι να συνδέσετε τη μηχανή ροής εργασίας με μια βάση δεδομένων που γνωρίζει τη σημασιολογία των συναλλαγών της ροής εργασίας. Αυτό δεν έχει συμβεί ακόμα, αλλά δεν είναι δύσκολο να πιστέψει κανείς ότι θα συμβεί. 

Από την άλλη πλευρά, οι προσεγγίσεις με επίκεντρο τη βάση δεδομένων συνειδητοποιούν ότι η γενική ροή εργασίας είναι πραγματικά χρήσιμη για τους προγραμματιστές εφαρμογών. Και έτσι αρχίζουμε να βλέπουμε βάσεις δεδομένων (όπως το Convex) — οι οποίες υποστηρίζουν παραδοσιακές λειτουργίες βάσης δεδομένων, όπως ερωτήματα, μεταλλάξεις, ευρετήρια κ.λπ. — υλοποιούν λειτουργίες όπως προγραμματισμό και συνδρομές. Αυτά τους επιτρέπουν να χρησιμοποιούνται ως μηχανές ροής εργασίας. Δηλαδή, επιτρέπουν την εκτέλεση αυθαίρετων μπλοκ κωδικών με ισχυρές εγγυήσεις. 

Όπως το έθεσε ο Ian Livingstone (ο οποίος έδωσε σχόλια για αυτό το κομμάτι), "Είναι το κλασικό "Μεταφέρετε τη λογική της εφαρμογής στη βάση δεδομένων ή τη βάση δεδομένων στη λογική της εφαρμογής;" παίζοντας ξανά… αυτή τη φορά προέκυψε από τη διάλυση του μονόλιθου». Έχοντας αυτή τη διχοτόμηση για δεκαετίες, είναι σαφές ότι και τα δύο μοντέλα θα επιμείνουν βραχυπρόθεσμα. Είναι πολύ λιγότερο σαφές ότι αυτό θα παραμείνει έτσι μακροπρόθεσμα. 

Ιδιαίτερες ευχαριστίες στους Charly Poly (Defer), Dan Farrelly (Inngest), David Khourshid (Stately), Ian Livingstone (Cape Security), Enes Akar (Upstash), James Cowling (Convex), Jamie Turner (Convex), Paul Copplestone (Supabase ), Sam Lambert (PlanetScale), Tony Holdstock-Brown (Inngest), Matt Aitken (Trigger) για την αξιολόγηση αυτής της ανάρτησης και την υποβολή σχολίων. Επιπλέον, ευχαριστούμε τους Benjamin Hindman (Reboot), Fredrik Björk (Grafbase), Glauber Costa (Chiselstrike), Guillaume Salles (Liveblocks), Maxim Fateev (Temporal), Steven Fabre (Liveblocks) και Viren Baraiya (Orkes) που μας βοήθησαν με η έρευνα.

• SEO Powered Content & PR Distribution. Ενισχύστε σήμερα.
• Platoblockchain. Web3 Metaverse Intelligence. Ενισχύθηκε η γνώση. Πρόσβαση εδώ.
• Minting the Future με την Adryenn Ashley. Πρόσβαση εδώ.
• πηγή: https://a16z.com/2023/04/14/the-modern-transactional-stack/