English
العربية
Deutsch
EspañolNext.js in München
Next.js-Entwicklung für Münchner Unternehmen
Eine Next.js-Agentur für Münchner Teams. Versicherung, Automotive und Industrie als Käufer, ein Einkauf, der länger dauert als die Umsetzung, und ein Sicherheitsfragebogen vor dem ersten Commit.
- Überschneidung der Arbeitszeit
- Sieben Stunden, wie Berlin - eine Stunde hinter Ankara
- Wer hier kauft
- Versicherer, Automotive, Industrie und die Beratungen, die sie bedienen
- Was das ändert
- Einkauf, Sicherheitsprüfung und Lieferanten-Onboarding liegen auf dem kritischen Pfad, meist vor der Entwicklung
- Lokale Besonderheiten
- Self-Hosting und Datenstandort kommen in fast jedem Projekt auf, und die Antwort muss einen Fragebogen überstehen
München kauft Entwicklung über einen Prozess ein. Das ist der Unterschied zu Berlin, und es ist keine Klage, sondern das, worum herum ein Projekt gebaut gehört.
Die Käufer hier sind Versicherer, Hersteller, Automobilzulieferer und die Beratungen, die an sie verkaufen. Es gibt einen Einkauf, ein Lieferanten-Onboarding, Sicherheitsfragebögen und ein Architekturgremium. Die technischen Entscheidungen sind selten der schwierige Teil des Zeitplans.
Was diese Projekte wirklich aufhält
Ehrlich: nicht der Code. Es ist das Warten auf eine Staging-Umgebung, auf Verzeichniszugang, auf einen Sicherheitsfragebogen, auf die eine Person, die eine Firewall-Regel freigeben darf.
Deshalb fragen wir in der ersten Woche, welche Freigaben die längste Vorlaufzeit haben, und schneiden die Phasen so, dass eine blockierte Abhängigkeit eine Phase stoppt und nicht das Projekt. Das klingt nach Projektsteuerung statt nach Technik - und es ist das Einzelne, das am stärksten darüber entscheidet, ob ein Enterprise-Projekt pünktlich landet.
Das Zweite: Entscheider und Prüfer sind verschiedene Leute. Freigegeben wird ein Dokument, gepflegt wird ein Repository. Eine Architekturnotiz, die erklärt, warum welche Route wie rendert, bedient beides - deshalb schreiben wir eine, statt Folien zu bauen.
Self-Hosting ist hier die Regel, nicht die Ausnahme
Die Standardregion einer Plattform ist keine Antwort auf einen Vertrag, der festlegt, wo Daten liegen. In München kommt diese Frage früh und von der juristischen Seite, nicht von der technischen.
Also laufen die meisten dieser Anwendungen als Container im Cluster des Kunden, in dessen Region, neben dessen Datenbank. Das ist eine völlig vernünftige Art, Next.js zu betreiben, und sie hat vier konkrete Kosten, die man besser am Anfang kennt als in Woche neun: Bildoptimierung muss geregelt werden, Revalidierung braucht einen über Replikate geteilten Cache, Middleware läuft nicht mehr am Edge, und ein puffernder Reverse Proxy macht Streaming kaputt.
Alle vier stehen in Next.js selbst betreiben, und was dabei aufhört zu funktionieren. Keine davon ist schwierig. Alle sind billiger geplant als nachgerüstet.
Identität ist meist schon entschieden
Unternehmen hier haben einen Identity Provider, und die Anwendung schließt sich an. Das ist einfacher, als Authentifizierung zu bauen, und es ist eine andere Art Arbeit: die Anbindung, das Mapping von Gruppen auf Rollen, und der Teil, auf den es ankommt - dass Autorisierung an den Daten durchgesetzt wird und nicht an der Route.
Ein Route Guard ist eine Weiterleitung. Er ist kein Berechtigungsmodell, und der Unterschied zeigt sich beim ersten API-Aufruf, der nicht über die Oberfläche kommt.
Die Formalitäten gehören zum Projekt
Vertragspartner ist die Codefacture Yazılım A.Ş. mit Sitz in der Türkei. Rechnungen kommen von dort, in Euro, per Überweisung, ohne türkische Umsatzsteuer, weil exportierte Leistungen davon befreit sind.
Ein Sicherheitsfragebogen wird fragen, wo Daten liegen, wer die Unterauftragnehmer sind und was am Ende des Projekts damit passiert. Das ist beantwortbar, und es geht schneller, es vor dem Zuschnitt zu beantworten als während.
Der regulatorische Rahmen - BFSG, Impressum, was der deutsche Datenschutz bis ins Schema hinein verlangt - steht auf der Länderseite Deutschland und wird hier nicht wiederholt.