Headless und API First Solidus: Die Voraussetzung für eine Mobile App
Es gibt ein Gespräch das ich so oft geführt habe dass ich es vertonen könnte. Ein Shop ist seit etwa achtzehn Monaten live. Er läuft gut. Und dann sagt jemand im Unternehmen, meistens nach einer Messe oder einem Gespräch mit einem Mitbewerber, das Wort App. Oder Marktplatz. Oder Kiosk für den Showroom. Oder eine zweite Marke die denselben Bestand über eine anders aussehende Seite verkaufen soll. Und der Inhaber ruft mich an und fragt wie schwer das wäre. Die ehrliche Antwort hängt fast vollständig von einer Entscheidung ab die getroffen wurde, oder öfter nicht getroffen wurde, bevor der Shop gebaut wurde: ob der Shop als Website gebaut wurde die zufällig Dinge verkauft, oder als System das Dinge verkauft und zufällig eine Website davor hat. Diese Unterscheidung ist das was Leute mit Headless meinen, wenn sie überhaupt etwas damit meinen. In diesem Artikel geht es darum was es wirklich bedeutet, wann es den Aufwand wert ist, wann nicht, und wie ich Shops auf Solidus so baue dass die App Frage eine günstige Antwort hat, wann immer sie auftaucht.
Die Frage die nach etwa achtzehn Monaten kommt
Es gibt ein Gespräch das ich so oft geführt habe dass ich es vertonen könnte. Ein Shop ist seit etwa achtzehn Monaten live. Er läuft gut. Und dann sagt jemand im Unternehmen, meistens nach einer Messe oder einem Gespräch mit einem Mitbewerber, das Wort App. Oder Marktplatz. Oder Kiosk für den Showroom. Oder eine zweite Marke die denselben Bestand über eine anders aussehende Seite verkaufen soll.
Und der Inhaber ruft mich an und fragt wie schwer das wäre.
Die ehrliche Antwort hängt fast vollständig von einer Entscheidung ab die getroffen wurde, oder öfter nicht getroffen wurde, bevor der Shop gebaut wurde: ob der Shop als Website gebaut wurde die zufällig Dinge verkauft, oder als System das Dinge verkauft und zufällig eine Website davor hat. Diese Unterscheidung ist das was Leute mit Headless meinen, wenn sie überhaupt etwas damit meinen.
In diesem Artikel geht es darum was es wirklich bedeutet, wann es den Aufwand wert ist, wann nicht, und wie ich Shops auf Solidus so baue dass die App Frage eine günstige Antwort hat, wann immer sie auftaucht. Den allgemeinen Fall für die Plattform habe ich im Solidus Vergleich geschrieben. Dieser hier ist enger und, glaube ich, nützlicher wenn du schon weißt dass du auf etwas baust das dir gehört.
Was Headless wirklich bedeutet, in einem Satz
Das Storefront ist ein Client des Shops. Es ist nicht der Shop.
Das ist die ganze Idee. Alles andere ist Detail, und das meiste Detail sind Anbieter die es aufhübschen.
In einem konventionellen Shop ist das Ding das die Produktseite rendert dasselbe Ding das weiß was das Produkt kostet, ob es auf Lager ist, welche Aktionen gelten und was passiert wenn du auf "In den Warenkorb" drückst. Die Regeln und die Pixel leben zusammen. Das ist in Ordnung, genau bis du einen zweiten Satz Pixel willst, und dann entdeckst du dass die Regeln mit dem ersten Satz verflochten sind und du sie entweder duplizieren oder auseinanderziehen musst.
In einem Headless Shop leben die Regeln an einem Ort und zeigen sich über eine Schnittstelle, fast immer eine JSON API über HTTP. Die Website redet mit dieser Schnittstelle. Die App auch. Der Marktplatz Feed auch, der Kiosk, der Partner der deinen Bestand auf seiner Seite verkaufen will, und das interne Tool das dein Lager benutzt. Keiner davon weiß irgendetwas über Preise oder Bestand oder Aktionen. Sie fragen, und es wird ihnen gesagt.
Wenn du jemals die Website deiner Bank und ihre App benutzt hast und gemerkt hast dass dein Kontostand in beiden derselbe ist, hast du ein Headless System benutzt. Der Kontostand ist nicht in der App. Die App fragt.
Headless das Marketingwort versus Headless der Vertrag
Jetzt der Teil den die Anbieter dir nicht erzählen.
Fast jede Plattform am Markt sagt inzwischen dass sie headless ist. Shopify hat eine Storefront API. Shopware hat eine Store API. Sogar WooCommerce hat eine Art REST API. Im Marketingsinn ist also jeder headless, und das Wort hat aufgehört etwas zu bedeuten.
Was zählt ist nicht ob eine API existiert. Es ist ob die API der Vertrag ist, also das Ding durch das jeder Client tatsächlich geht, oder eine Seitentür die neben der echten Logik angeschraubt wurde. Der Unterschied zeigt sich in drei Fragen.
Erstens: benutzt das eigene Storefront der Plattform die API? Wenn die Website des Anbieters über einen anderen, privilegierten Pfad geht und die öffentliche API eine Übersetzung davon ist, dann hinkt die API immer hinterher. Features landen zuerst auf der Website und erreichen die API wenn jemand dazu kommt. Du findest das heraus wenn die Aktion die du konfiguriert hast im Web funktioniert und in der App nicht.
Zweitens: kannst du über die API alles tun was du über den Admin tun kannst? Eine Bestellung mit individuellem Preis anlegen, eine Aktion anwenden die nicht für Selbstbedienung gedacht war, eine Lieferung aufteilen, einen Teil einer Position erstatten. Wenn die Antwort "das meiste" lautet, lautet die Antwort nein.
Drittens: wem gehört die API? Wenn sie dem Anbieter gehört, kann er sie drosseln, versionieren, abkündigen und dafür Geld verlangen, und er wird irgendwann alle vier Dinge tun. Wenn sie dir gehört, in deiner Codebasis, auf deinem Server, dann ändert sie sich wenn du sie änderst.
Solidus besteht, das muss man ihm lassen, die ersten beiden und ist eine der wenigen Plattformen bei denen die dritte eindeutig ist, weil es keinen Anbieter gibt. Die API ist eine Rails Engine die mit dem Kern ausgeliefert wird, und das Storefront das ich baue ist einfach ein weiterer Konsument derselben Modelle. Darauf komme ich zurück.
Wann Headless sich lohnt
Ich werde konkret, denn "Flexibilität" ist kein Business Case.
Du willst eine Mobile App. Das ist der große Fall und der Grund warum der Artikel den Titel hat den er hat. Eine App ist ein zweites Storefront das zufällig auf einem Telefon läuft. Sie braucht den Katalog, den Warenkorb, den Checkout, das Konto, die Bestellhistorie, und sie braucht das alles so dass es sich genau wie die Website verhält, weil derselbe Kunde beides nutzt. Ohne API baust du das alles zweimal, und die zweite Kopie driftet innerhalb eines Quartals von der ersten weg. Zur App selbst sage ich am Ende mehr.
Du willst auf Marktplätzen oder über Partner verkaufen. Amazon, Kaufland, Otto, das Fachportal deiner Branche, ein Händler der dein Sortiment listen will. Jeder davon will einen Feed mit Produkten und Beständen und will Bestellungen zurückschieben. Das ist eine API in beide Richtungen. Einen Feed Export an einen Shop zu schrauben der nicht dafür gebaut wurde bedeutet meistens ein nächtliches CSV und einen Bestand der dreiundzwanzig Stunden am Tag falsch ist.
Du willst eine zweite Marke auf demselben Katalog. Ein Premium und ein Preiseinstiegs Label. Eine B2B Seite und eine Endkundenseite. Ein deutscher Shop und ein Schweizer mit anderen Preisen und anderen Rechtstexten. Wenn die Regeln an einem Ort leben, ist das zweite Storefront eine Designaufgabe. Wenn sie in den Templates leben, ist es ein zweiter Shop.
Du hast eine physische Präsenz. Einen Showroom, einen Marktstand, einen Pop up Store. Ein Kiosk oder ein Tablet an der Kasse das aus demselben Bestand verkauft, zu denselben Preisen, mit denselben Aktionen, und die Bestellung ins selbe System legt damit das Lager eine einzige Warteschlange sieht. Das ist ein API Client. Ein günstiger, sobald die API existiert.
Deine Systeme müssen miteinander reden. ERP, Lagerverwaltung, Buchhaltung, ein CRM, ein Mail Tool das von abgebrochenen Warenkörben wissen will. Jede Integration ist leichter wenn es einen gut dokumentierten Weg in den Shop hinein und hinaus gibt, und fast unmöglich sauber zu halten wenn sich jede ihren eigenen Pfad durch die Datenbank kratzt.
Wenn zwei oder mehr davon auf deiner Roadmap stehen, und ich meine wirklich darauf stehen und nicht einmal in einem Meeting erwähnt wurden, ist die API nicht optional. Sie ist das was den Rest bezahlbar macht.
Wann Headless sich nicht lohnt
Hier die andere Seite, denn ich habe Leuten zugeschaut die echtes Geld für Architektur ausgegeben haben die sie nie genutzt haben.
Ein einzelnes Storefront und keine Pläne. Wenn du über eine Website verkaufst, keine Absicht hast eine App zu bauen, nicht auf Marktplätzen verkaufst und deine Integrationen Stripe und ein Mail Anbieter sind, dann ist ein vollständig entkoppelter Headless Aufbau eine Steuer. Du wartest zwei Anwendungen statt einer, ein Frontend und ein Backend, deployst sie getrennt, debuggst sie getrennt und zahlst zweimal Hosting. Für nichts.
Ein kleines Team. Vollständig headless heißt ein JavaScript Frontend das mit einem Ruby Backend redet, und das heißt zwei Skillsets, zwei Build Pipelines und zwei Orte an denen sich ein Fehler verstecken kann. Ein Team aus ein oder zwei Leuten fährt mit einer Anwendung besser.
Ein großer Katalog der von Suchtraffic lebt. Das ist der Fall der Leute überrascht. Wenn dein Umsatz davon abhängt dass Google zehntausend Produktseiten findet, brauchst du diese Seiten serverseitig gerendert, schnell, mit korrekten strukturierten Daten, und es muss langweilig sein. Ein clientseitig gerendertes Frontend kann das, mit Aufwand, über serverseitige Rendering Frameworks, aber jetzt hast du eine Rendering Schicht hinzugefügt um ein Problem zu lösen das die Rails Anwendung nie hatte. Ich habe Shops gesehen die in einer "Headless Migration" ein Drittel ihres organischen Traffics verloren und ein Jahr gebraucht haben um es zurückzuholen.
Weil die Agentur es gesagt hat. Vollständig entkoppelte Aufbauten sind teurer, dauern länger und brauchen mehr Leute. Das sind drei Gründe warum eine Agentur sie mögen könnte, die nichts mit deinem Geschäft zu tun haben.
Die Antwort ist also nicht headless oder nicht. Die Antwort ist die Variante von Headless die dir den Vertrag gibt ohne die Kosten zwei Anwendungen zu betreiben. Womit ich bei dem bin was ich tatsächlich baue.
Der Hybrid den ich tatsächlich baue
Jeder Shop den ich baue hat dieselbe Form, und ich bin dort angekommen indem ich es in beide Richtungen falsch gemacht habe.
Es gibt eine Rails Anwendung. Sie enthält den Solidus Kern, dem Produkte, Varianten, Preise, Bestände, Aktionen, Bestellungen, Zahlungen, Lieferungen und Steuern gehören. Sie enthält ein serverseitig gerendertes Storefront, also gewöhnliche Rails Controller und Views die HTML erzeugen, das ist was deine Kunden sehen und was Google indexiert. Und sie enthält eine JSON API, einen zweiten Satz Controller die dieselben Modelle für alles freigeben was kein Browser ist.
Der wichtige Teil ist was diese beiden Sätze Controller gemeinsam haben, nämlich alles darunter.
Wenn ein Kunde auf der Website einen Geschenkkorb in den Warenkorb legt, ruft der Storefront Controller dasselbe Service Objekt auf das der API Controller aufruft wenn die App es tut. Dieselben Aktionsregeln laufen. Dieselbe Bestandsprüfung passiert. Derselbe Positionsvergleich entscheidet ob das eine neue Position ist oder eine Mengenerhöhung einer bestehenden. Es gibt keine Möglichkeit dass Web und App sich widersprechen, weil es keine zweite Implementierung gibt die widersprechen könnte.
Ich nenne das API first obwohl das Storefront im HTTP Sinn kein Client der API ist. Es ist API first weil die API von Anfang an als vollwertiger Bürger entworfen wird, die Regeln aus den Views herausgehalten werden, und nichts was das Storefront kann über die API unmöglich ist. Wenn ich später entscheiden würde das Storefront als JavaScript Anwendung neu zu bauen, könnte ich das, und es würde mit denselben Endpunkten reden wie die App. Ich habe es nie gebraucht.
Was du davon hast ist eine Anwendung zum Deployen, eine zum Überwachen, eine zum Absichern, eine zum Testen. Serverseitig gerenderte Seiten für Suche und Geschwindigkeit. Und in dem Moment in dem jemand App sagt, lautet die Antwort "die API ist schon da, wir müssen die App bauen", und das ist ein anderes Gespräch als "wir müssen die API bauen und dann die App".
Was Solidus dir am ersten Tag gibt
Solidus wird mit einer API Engine als Teil des Kerns ausgeliefert. Sie ist keine Erweiterung die du installieren könntest oder auch nicht. Von Haus aus bekommst du das meiste von dem was ein Client braucht.
Katalog Endpunkte. Produkte, Varianten, Taxons, Bilder, Preise, Bestände. Paginiert, filterbar, und mit genug Inhalt dass sich eine Produktliste in einer App direkt daraus bauen lässt.
Warenkorb und Checkout. Bestellung anlegen, Positionen hinzufügen und entfernen, die Bestellung durch ihre Zustände führen, Adressen setzen, Versandart wählen, Zahlung hinzufügen, abschließen. Die Zustandsmaschine die den Web Checkout treibt ist dieselbe die die API treibt. Wenn dein Web Checkout einen individuellen Schritt hat, und meine haben das meistens, hat die API diesen Schritt auch, weil der Schritt in der Bestellung lebt, nicht in der View.
Konten und Authentifizierung. Jeder Nutzer bekommt einen API Schlüssel. Clients schicken ihn als Bearer Token. Gastbestellungen funktionieren mit einem Bestell Token. Wenn du etwas Aufwändigeres willst, eine Mobile App will meistens kurzlebige Tokens mit Refresh, sind die Bausteine da um es darauf zu bauen.
Admin Operationen. Bestellungen, Lieferungen, Erstattungen, Bestandsbewegungen, Aktionsverwaltung. Alles was dein Lager Tool oder deine Buchhaltungsintegration tun muss ist freigegeben, und es respektiert dieselben Berechtigungen wie deine Admin Nutzer.
Ein Event Bus. Solidus veröffentlicht Ereignisse wenn Dinge passieren: eine Bestellung wird abgeschlossen, eine Lieferung geht raus, eine Zahlung schlägt fehl. Du abonnierst diese Ereignisse und tust was du brauchst, was bei Integrationen meistens heißt einen Webhook an das System von jemand anderem zu schicken. Es gibt keinen eingebauten Manager für ausgehende Webhooks, und ich habe ihn nie vermisst, weil ein Abonnent der JSON verschickt fünfzehn Zeilen ist und ich ihn testen kann.
Das ist viel für umsonst, und es ist der Grund warum ich sage die API ist vom ersten Tag da und nicht etwas das du hinzufügst.
Was du selbst entwerfen musst
Und hier ist was du nicht bekommst, der Teil bei dem ein Angebot ehrlich sein sollte.
Versionierung. In dem Moment in dem eine App im Store ist, kannst du eine API Antwort nicht mehr ändern ohne Telefone kaputt zu machen die du nicht kontrollierst. Irgendjemand wird die Version von vor acht Monaten laufen haben. Du brauchst eine Versionierungsstrategie bevor die erste App ausgeliefert wird, ob das eine Version in der URL ist, ein Header, oder die Regel Felder nur jemals hinzuzufügen und nie zu entfernen. Ich mache meistens Letzteres, mit einem harten Versionssprung für die seltene Änderung die nicht additiv sein kann.
Rate Limits. Eine öffentliche API wird von Dingen getroffen die nicht deine App sind. Scraper, Mitbewerber, die fehlerhafte Integration eines Partners die jede Sekunde neu versucht. Du brauchst Limits pro Client, und sie müssen höflich mit einem ordentlichen Statuscode scheitern statt durch Umfallen. Rack Attack, eine kleine Konfiguration, und ein Ort an dem du siehst wer was trifft.
Caching. Produktdaten ändern sich selten und werden ständig gelesen. Eine App die den Katalog jedes Mal holt wenn jemand sie öffnet, lässt deinen Server härter arbeiten als deine Website es tut. HTTP Caching Header, bedingte Anfragen und eine Cache Schicht für die leseintensiven Endpunkte sind nicht optional sobald echter Traffic kommt.
Idempotenz für alles was Geld kostet. Dem gebe ich unten einen eigenen Abschnitt, denn das ist der Punkt der weh tut.
Bildauslieferung. Eine App will Bilder in drei oder vier Größen, in modernen Formaten, von einem CDN, schnell. Solidus speichert Bilder und kann Varianten auf Abruf erzeugen, aber die Auslieferungspipeline, das CDN davor und die URLs die die API herausgibt sind Designentscheidungen die du einmal triffst und mit denen du lebst.
Suche. Die Katalog Endpunkte filtern, aber sie sind keine Suchmaschine. Wenn deine App "drei Buchstaben tippen und Vorschläge sehen" braucht, brauchst du einen Suchindex und einen Endpunkt davor. Ich füge das hinzu wenn der Katalog es rechtfertigt und nicht vorher.
Dokumentation. Nicht für dich. Für die Person die die App baut nachdem die Person die sie gebaut hat gegangen ist. Eine API ohne schriftlichen Vertrag ist eine mündliche Vereinbarung, und mündliche Vereinbarungen überleben keinen Personalwechsel. Ich erzeuge die Doku aus den Tests, das beschreibe ich in meinem Artikel über das Testen von APIs.
Nichts davon ist schwer. Alles davon habe ich schon fehlen sehen, und jedes fehlende Stück wird später zu einem Umbau.
The Gift Bow als durchgehendes Beispiel
Ich mache das konkret mit dem ersten meiner Demo Shops, einem Geschenk und Präsentkorb Shop namens The Gift Bow. Ich habe ihn teils gebaut um einen echten Shop zum Vorzeigen zu haben und teils um zu sehen wie weit die Disziplin "API bereit vom ersten Tag" trägt wenn die Features ungewöhnlich werden. Sie wurden ungewöhnlich.
Der Shop ist zweisprachig, Englisch und Deutsch, mit der Sprache beim ersten Besuch aus dem Browser und dann aus dem Land des Besuchers gewählt. Er hat fünf explizite Preislisten, in Pfund, Euro, US, australischen und neuseeländischen Dollar, mit ordentlichen Schwellenpreisen in jeder statt einer umgerechneten Zahl, und die Währung folgt ebenfalls dem Land des Besuchers. Er hat einen Korb zum Selbstzusammenstellen, bei dem du einen Behälter zu einem festen Preis wählst, sagen wir sechzig Pfund für sechs Artikel oder hundert für acht mit höchstens zwei Flaschen, und ihn aus dem Katalog füllst. Der gewählte Inhalt reist als strukturierte Daten auf der Position mit, und der Warenkorb weiß dass zwei Körbe mit unterschiedlichem Inhalt zwei verschiedene Dinge sind, nicht Menge zwei. Die Startseite hat Aktionskarten die im Admin gepflegt werden, mit Zeitplanung, damit die Festtagskollektion im Oktober angelegt werden und am ersten November erscheinen kann ohne dass jemand etwas anfasst. Manche Produkte lassen sich im Abo mit Rabatt in einem gewählten Intervall kaufen. Lieferregeln variieren nach Region.
Jedes dieser Features wurde als Regel auf der Bestellung oder dem Produkt gebaut, nicht als View. Das war die Disziplin, und sie hat sich auf Arten ausgezahlt die ich nicht erwartet hatte.
Die Währungs und Sprachauswahl ist kein Storefront Trick. Sie ist eine Preisoption auf der Bestellung, das heißt eine App die sagt "dieser Kunde ist in Österreich" bekommt Europreise und deutschen Text vom selben Endpunkt den das Web nutzt, ohne eine Zeile App spezifischer Logik. Der Korb Konfigurator ist ein Service der eine Behältervariante und eine Liste von Auswahlen nimmt und eine Position mit angehängtem Inhalt erzeugt. Das Webformular ruft ihn auf. Eine App würde ihn über die API mit einem JSON Body aufrufen der fast genauso aussieht wie das Formular. Der Positionsvergleich, die Regel die sagt "diese zwei Körbe sind verschieden", lebt im Modell, also verhält sich ein über die API angelegter Warenkorb identisch zu einem im Web angelegten. Die Aktionskarten sind Datensätze mit Start und Enddatum; ein App Startbildschirm kann die aktiven holen und nativ rendern, und sie wechseln im selben Moment wie die Website.
Ich habe keine App für The Gift Bow gebaut. Ich brauche keine. Der Punkt ist: wenn ich prüfe was es bräuchte, lautet die Antwort: die Bildschirme entwerfen, die App bauen, auf das zeigen was schon da ist. Es gibt keine Phase "zuerst müssen wir die Geschäftsregeln aus den Templates herausziehen", und diese Phase ist der Ort an den das Geld geht bei Shops die andersherum gebaut wurden.
Zahlungen, Idempotenz und die doppelte Belastung die niemand will
Das ist der Abschnitt den ich jeden Inhaber lesen lassen würde wenn ich nur einen wählen dürfte.
Auf einer Website passiert eine Zahlung einmal, weil der Browser ein Formular einmal abschickt und dann eine Bestätigungsseite zeigt. Wenn die Verbindung nach der Zahlung aber vor der Bestätigung abbricht, sieht der Kunde einen Fehler, lädt neu und findet seine Bestellung meistens in seinem Konto. Ärgerlich, aber selten und behebbar.
Auf einer Mobile App brechen Verbindungen ständig ab. Tunnel, Aufzüge, der Weg vom Büro zum Parkplatz. Eine App die "schließe diese Bestellung mit dieser Zahlung ab" schickt und nichts zurückhört, wird, wenn sie naiv geschrieben ist, es noch einmal schicken. Jetzt wurde der Kunde zweimal belastet, oder die Bestellung existiert zweimal, und du erfährst es aus einer Bewertung mit einem Stern.
Die Lösung ist ein gut verstandenes Muster namens Idempotenz. Die App erzeugt für jeden Versuch einen eindeutigen Schlüssel, schickt ihn mit der Anfrage, und der Server merkt sich welche Schlüssel er schon verarbeitet hat. Ein Wiederholungsversuch mit demselben Schlüssel gibt das ursprüngliche Ergebnis zurück statt die Arbeit noch einmal zu tun. Stripe nutzt genau das auf seiner eigenen API, deshalb kannst du einen Stripe Aufruf gefahrlos wiederholen.
Solidus macht das auf seinen Checkout Endpunkten nicht für dich. Es sind ein paar Dutzend Zeilen: eine Tabelle gesehener Schlüssel, eine Prüfung am Anfang der Abschlussaktion, eine gespeicherte Antwort. Ich füge es jedem Shop hinzu bei dem ein API Client jemals eine Bestellung abschließen könnte, also jedem Shop, denn das Hinzufügen kostet eine Stunde und das Fehlen kostet einen Kunden den du nie wiedersiehst und eine Erstattung die dein Buchhalter erklären muss.
Wo wir schon dabei sind: dasselbe gilt für alles was Bestand ändert, eine Mail verschickt oder etwas erzeugt das der Kunde sehen wird. Jeder Endpunkt mit einem Nebeneffekt muss sicher zweimal aufrufbar sein.
Bilder, Suche und die Dinge die Leute vergessen
Zwei kleinere Punkte die immer spät auftauchen.
Zuerst Bilder. Eine Webseite lädt ein Produktbild einmal, in der Größe die das Layout braucht. Eine App auf einem schnellen Telefon will ein Vorschaubild im Raster, ein mittleres Bild auf dem Produktbildschirm und ein großes wenn du zum Zoomen zwickst, und sie will sie gecacht damit das Scrollen sofort geht. Wenn die API eine URL auf ein großes Original herausgibt, ist die App langsam und der Server mit Skalieren beschäftigt. Wenn die API einen Satz URLs auf vorab erzeugte Größen auf einem CDN herausgibt, ist die App schnell und der Server sieht die Anfrage nie. Das ist eine Entscheidung darüber wie die API ein Bild beschreibt, und sie muss getroffen werden bevor der erste Client geschrieben wird, denn sie nachträglich zu ändern heißt jeden Client zu ändern.
Dann Suche. Die API kann Produkte nach Taxon filtern, nach Preisspanne, nach Namen der einen String enthält. Das reicht für einen Kategoriebildschirm. Es reicht nicht für ein Suchfeld, denn ein Suchfeld braucht Tippfehlertoleranz, Ranking und Ergebnisse in unter hundert Millisekunden. Dafür brauchst du einen Index, der Index muss mit dem Katalog synchron gehalten werden, und die Synchronisation muss getestet werden. Es ist ein Projekt, ein kleines, und der Fehler ist nicht es zu machen. Der Fehler ist der App ein Suchfeld zu versprechen bevor es auf der API existiert.
Was es kostet es später zu machen
Ich will eine Zahl auf den Unterschied setzen, denn "bau es gleich beim ersten Mal richtig" ist ein Rat den jeder gibt und niemand beziffert.
Einen Solidus Shop so zu bauen dass die Regeln in Services und Modellen leben und die API ein vollwertiger Konsument ist, kostet nach meiner Erfahrung irgendwo zwischen fünf und zehn Prozent mehr beim Aufbau. Das ist der Preis der Disziplin: ein Service Objekt statt Logik im Controller, ein Test der den API Endpunkt genauso prüft wie das Webformular, eine früh getroffene Entscheidung über Bild URLs. Bei einem Aufbau für sechzigtausend Euro sind das drei bis sechstausend.
Eine API nachträglich auf einen Shop zu setzen in dem die Regeln in die Views hineingewachsen sind, ist eine andere Art von Projekt. Du fügst keine API hinzu. Du findest jeden Ort an dem eine Geschäftsregel lebt, das sind meistens mehr Orte als irgendjemand sich erinnert, ziehst jede davon in etwas heraus das Web und API beide aufrufen können, und tust das ohne das Verhalten eines laufenden Shops zu verändern. Es ist Archäologie mit Abgabetermin. Ich habe es dreimal gemacht und es hat nie unter einem Drittel der ursprünglichen Aufbaukosten gelegen, zweimal war es näher an der Hälfte.
Die ehrliche Rechnung lautet also: fünf bis zehn Prozent jetzt, oder dreißig bis fünfzig Prozent später, plus die Verzögerung, plus das Risiko etwas kaputt zu machen das funktioniert. Und das ist vor der App selbst, die so oder so dasselbe kostet.
Der Grund warum Leute "später" wählen ist nicht dass sie diese Rechnung gemacht und sich dagegen entschieden haben. Es ist dass ihnen am Anfang niemand die Option vorgelegt hat. Betrachte das hier als mich der sie dir vorlegt.
Was "API bereit vom ersten Tag" in der Praxis heißt
Da ich den Ausdruck ständig benutze, hier was er bei einem Aufbau tatsächlich bedeutet, in der Reihenfolge in der ich es mache.
Geschäftsregeln gehören in Services und Modelle, nie in Views oder Controller. Wenn ein Controller mehr tut als Eingaben entgegenzunehmen, etwas aufzurufen und zu rendern, ist er falsch.
Jedes Feature das das Web Storefront kann bekommt einen API Test genauso wie einen Web Test. Keine vollständige zweite Implementierung, nur ein Test der beweist dass der Endpunkt dasselbe tut. Das ist die Prüfung die Drift verhindert.
Antworten werden so entworfen dass man ihnen etwas hinzufügen kann, aber sie nie ändert. Neue Felder sind in Ordnung. Ein Feld umzubenennen oder zu entfernen ist ein Versionssprung, und Versionssprünge sind selten und bewusst.
Alles was Geld kostet oder einen Nebeneffekt hat akzeptiert einen Idempotenzschlüssel.
Bilder werden als Satz von Größen auf einem CDN beschrieben, nicht als ein Original.
Es gibt einen Rate Limiter und einen Ort an dem man sieht wer was trifft.
Der Vertrag ist aufgeschrieben, aus den Tests erzeugt damit er nicht veralten kann.
Nichts davon ist exotisch. Es ist der Unterschied zwischen einem Shop der ein zweites Gesicht bekommen kann und einem der es nicht kann, und es kostet fast nichts wenn du so anfängst.
Die App selbst, kurz
Ich habe sehr wenig über die App gesagt, absichtlich, denn die App ist der einfache Teil sobald das Fundament stimmt. Weil Leute fragen: ich baue sie in React Native, eine Codebasis für iOS und Android, die mit derselben API redet wie alles andere. Eine App für einen Shop mit solider API ist ein Design und Bauprojekt das in Wochen gemessen wird. Dieselbe App für einen Shop ohne API wird in Quartalen gemessen, und die meisten dieser Quartale gehen in den Shop, nicht in die App.
Ob du überhaupt eine App haben solltest ist eine eigene Frage, und meine Antwort ist vorsichtiger als du von jemandem erwarten würdest der sie baut. Die meisten Shops brauchen keine. Geschäfte mit Wiederkauf, Abo Geschäfte, alles bei dem der Kunde monatlich wiederkommt und Push Benachrichtigungen und einen gespeicherten Warenkorb schätzen würde, die profitieren. Ein Shop der jemandem alle sieben Jahre ein Sofa verkauft nicht. Das schreibe ich ein andermal ordentlich auf.
Wo dich das hinlässt
Wenn du einen neuen Shop baust, bestehe auf dem Hybrid. Eine Anwendung, serverseitig gerendertes Storefront, vollwertige API, Regeln an einem Ort. Bitte deinen Entwickler dir die API Tests neben den Web Tests zu zeigen, und frag was passiert wenn die App eine Zahlung wiederholt. Wenn er verständnislos schaut, frag weiter.
Wenn du schon einen Shop hast und die App Frage angekommen ist, lass jemanden anschauen wo die Regeln leben bevor irgendjemand die App anbietet. Das Angebot für die App ist nur die halbe Zahl, und es ist die kleinere Hälfte wenn der Shop als Website gebaut wurde die zufällig Dinge verkauft.
Und wenn du sehen willst wie API bereit vom ersten Tag mit echten Features aussieht: die Demo Shops sind live, der Korb Konfigurator funktioniert, und ich gehe den Code gerne mit dir durch.