Eine Exkursion in React.js & Next.js

Heute wird es mal ziemlich technisch. Seit einigen Wochen beschäftige ich mich mit Javascript, React und Next. Heute hatte ich eine ruhige Mittagspause und konnte ein bisschen darüber nachdenken und recherchieren - irgendwie hatte ich komisches Bauchgefühl wegen den Dingen, die ich da so nachprogrammiert habe. Ich werde etwas ausholen müssen... Webentwicklung im engeren Sinn hatte ich noch nie so ganz auf dem Schirm, aber es hatte sich hier angeboten, ich bin da eher zufällig drauf gestoßen. Als Projekt hatte ich mir einen Webshop für Restaurants ausgesucht. Ich hatte sowohl einen Kurs auf Udemy dazu gefunden als auch einen Kurs auf Youtube. Der Kurs auf Udemy hat mir nicht so richtig gut gefallen, obwohl der Instructor wirklich angenehm anzuhören ist und sehr strukturiert vorgeht. Eigentlich hat mich nur die Optik des Projekts nicht so ganz angesprochen wie bei dem Kurs auf Youtube, technisch sind beide extrem ähnlich. Den Kurs auf Youtube verfolge ich weiter, ich bin da so etwa zu 2/3 durch, möchte hier aber schon mal meine Gedanken sortieren.

Ich schweife ab und sollte zum Punkt kommen. Bei beiden Kursen ist die Struktur soweit identisch: die Produkte liegen in einer MongoDB, da kommen JSONs bei Anfragen raus. Ja, intern ist das wohl nicht ganz richtig, spielt hier aber keine Rolle. In den Kursen entwickelt man eine API, über welche die MongoDB angesprochen wird. Diese API gibt ebenfalls JSON aus und wird wiederum z.B. auf den Produktseiten verwendet (aber auch für die Bestellungen usw). Die Kommunikation sieht also etwa so aus:

Produktseite ⇄ API ⇄ MongoDB

Hat mich erst gar nicht irritiert. Aber je mehr ich von React/Next/JS verstanden habe, umso merkwürdiger fand ich das ganze. Ich hab dann schon überlegt, man müsste die API ja prinzipiell nach außen hin verstecken oder besser: vernünftig absichern. So richtig wollte mir das aber keine Ruhe lassen, also musste ich googlen. Und mein Bauchgefühl war tatsächlich richtig! Ich zitiere hier mal aus der Dokumentation von Next.js:

It can be tempting to reach for an API Route when you want to fetch data from the server, then call that API route from getServerSideProps. This is an unnecessary and inefficient approach, as it will cause an extra request to be made due to both getServerSideProps and API Routes running on the server.

Take the following example. An API route is used to fetch some data from a CMS. That API route is then called directly from getServerSideProps. This produces an additional call, reducing performance. Instead, directly import the logic used inside your API Route into getServerSideProps. This could mean calling a CMS, database, or other API directly from inside getServerSideProps.

Es wird hier genau das Verhalten geschildert, welches in den Kursen gelehrt wird. In beiden. Irgendwie empfinde ich das sogar als anti-pattern, das Gegenteil von DRY (don't repeat yourself) sozusagen. Ja, APIs sind eine tolle Sache. Ja, Next hat APIs als Feature umarmt und toll umgesetzt. Und es ist sinnvoll, den Umgang mit APIs zu lernen bzw. zu lehren, aber hier sind das nur APIs um der API willen. Wenn man die API rauswirft, kann man problemlos folgendes Schema fahren:

Produktseite ⇄ MongoDB

Ich befürchte fast, dass intern die JSON aus der Datenbank deserialisiert wird, intern als Array o.ä. rumlungert, dann über die API wieder frisch als JSON serialisiert ausgeliefert wird um sie dann zu verarbeiten. Das ist zwar keine hohe (Rechen-)Kunst, aber spätestens bei ein paar hundert Anfragen pro Sekunde geht da so mancher Server sicher schon etwas in die Knie. Da geht es auch um die user experience und um SEO. Also wird - wenn so eine Macke im Code nicht gefunden wird - wieder mehr Hardware auf das Problem geworfen. Man liest wohl zwischen den Zeilen, ich bin nicht so mega begeistert. Andererseits ist das auch eine Gelegenheit, um am Code zu wachsen, insofern bin ich trotzdem dankbar für die Kurse. Letzten Endes mache ich einen ~dreistündigen Gratiskurs, also: so what?