GraphQL: μαθήματα στην παραγωγή

Είναι το 2020. Το ομάδα κλίνει όλο και περισσότερο προς την κατασκευή εφαρμογών μίας σελίδας, ή τουλάχιστον τη συμπερίληψη πλούσιων στοιχείων σε κανονικές εφαρμογές πολλών σελίδων. Η [GraphQL](https://graphql.org/) είναι [πάνω από δύο ετών](https://en.wikipedia.org/wiki/GraphQL) τώρα, η οποία από JavaScript τα πρότυπα του οικοσυστήματος θα μπορούσαν να θεωρηθούν ώριμα. Αισθανόμασταν λίγο περιπετειώδεις, οπότε αποφύγαμε τα συνηθισμένα JSON APIs και βουτήξαμε κατευθείαν μέσα - να τι μάθαμε.

Χρειάζεστε έναν διακομιστή GraphQL

Στα περισσότερα πλαίσια που χρησιμοποιούνται για ανάπτυξη ιστοσελίδων, τα εργαλεία για τη δημιουργία ενός JSON API υπάρχουν ήδη. Μπορείτε να δημιουργήσετε μια δομή διαδρομής και να δεχτείτε εύκολα κάποια GETs και POSTs, και στη συνέχεια να εξάγετε μια απάντηση JSON. Το Ruby on Rails διαθέτει ακόμη και ένα ειδικό έργο ρύθμιση που καταργεί τα συνήθη καλούδια της HTML και βάζει στη θέση τους μια στέρεη βάση για APIs. Αυτό που προκύπτει είναι ότι ένας εξειδικευμένος προγραμματιστής που χρησιμοποιεί σύγχρονα εργαλεία μπορεί να δημιουργήσει ένα backend κυριολεκτικά μέσα σε λίγα λεπτά.

Όχι όμως με την GraphQL. Ενώ υπάρχουν βιβλιοθήκες διακομιστή για πολλές γλώσσες, εξακολουθείτε να επιβαρύνεστε με ποινή ταχύτητας από την πρώτη στιγμή - απλά και μόνο επειδή πρέπει να βρείτε τι είναι σωστό για το οικοσύστημά σας. Σε μια πιο προσωπική σημείωση, δεν μου αρέσει επίσης ο όρος "διακομιστής" που χρησιμοποιείται για να περιγράψει μια βιβλιοθήκη που μπορεί να εισαχθεί σε ένα έργο.

Υπάρχει μόνο ένα τελικό σημείο

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

Η GraphQL χρησιμοποιεί μόνο ένα τελικό σημείο, συνήθως /graphql. Κάθε αίτηση προς το API σας θα φτάνει ως αίτηση POST σε αυτό το τελικό σημείο, και από εκεί και πέρα είναι ευθύνη του διακομιστή GraphQL να καταλάβει τι θέλει ο πελάτης και να απαντήσει κατάλληλα.

Με την πρώτη ματιά φαίνεται δυσκίνητο: φανταστείτε να προσπαθείτε να κάνετε τα πάντα σε ένα JSON API με ένα μόνο τελικό σημείο! Ωστόσο, σύντομα αρχίζει να βγάζει νόημα καθώς το API σας ωριμάζει και κάποια πράγματα αντικαθίστανται από άλλα. Η απομάκρυνση στα κλασικά API γίνεται συνήθως σε επίπεδο namespace, μετακινώντας από το v1 στο v2. Η GraphQL παρέχει πολύ περισσότερο έλεγχο, μέχρι και την κατάργηση ενός μόνο πεδίου. Φανταστείτε να μπορείτε να πείτε σε έναν καταναλωτή REST API ότι δεν θέλετε να χρησιμοποιεί το όνομα και να χρησιμοποιήσετε το πεδίο fancy_name αντ' αυτού! Αποδεικνύεται ότι αυτό που αρχικά φαινόταν δυσκίνητο είναι στην πραγματικότητα ένα από τα καλύτερα χαρακτηριστικά.

Όλα είναι δακτυλογραφημένα

Το JSON δεν έχει πραγματικά πολλά χαρακτηριστικά πληκτρολόγησης. Υπάρχουν συμβολοσειρές, αριθμοί, πίνακες και αντικείμενα. Πέρα από αυτά, δεν είστε τυχεροί. Αντίθετα, στην GraphQL, τα πάντα αρχίζουν και τελειώνουν με τύπους, καθώς ακόμη και οι ρίζες Query και Mutation είναι ακριβώς αυτό - τύποι. Η DSL GraphQL επιβάλλει τον έλεγχο τύπων τόσο στον διακομιστή όσο και στον πελάτη, αποτρέποντας κάθε είδους δυσάρεστες εκπλήξεις.

Αυτό είναι πολύ σημαντικό, ιδίως καθώς οι ίδιες οι SPA ελέγχονται ολοένα και περισσότερο, είτε με τη χρήση του TypeScript είτε με εναλλακτικές λύσεις όπως η Flow. Η GraphQL καθιστά εύκολη την εισαγωγή σύνθετων και σύνθετων τύπων πάνω από τις προεπιλεγμένες τιμές και γίνεται γρήγορα δεύτερη φύση για τους προγραμματιστές τόσο στο backend όσο και στο frontend.

Διαβάστε περισσότερα: Δοκιμή JavaScript... με Ruby?!

Τα έγγραφα είναι ενσωματωμένα

Σε ένα κλασσικό API JSON, η τεκμηρίωση μπορεί να είναι δευτερεύουσα. Και ακόμη και αν δεν είναι, υπάρχουν πολλές μέθοδοι για να διαλέξετε. Χρησιμοποιούμε κάποιο σχήμα όπως OpenAPI? Το μετατρέπουμε στη συνέχεια σε μορφή αναγνώσιμη από τον άνθρωπο με εργαλεία όπως το Swagger; Ή απλά πετάμε κάπου ένα σωρό αρχεία Markdown; Παρόλο που αυτό το πρόβλημα έχει επιλυθεί πολλές φορές, εξακολουθεί να απαιτεί συνειδητή σκέψη και προσπάθεια από την ομάδα - πρώτα για τη δημιουργία των εγγράφων και στη συνέχεια για τη διατήρησή τους σε ενημέρωση και διάδοση. Πρόκειται για ένα ακόμη πιο σύνθετο πρόβλημα όταν το API έχει διάφορα τμήματα που είναι προσβάσιμα μόνο π.χ. από συγκεκριμένους ρόλους χρηστών.

Στην GraphQL η τεκμηρίωση είναι πολίτης πρώτης κατηγορίας, καθώς οι περισσότεροι διακομιστές επιτρέπουν την τεκμηρίωση των τύπων και των αιτημάτων σας επιτόπου. Από τις αρχές του 2018 η GraphQL Schema Definition Language έχει γίνει μέρος των επίσημων προδιαγραφών, οπότε υπάρχει ακριβώς ένας τρόπος τεκμηρίωσης ενός GraphQL API. Επίσης, δεδομένου ότι η GraphQL επιτρέπει τον ορισμό της ορατότητας ορισμένων τμημάτων του γραφήματος, οι χρήστες που δεν θα έπρεπε να βλέπουν αυτόματα έγγραφα για όσα δεν μπορούν να έχουν πρόσβαση. Το γεγονός ότι η απόφαση έχει ληφθεί και οι σαφείς κατευθυντήριες γραμμές αποτέλεσαν μεγάλη ευλογία για την ομάδα.

Υπάρχουν μόνο δύο τύποι δράσης

Σε αντίθεση με τα GET, POST, PUT, PATCH και DELETE του HTTP, υπάρχουν μόνο δύο τύποι ενεργειών στην GraphQL: Ερωτήματα και μεταλλάξεις. Η κύρια διαφορά είναι ότι οι μεταλλάξεις μπορούν και θα μεταβάλλουν την κατάσταση του συστήματος, ενώ τα ερωτήματα θα διαβάζουν μόνο παθητικά δεδομένα.

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

Χρειάζεστε έναν πελάτη

Η αλληλεπίδραση με REST APIs μέσω HTTP είναι εξαιρετικά εύκολη στο vanilla JavaScript, ακόμα περισσότερο με τη χρήση του σύγχρονου φέρε το API. Αντίθετα, για την GraphQL θέλετε να χρησιμοποιήσετε μια βιβλιοθήκη-πελάτη αν θέλετε πραγματικά αξιοπρεπείς επιδόσεις. Δεν είναι αδύνατο να αλληλεπιδράσετε με ένα GraphQL API χρησιμοποιώντας μόνο το vanilla JavaScript - είναι απλά αιτήματα POST τελικά. Ωστόσο, η χρήση μόνο μακροχρόνιων τεχνολογιών Web, όπως η προσωρινή αποθήκευση αιτήσεων για κοινές κλήσεις API, δεν θα λειτουργήσει, καθώς τα αιτήματα POST δεν αποθηκεύονται γενικά στην προσωρινή μνήμη.

Κάθε λογικός πελάτης GraphQL υλοποιεί έναν μηχανισμό προσωρινής αποθήκευσης αποτελεσμάτων από την πλευρά του πελάτη και πολλά άλλα χαρακτηριστικά. Χάρη σε όλες αυτές τις επιλογές, η χειροκίνητη διαμόρφωση μιας παραμέτρου για έναν πελάτη GraphQL σε εισαγωγικό επίπεδο είναι μια εντελώς εκπληκτική εργασία. Όταν ξεκινάτε με την GraphQL συνιστώ ιδιαίτερα να ρίξετε μια ματιά στο Apollo-Boost δεδομένου ότι έρχεται με πολύ λογικές προεπιλογές.

Ο πελάτης επιλέγει τα δεδομένα

Όλοι έχουμε βρεθεί σε αυτή την κατάσταση: τραβάμε μια λίστα δεδομένων από το API και λείπει κάποιο κρίσιμο πεδίο σχετικά με ένα σχετικό μοντέλο. Στη συνέχεια, εφαρμόζουμε ένα hack που περιλαμβάνει N+1 αιτήσεις, ενώ γκρινιάζουμε στους προγραμματιστές του backend που τρέχουν να το προσθέσουν γρήγορα. Αυτό συνήθως δεν συμβαίνει με ένα καλά υλοποιημένο GraphQL API, αφού μπορούμε απλώς να εμβαθύνουμε στα δεδομένα όσο βαθιά θέλουμε. Θέλετε να δείτε τη διεύθυνση ενός πελάτη σε μια παραγγελία σε αυτή τη δέσμη; Κανένα πρόβλημα - τουλάχιστον θεωρητικά, πράγμα που μας οδηγεί όμορφα στο...

Η πολυπλοκότητα είναι πιο δύσκολο να προβλεφθεί

Όταν σχεδιάζετε τη GraphQL από την πλευρά του back-end, μπορεί να είναι δύσκολο να σκεφτείτε όλο το βάθος στο οποίο μπορεί να εμβαθύνει ένας πελάτης στο γράφημα. Υπάρχουν πολλοί τρόποι για να οργανώσετε και να παρατηρήσετε τη χρήση του γράφου σας, και αφού αφήσετε τους συναδέλφους σας στο front-end να παίξουν για λίγο, μπορείτε να αρχίσετε να βλέπετε μερικά μακροσκελή ερωτήματα που εκτελούν μάλλον ευφάνταστες αναγνώσεις στο χώρο αποθήκευσης δεδομένων σας. Σε ένα REST API αυτό είναι πιο εύκολο να ελεγχθεί, καθώς μπορείτε εύκολα να πείτε το εύρος των δεδομένων στα οποία θα έχετε πρόσβαση σε ένα μόνο αίτημα. Συχνά αυτή η χαμένη πολυπλοκότητα μπορεί να σας δαγκώσει άσχημα μόλις το απελευθερώσετε στην παραγωγή. Πολλές από αυτές τις φορές δεν είναι επίσης προφανές πώς να ξεφύγετε από αυτή την τρύπα που έχετε σκάψει στον εαυτό σας.

Οι αριθμημένες σελίδες είναι πραγματικά δύσκολες

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

Θα το ξανακάνουμε;

Με όλες τις γκρίνιες και τις διαφορές που αναφέρθηκαν παραπάνω, πιθανόν να νομίζετε ότι αντιμετωπίζουμε την GraphQL ως ένα πείραμα που έγινε ξινό και επιστρέψαμε κατευθείαν στα REST APIs. Αυτό δεν είναι αλήθεια. Αν μη τι άλλο, εργαζόμαστε για να χρησιμοποιήσουμε την GraphQL ευρύτερα σε έργα σε ολόκληρο τον οργανισμό. Είναι μια σπουδαία τεχνολογία που έχει κάνει τη δουλειά μας ευκολότερη και καλύτερη. Επενδύσαμε, ωστόσο, αρχικά στην GraphQL χωρίς να συνειδητοποιήσουμε πλήρως τι είδους πόνους ανάπτυξης θα περάσουμε.

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

Διαβάστε επίσης:

– Πώς να διαχειρίζεστε αποτελεσματικά τους απομακρυσμένους προγραμματιστές; Ο οδηγός για τους CTOs

– Python vs. Ruby? Ποια τεχνολογία πρέπει να χρησιμοποιήσετε για την ανάπτυξη προϊόντων;

– Ένας γρήγορος οδηγός για τη δημιουργία και την ανάπτυξη της δικής σας αγοράς. Τι αξίζει να γνωρίζετε;