Για χρόνια, η Vercel ήταν η προεπιλεγμένη πλατφόρμα όπου αναπτύσσαμε σχεδόν οτιδήποτε σχετικό με τον ιστό στη WebCatalog. Τα περισσότερα από αυτά τα έργα χρησιμοποιούσαν Next.js, οπότε ο συνδυασμός ήταν φυσικός. Οι ιστότοποι μάρκετινγκ, τα περιβάλλοντα των προϊόντων, οι ρυθμίσεις λογαριασμού, η κονσόλα προγραμματιστών, η ταυτοποίηση χρηστών, τα εργαλεία διαχείρισης και τα API μας κατέληξαν όλα να χρησιμοποιούν περίπου την ίδια τεχνολογική στοίβα.
Αυτό λειτούργησε καλά για πολύ καιρό. Η Vercel έκανε την ανάπτυξη εφαρμογών απλή, το Next.js μάς έδινε ένα παραγωγικό framework για frontend και backend, και σπάνια χρειαζόταν να σκεφτούμε την υποδομή στην οποία βασίζονταν.
Τελικά, αυτή η ευκολία έπαψε να ανταποκρίνεται στις ανάγκες των προϊόντων μας.
Οι ιστότοποι μάρκετινγκ εξακολουθούσαν να ωφελούνται από το SSR (απόδοση στην πλευρά του διακομιστή), αλλά οι περισσότερες άλλες διαδικτυακές εφαρμογές μας όχι. Μπορούσαν να είναι απλές SPA (εφαρμογές μίας σελίδας). Τα API μας χρειάζονταν ένα κανονικό περιβάλλον Node.js, με εγγενείς εξαρτήσεις και διεργασίες μακράς διάρκειας. Σχεδόν όλη η υπόλοιπη στοίβα frontend χρησιμοποιούσε ήδη Vite. Παράλληλα, το κόστος υποδομής γινόταν όλο και πιο δύσκολο να αγνοηθεί, ιδίως όσο αυξανόταν η δημόσια και η αυτοματοποιημένη κίνηση.
Αρχικά προσπαθήσαμε να βελτιστοποιήσουμε ό,τι είχαμε ήδη. Εξετάσαμε το ενδεχόμενο να κρατήσουμε το Next.js και να το μεταφέρουμε στα Cloudflare Workers μέσω ενός adapter. Δοκιμάσαμε το Astro για τους ιστότοπους μάρκετινγκ. Μεταφέραμε για λίγο τα API μας στα Cloudflare Containers.
Τελικά καταλήξαμε σε κάτι απλούστερο: οι περισσότερες διαδικτυακές εφαρμογές μας χρησιμοποιούν πλέον Vite + TanStack Router σε Cloudflare Workers, οι ιστότοποι μάρκετινγκ χρησιμοποιούν TanStack Start με SSR σε Cloudflare Workers και τα API μας χρησιμοποιούν Hono + tRPC στο Railway, ως κοντέινερ Node.js μακράς διάρκειας.
Η μετάβαση μείωσε το κόστος της διαδικτυακής υποδομής μας κατά περίπου 80%. Αφού αυστηροποιήσαμε επίσης τους κανόνες ασφαλείας στο Cloudflare και αποκλείσαμε περισσότερη κακόβουλη αυτοματοποιημένη κίνηση στο edge, η συνολική εξοικονόμηση αυξήθηκε σε περίπου 90%.
Το μεγαλύτερο μέρος της υλοποίησης της μετάβασης πραγματοποιήθηκε επίσης από πράκτορες AI για συγγραφή κώδικα, κυρίως τους Claude Fable 5 και Claude Opus 5. Οι μηχανικοί αποφάσιζαν την αρχιτεκτονική, όριζαν τους περιορισμούς, εξέταζαν τις αλλαγές και επαλήθευαν το αποτέλεσμα.
Δεν ξεκινήσαμε με στόχο να φύγουμε από τη Vercel
Το πρώτο μας ένστικτο ήταν να βελτιστοποιήσουμε την υπάρχουσα υποδομή.
Το webcatalog.io ήταν το προφανές σημείο εκκίνησης, επειδή δέχεται πολλή δημόσια κίνηση, ενώ οι περισσότερες σελίδες του αλλάζουν σχετικά σπάνια. Διαπιστώσαμε ότι υπερβολικά μεγάλο μέρος του ιστότοπου εξακολουθούσε να αποδίδεται δυναμικά. Έτσι, διορθώσαμε την ακούσια δυναμική απόδοση, προσθέσαμε ISR (σταδιακή αναδημιουργία στατικών σελίδων) σε διαδρομές με μεγάλη κίνηση, κάναμε περισσότερες σελίδες κατάλληλες για προσωρινή αποθήκευση και βελτιστοποιήσαμε τη δαπανηρή επεξεργασία των χαρτών ιστότοπου.
Η δουλειά αυτή βοήθησε, αλλά ανέδειξε πιο καθαρά και το βασικό πρόβλημα. Ξοδεύαμε όλο και περισσότερο χρόνο για να καταλάβουμε γιατί σχετικά στατικό περιεχόμενο ήταν δυναμικό, ποια συμπεριφορά του framework το είχε προκαλέσει και ποιον μηχανισμό του framework έπρεπε να χρησιμοποιήσουμε ώστε να μπορεί ξανά να αποθηκευτεί προσωρινά.
Στο μεταξύ, πολλές από τις άλλες εφαρμογές μας είχαν το αντίθετο πρόβλημα. Οι ρυθμίσεις λογαριασμού, η κονσόλα προγραμματιστών, οι εφαρμογές διαχείρισης και τα περισσότερα περιβάλλοντα προϊόντων δεν χρειάζονταν καθόλου απόδοση στον διακομιστή. Ήταν εφαρμογές στον φυλλομετρητή που επικοινωνούσαν με API.
Σε εκείνο το σημείο, το ερώτημα έπαψε να είναι «Πώς θα μειώσουμε τον λογαριασμό μας στη Vercel;» και έγινε «Τι θα φτιάχναμε αν αυτές οι εφαρμογές δεν ήταν ήδη εφαρμογές Next.js;»
Εξετάσαμε το Next.js στο Cloudflare
Η επιλογή με τις λιγότερες αλλαγές ήταν να κρατήσουμε το Next.js και να το μεταφέρουμε από τη Vercel στα Cloudflare Workers.
Το εξετάσαμε σοβαρά, επειδή το Next.js μπορεί να λειτουργήσει στο Cloudflare μέσω adapter, κάτι που θα μας επέτρεπε να διατηρήσουμε μεγάλο μέρος της υπάρχουσας δομής των εφαρμογών.
Όμως δεν θεωρούσαμε ότι το Next.js στο Cloudflare είναι ισοδύναμο με το Next.js στη Vercel. Το Next.js είναι πιο στενά ενσωματωμένο με το περιβάλλον εκτέλεσης, το σύστημα ανάπτυξης εφαρμογών, τη συμπεριφορά προσωρινής αποθήκευσης και τις δυνατότητες της πλατφόρμας Vercel. Στο Cloudflare, ένας adapter πρέπει να προσαρμόσει αυτές τις παραδοχές σε διαφορετικό περιβάλλον εκτέλεσης.
Αυτό μπορεί να λειτουργήσει καλά, αλλά, αν ο στόχος μας ήταν να απλοποιήσουμε τη στοίβα μας, η προσθήκη ενός ακόμη επιπέδου συμβατότητας δεν φαινόταν ιδανική.
Υπήρχε και ένα ευρύτερο ζήτημα εργαλείων. Σχεδόν οτιδήποτε άλλο φτιάχναμε στο frontend χρησιμοποιούσε ήδη Vite: εφαρμογές για υπολογιστές, επεκτάσεις φυλλομετρητή, SPA και άλλα έργα που εκτελούνται στην πλευρά του πελάτη.
Το Next.js είχε στραφεί έντονα προς το Turbopack, το οποίο έχει βελτιωθεί πολύ. Δεν επρόκειτο για παράπονο σχετικά με την απόδοσή του. Για εμάς, η μεγαλύτερη διαφορά ήταν το οικοσύστημα. Το Vite ήταν ήδη η κοινή βάση για το μεγαλύτερο μέρος του κώδικα frontend, με ευρύτερο οικοσύστημα plugin και περισσότερες δυνατότητες επαναχρησιμοποίησης ρυθμίσεων μεταξύ έργων.
Αν κρατούσαμε το Next.js στο Cloudflare, θα λύναμε λοιπόν ένα μέρος του προβλήματος φιλοξενίας, αλλά θα διατηρούσαμε τόσο την ασυμφωνία μεταξύ των framework όσο και ένα ξεχωριστό οικοσύστημα εργαλείων build.
Έτσι, κάναμε ένα βήμα πίσω και εξετάσαμε τι χρειαζόταν πραγματικά κάθε φόρτος εργασίας.
Χωρίσαμε τη στοίβα ανάλογα με τον φόρτο εργασίας
Μόλις σταματήσαμε να ψάχνουμε μία καθολική αντικατάσταση του Next.js, η αρχιτεκτονική έγινε πολύ απλούστερη.
Οι ιστότοποι μάρκετινγκ χρειάζονταν SSR, επειδή έχουν δημόσιες, τοπικοποιημένες σελίδες, μεταδεδομένα, κανονικές διευθύνσεις URL, χάρτες ιστότοπου και κίνηση από μηχανές αναζήτησης.
Οι περισσότερες άλλες διαδικτυακές εφαρμογές μας δεν χρειάζονταν SSR και μπορούσαν απλώς να είναι εφαρμογές Vite με TanStack Router.
Τα API μας δεν χρειάζονταν καθόλου framework React και ταίριαζαν καλύτερα σε ένα κανονικό περιβάλλον εκτέλεσης Node.js.
Ο τελικός διαχωρισμός ήταν ο εξής:
Διαδικτυακές εφαρμογές
Vite + TanStack Router
│
└── Cloudflare Workers
Ιστότοποι μάρκετινγκ
TanStack Start + SSR
│
└── Cloudflare Workers
API
Hono + tRPC
│
└── Railway / κοντέινερ Node.js
Ο κανόνας έγινε απλός: χρησιμοποιούμε SSR όπου προσφέρει πραγματική αξία, μια απλή SPA όπου δεν προσφέρει και εκτελούμε τις υπηρεσίες backend σε περιβάλλον κατάλληλο για backend.
Οι περισσότερες διαδικτυακές εφαρμογές έγιναν SPA
Η μετάβαση των SPA ήταν το ευκολότερο μέρος.
Η διαδικτυακή εφαρμογή WebCatalog μεταφέρθηκε ιδιαίτερα γρήγορα: δημιουργήσαμε τον αρχικό σκελετό της αντικατάστασης με Vite + TanStack Router, μεταφέραμε το περιβάλλον χρήστη, αλλάξαμε την πλατφόρμα ανάπτυξης σε Cloudflare Workers και αφαιρέσαμε την παλιά έκδοση Next.js μέσα στο ίδιο πρωινό.
Ακολουθήσαμε το ίδιο μοτίβο για τη διαδικτυακή εφαρμογή Lexibird, τις ρυθμίσεις λογαριασμού, την κονσόλα προγραμματιστών, την ταυτοποίηση χρηστών και τις εφαρμογές διαχείρισης. Από τη δημιουργία του πρώτου σκελετού SPA μέχρι τη διαγραφή της τελευταίας εφαρμογής Next.js πέρασαν περίπου 19 ημέρες.
Για αυτές τις εφαρμογές, η χρήση των Cloudflare Workers είναι σκόπιμα απλή. Το Vite δημιουργεί στατικά αρχεία, το Cloudflare τα σερβίρει και οι διαδρομές της εφαρμογής καταλήγουν στο index.html όταν δεν αντιστοιχούν σε αρχείο. Δεν υπάρχει περιβάλλον SSR, επειδή τίποτα δεν χρειάζεται απόδοση στον διακομιστή.
Το δυσκολότερο μέρος ήταν να διατηρήσουμε τη συμπεριφορά που είχε διαμορφωθεί γύρω από αυτές τις εφαρμογές με την πάροδο του χρόνου. Κάποια λογική ταυτοποίησης έπρεπε να μεταφερθεί από τις server routes του Next.js στο API, ενώ παλαιότερες εκδόσεις της εφαρμογής WebCatalog για υπολογιστές εξακολουθούσαν να εξαρτώνται από παλιά endpoints, τα οποία έπρεπε να συνεχίσουν να λειτουργούν.
Η μεταφορά του περιβάλλοντος React ήταν εύκολη.
Η διατήρηση των υφιστάμενων συμβάσεων ήταν δυσκολότερη.
Δοκιμάσαμε το Astro και το διαγράψαμε πέντε ημέρες αργότερα
Οι ιστότοποι μάρκετινγκ ήταν πιο δύσκολη υπόθεση.
Η πρώτη μας επιλογή ήταν το Astro, που φαινόταν φυσική λύση για τα webcatalog.io και lexibird.com, επειδή και τα δύο είναι δημόσιοι ιστότοποι με πολύ περιεχόμενο και το Astro ενσωματώνεται καλά με το Cloudflare.
Αρχίσαμε να μεταφέρουμε και τους δύο ιστότοπους και, πέντε ημέρες αργότερα, σταματήσαμε.
Δεν υπήρχε ένα και μοναδικό ανυπέρβλητο πρόβλημα. Αντίθετα, συσσωρεύονταν μικρές ασυμφωνίες. Κάποιες διαδρομές χρειάζονταν πρόσβαση στη βάση δεδομένων κατά την προαπόδοση, ενώ το περιβάλλον build μας σκόπιμα δεν διέθετε διαπιστευτήρια για τη βάση παραγωγής. Τα React islands έκαναν τη χρήση κοινής κατάστασης της εφαρμογής λιγότερο φυσική. Αντιμετωπίσαμε επίσης διαφορές μεταξύ προαποδιδόμενων διαδρομών και διαδρομών που αποδίδονταν κατά την εκτέλεση, καθώς και ορισμένες δυσκολίες με τα εργαλεία στο αποθετήριο κώδικά μας.
Κανένα από αυτά τα προβλήματα δεν ήταν αδύνατο να λυθεί. Ακριβώς γι' αυτό ήταν επικίνδυνο να συνεχίσουμε: θα μπορούσαμε εύκολα να περάσουμε άλλες μερικές εβδομάδες διορθώνοντας το ένα ζήτημα μετά το άλλο.
Αντί γι' αυτό, διαγράψαμε την υλοποίηση και ξεκινήσαμε από την αρχή.
Οι πράκτορες AI άλλαξαν τα δεδομένα αυτής της απόφασης. Μεγάλο μέρος της μηχανικής μεταφοράς δεν είχε απαιτήσει εβδομάδες εργασίας από μηχανικούς, οπότε το ήδη επενδεδυμένο κόστος ήταν μικρότερο και ήταν ευκολότερο να παραδεχτούμε ότι προτιμούσαμε άλλη αρχιτεκτονική.
Το TanStack Start ταίριαζε καλύτερα
Ξεκινήσαμε ξανά τη μετάβαση των ιστότοπων μάρκετινγκ από τον αρχικό κώδικα Next.js, αυτή τη φορά χρησιμοποιώντας TanStack Start.
Ταίριαζε πολύ πιο φυσικά, επειδή χρησιμοποιούσαμε ήδη TanStack Router στις εφαρμογές SPA. Έτσι, οι διαδρομές, οι loaders, οι παράμετροι αναζήτησης και η πλοήγηση βασίζονταν σε παρόμοιες έννοιες. Ο κώδικας παρέμεινε συνηθισμένος React και TypeScript, ενώ το σύστημα build ήταν το Vite.
Μεταφέραμε το lexibird.com στο TanStack Start μέσα σε μία ημέρα. Ακολούθησε το webcatalog.io.
Το πλεονέκτημα δεν ήταν ότι το TanStack Start έλυσε ως διά μαγείας κάθε πρόβλημα. Ήταν ότι ταίριαζε με την κατεύθυνση προς την οποία κινούνταν ήδη η υπόλοιπη στοίβα μας.
Σε ένα monorepo, αυτό έχει σημασία. Τα κοινά εργαλεία build σημαίνουν περισσότερα επαναχρησιμοποιήσιμα plugin και ρυθμίσεις, λιγότερες ειδικές περιπτώσεις κατά την αποσφαλμάτωση, λιγότερες εναλλαγές πλαισίου για τους προγραμματιστές και λιγότερες συμβάσεις ειδικές για κάθε έργο που πρέπει να ανακαλύψουν οι πράκτορες συγγραφής κώδικα.
Το Cloudflare ήταν πολύ φθηνότερο για τη δική μας κίνηση
Η αρχιτεκτονική ήταν μόνο ένας από τους λόγους που μειώθηκε ο λογαριασμός μας. Η τιμολόγηση του Cloudflare ήταν σημαντικός παράγοντας, ιδίως όσον αφορά το εύρος ζώνης.
Το επί πληρωμή πρόγραμμα Cloudflare Workers χρεώνει σήμερα κυρίως βάσει αιτημάτων και χρήσης CPU και δεν προσθέτει χρεώσεις μεταφοράς δεδομένων ή εύρους ζώνης για τα Workers. (developers.cloudflare.com) Αυτό έχει μεγάλη σημασία για δημόσιους ιστότοπους, επειδή ένα αίτημα μπορεί να χρησιμοποιεί ελάχιστη CPU, αλλά να μεταφέρει HTML, JavaScript, εικόνες, γραμματοσειρές και άλλα αρχεία.
Το μοντέλο τιμολόγησης της Vercel περιλαμβάνει επίσης κατηγορίες και όρια χρήσης που σχετίζονται με το δίκτυο, όπως το Fast Data Transfer και το Fast Origin Transfer. (vercel.com) Για το δικό μας προφίλ κίνησης, το Cloudflare ήταν σημαντικά οικονομικότερο.
Η εξοικονόμηση δεν προήλθε μόνο από την αλλαγή παρόχου. Μετατρέψαμε επίσης πολλές εφαρμογές σε στατικά build του Vite, περιορίσαμε το περιττό SSR, κάναμε την προσωρινή αποθήκευση πιο ρητή και μεταφέραμε τους φόρτους εργασίας των API σε περιβάλλον εκτέλεσης που τους ταίριαζε καλύτερα. Ωστόσο, η τιμολόγηση του Cloudflare, ιδίως για το εύρος ζώνης, συνέβαλε σημαντικά στη μείωση κατά περίπου 80% που παρατηρήσαμε.
Το ποσοστό αυτό αφορά συγκεκριμένα τον δικό μας φόρτο εργασίας. Δεν ισχυριζόμαστε ότι κάθε εφαρμογή που μεταφέρεται από τη Vercel στο Cloudflare θα εξοικονομήσει 80%.
Τα API κατέληξαν στο Railway
Τα API ήταν ξεχωριστό πρόβλημα.
Παρότι ήταν έργα Next.js, ήταν ήδη ως επί το πλείστον ανεξάρτητα από το Next.js. Ο κώδικας του WebCatalog API ήταν περίπου 34.000 γραμμές, αλλά μόνο επτά αρχεία εισήγαν το next/server. Το tRPC χρησιμοποιούσε ήδη τον adapter Fetch και το Inngest υποστήριζε το Hono.
Αντικαταστήσαμε το επίπεδο HTTP του Next.js με Hono. Αυτό το μέρος ήταν απροσδόκητα μικρό.
Το δυσκολότερο ερώτημα ήταν πού θα το εκτελούσαμε. Τα απλά Workers δεν ήταν κατάλληλα, επειδή τα API χρησιμοποιούν Node.js και εγγενείς εξαρτήσεις όπως το sharp.
Αρχικά δοκιμάσαμε τα Cloudflare Containers, χάρη στα οποία φύγαμε γρήγορα από τη Vercel. Όμως, αφού χρησιμοποιήσαμε αυτή τη λύση σε παραγωγή, διαπιστώσαμε ότι το μοντέλο λειτουργίας της απαιτούσε περισσότερη χειροκίνητη ρύθμιση χωρητικότητας από όση θέλαμε τότε.
Έτσι, μεταφέραμε ξανά τα API.
Σήμερα εκτελούνται στο Railway ως συνηθισμένες υπηρεσίες κοντέινερ Node.js μακράς διάρκειας. Το CI (συνεχής ενσωμάτωση) δημιουργεί εικόνες Docker και τις ανεβάζει στο registry μας, ενώ το Railway αναλαμβάνει την οριζόντια αυτόματη κλιμάκωση.
Δεν χρειάζεται να εκτελούνται τα πάντα στο edge.
Η αποχώρηση από τη Vercel σήμαινε περισσότερες ευθύνες για εμάς
Το χαμηλότερο κόστος συνοδευόταν από έναν συμβιβασμό.
Η Vercel και το Next.js διαχειρίζονταν πολλές λειτουργίες υποδομής σε υψηλότερο επίπεδο. Με το TanStack Start και τα Workers, στραφήκαμε σε πιο ρητούς κανόνες προσωρινής αποθήκευσης HTTP. Μια σελίδα αποδίδεται, επιστρέφουμε headers προσωρινής αποθήκευσης και το Cloudflare αποθηκεύει προσωρινά την απόκριση. Η προσωρινή αποθήκευση στον φυλλομετρητή και στο edge μπορεί να ακολουθεί διαφορετικές πολιτικές, όπως τη χρήση παλιού περιεχομένου όσο ανανεώνεται στο παρασκήνιο στο edge.
Μας άρεσε που αυτές οι αποφάσεις έγιναν ρητές, αλλά όταν διαχειρίζεσαι πιο άμεσα την υποδομή, τα λάθη είναι επίσης δικά σου.
Κάναμε μερικά. Ένας κανόνας προσωρινής αποθήκευσης στην παραγωγή συμπεριέλαβε κατά λάθος αποκρίσεις server functions του TanStack που αφορούσαν συγκεκριμένους επισκέπτες, ενώ μια άλλη ρύθμιση προσωρινής αποθήκευσης αλληλεπιδρούσε άσχημα με τη συμπεριφορά fallback της SPA. Αυτά τα σφάλματα μας υπενθύμισαν ότι η ορθότητα μιας μετάβασης δεν μπορεί να αποδειχθεί εξ ολοκλήρου εξετάζοντας το αποθετήριο κώδικα. Η υποδομή παραγωγής είναι κι αυτή μέρος του συστήματος.
Οι πράκτορες AI άλλαξαν τον τρόπο που κάναμε τη μετάβαση
Το μεγαλύτερο μέρος της υλοποίησης έγινε από πράκτορες συγγραφής κώδικα, κυρίως τους Claude Fable 5 και Claude Opus 5.
Οι μεταβάσεις μεταξύ framework προσφέρονται ιδιαίτερα για πράκτορες, επειδή μεγάλο μέρος της δουλειάς έχει ένα σαφές υπάρχον σημείο αναφοράς. Μετέφερε αυτή τη διαδρομή, διατήρησε αυτή τη διεύθυνση URL, αντικατάστησε αυτό το API του framework, κράτησε τα ίδια μεταδεδομένα, εκτέλεσε τον έλεγχο τύπων, διόρθωσε τα σφάλματα και σύγκρινε το αποτέλεσμα με την παλιά υλοποίηση.
Για το webcatalog.io, διατηρούσαμε έναν πίνακα παρακολούθησης της μετάβασης, που χώριζε τη δουλειά σε στάδια όπως η βασική υποδομή, οι σελίδες προϊόντων, οι σελίδες καταλόγου, η αναζήτηση, το ιστολόγιο, οι τιμές, οι ανακατευθύνσεις, οι χάρτες ιστότοπου και η τελική αλλαγή συστήματος. Αντί να ζητήσουμε από έναν πράκτορα «να μεταφέρει το webcatalog.io στο TanStack Start», του δίναμε οριοθετημένες εργασίες με σαφώς καθορισμένες απαιτήσεις που έπρεπε να παραμείνουν αναλλοίωτες.
Η υπάρχουσα εφαρμογή έγινε η προδιαγραφή. Η δουλειά του πράκτορα ήταν να αναπαράγει τη συμπεριφορά με τη νέα αρχιτεκτονική, όχι να επανεφεύρει το προϊόν.
Έτσι, η ανθρώπινη προσπάθεια μετατοπίστηκε από τη χειροκίνητη μεταφορά κώδικα σε ερωτήματα όπως: Χρειάζεται πράγματι αυτή η σελίδα SSR; Ποια συμπεριφορά είναι σκόπιμη; Τι μπορεί να αποθηκεύεται προσωρινά για όλους; Ποιες διευθύνσεις URL πρέπει να μείνουν ίδιες; Πού πρέπει να γίνεται η ταυτοποίηση; Πότε πρέπει να σταματήσουμε να προσπαθούμε να κάνουμε μια προσέγγιση να λειτουργήσει;
Εξακολουθούσαμε να ελέγχουμε το αποτέλεσμα, να εκτελούμε build και ελέγχους τύπων και να επαληθεύουμε χειροκίνητα τομείς υψηλότερου κινδύνου, όπως η ταυτοποίηση, το SEO (βελτιστοποίηση για μηχανές αναζήτησης), οι ανακατευθύνσεις και η προσωρινή αποθήκευση.
Η σημαντική αλλαγή δεν ήταν ότι η AI έγραφε κώδικα για εμάς. Ήταν ότι έκανε τον πειραματισμό φθηνότερο.
Έγινε πολύ ευκολότερο να δικαιολογήσουμε τη δοκιμή του Astro και τη διαγραφή της υλοποίησης πέντε ημέρες αργότερα. Ήταν λιγότερο επώδυνο να μεταφέρουμε τα API μία φορά και ύστερα να αποφασίσουμε ότι μια άλλη πλατφόρμα ταίριαζε καλύτερα. Η μηχανική δουλειά κόστιζε λιγότερο, οπότε μπορούσαμε να αλλάξουμε πορεία όταν η αρχιτεκτονική δεν ήταν σωστή, αντί να συνεχίσουμε επειδή είχαμε ήδη επενδύσει υπερβολικά σε αυτήν.
Οι πράκτορες έκαναν την υλοποίηση λιγότερο σπάνιο πόρο.
Αυτό έκανε την αρχιτεκτονική, τους περιορισμούς, την ανασκόπηση και την επαλήθευση πιο σημαντικά.
Το 80% έγινε περίπου 90%
Μετά τη μετάβαση, το κόστος της διαδικτυακής υποδομής μας ήταν περίπου 80% χαμηλότερο.
Στη συνέχεια, αρχίσαμε να δίνουμε μεγαλύτερη προσοχή στο ποια αιτήματα έφταναν εξαρχής στις εφαρμογές.
Ένα σημαντικό μέρος της κίνησης στο δημόσιο διαδίκτυο είναι αυτοματοποιημένο: μηχανές αναζήτησης, ανιχνευτές AI, πράκτορες, εργαλεία συλλογής δεδομένων, εργαλεία σάρωσης και λιγότερο καλοπροαίρετα bot. Ένα μέρος αυτής της κίνησης είναι χρήσιμο και ένα άλλο όχι.
Με τις εφαρμογές να βρίσκονται απευθείας πίσω από το Cloudflare, αυστηροποιήσαμε τους κανόνες ασφαλείας μας, ώστε η κακόβουλη αυτοματοποιημένη κίνηση να απορρίπτεται στο edge προτού προκαλέσει υπολογιστικό φόρτο στις εφαρμογές ή εργασίες στη βάση δεδομένων.
Μετά από αυτό, η συνολική εξοικονόμηση έφτασε περίπου το 90% σε σύγκριση με την παλιά υποδομή.
Η τελική μείωση προέκυψε από τον συνδυασμό πολλών παραγόντων: τη χαμηλότερη τιμολόγηση του Cloudflare, ιδίως για το εύρος ζώνης· λιγότερη εργασία στην πλευρά του διακομιστή· ένα καταλληλότερο περιβάλλον εκτέλεσης για τα API μας· πιο ρητούς κανόνες προσωρινής αποθήκευσης· και λιγότερα περιττά αιτήματα που φτάνουν στις εφαρμογές.
Πού καταλήξαμε
Δεν έχουν απομείνει εφαρμογές Next.js στο αποθετήριο κώδικά μας. Οι περισσότερες διαδικτυακές εφαρμογές μας είναι πλέον SPA με Vite + TanStack Router σε Cloudflare Workers. Τα webcatalog.io και lexibird.com χρησιμοποιούν TanStack Start σε Cloudflare Workers, επειδή αυτοί οι ιστότοποι ωφελούνται πραγματικά από το SSR. Τα API μας χρησιμοποιούν Hono + tRPC στο Railway και εκτελούνται ως συνηθισμένα κοντέινερ Node.js. Σχεδόν όλα τα έργα frontend μας ανήκουν πλέον στο οικοσύστημα του Vite.
Το κόστος υποδομής μας μειώθηκε κατά περίπου 80%, με τη σημαντικά ευνοϊκότερη τιμολόγηση του Cloudflare για τη δική μας κίνηση, ιδίως όσον αφορά το εύρος ζώνης, να συμβάλλει καθοριστικά. Το φιλτράρισμα της κακόβουλης αυτοματοποιημένης κίνησης στο edge ανέβασε τη συνολική εξοικονόμηση σε περίπου 90%.
Όμως το αποτέλεσμα που έχει τη μεγαλύτερη σημασία για εμάς αφορά την αρχιτεκτονική. Οι ιστότοποι μάρκετινγκ χρησιμοποιούν SSR, οτιδήποτε άλλο μπορεί να είναι SPA είναι SPA και τα API εκτελούνται σε κανονικούς διακομιστές όταν αυτό είναι απλούστερο.
Ξεκινήσαμε προσπαθώντας να μειώσουμε το κόστος της Vercel.
Καταλήξαμε να συνειδητοποιήσουμε ότι δεν χρειαζόμασταν το μεγαλύτερο μέρος της αρχιτεκτονικής για την οποία πληρώναμε.