Warum TanStack Start auf Adapter verzichtet

von Tanner Linsley am 22. Nov. 2024.

Der Aufbau eines neuen Frontend-JavaScript-Frameworks ist eine entmutigende Aufgabe, wie ich bei der Entwicklung von TanStack Start, meinem neuen, von TanStack unterstützten Full-Stack-Framework, feststelle. Es gibt so viele bewegliche Teile

• Routing
• Server-Side Rendering
• RPCs & APIs
• Entwicklungswerkzeuge
• Bereitstellung & Hosting

Letzterer Punkt, **Bereitstellung & Hosting**, kann besonders knifflig sein, da heutzutage jede Cloud-Umgebung ihre eigenen eigenartigen Zaubersprüche zu haben scheint, um Dinge „genau richtig“ zum Laufen zu bringen. Als ich diese Entscheidung für TanStack Start traf, wusste ich offensichtlich, welche Hosts ich von Anfang an unterstützen wollte, und Vercel stand ganz oben auf dieser Liste.

Meine erste Reaktion war, ein System zu entwickeln, das für jeden Host „Adapter“ haben könnte, und dann einfach damit zu beginnen, den Vercel-Adapter zu schreiben.

Dieser Plan war jedoch von Anfang an fehlerhaft. Es dauerte nicht lange, bis mir klar wurde, dass ich persönlich (zumindest am Anfang) dafür verantwortlich sein würde, den Großteil, wenn nicht den gesamten Code zu schreiben, um TanStack Start auf Vercel, aber auch auf vielen anderen Zielen und Plattformen zum Leben zu erwecken. Nach kurzer Recherche war diese Aufgabe allein entmutigend genug, um meine Motivation für die Entwicklung eines servergebundenen JS-Frameworks überhaupt in Frage zu stellen.

Technisch gesehen ist die Arbeit, die allein für die Bereitstellung auf Vercel erforderlich ist, bereits sehr einfach, indem man einfach einige Namenskonventionen für Ausgabe-Dateien/Verzeichnisse einhält. Die Lähmung kam jedoch von der schieren Anzahl der zu unterstützenden Umgebungen/Hosts. Es gibt viele! Schauen Sie sich einfach die wachsende Liste von Server-Adaptern von Remix an! Remix ist nicht das einzige Framework mit dieser Liste. Die meisten servergebundenen JS-Frameworks haben etwas Ähnliches. Ich hätte mich im Grunde verpflichtet, in den ersten Monaten des Frameworks mindestens 10 Adapter zu schreiben, und ich war kaum in die spannenden Funktionen des Frameworks selbst eingestiegen (ganz zu schweigen von der Arbeit an der Wartung und Aktualisierung dieser Adapter).

Die harte Realität hier ist, dass es **keinen Weg darum herum gibt.** Wenn Ihr Framework **irgendeinen serverseitig ausgerichteten Code in Ihrem Framework bereitstellt, müssen Sie sicherstellen, dass er überall perfekt läuft, wo Sie ihn bereitstellen können.**

Als ich mich also der unendlichen Traurigkeit des Schreibens von hundert Adaptern und dem Umgang mit Upstream-Breaking-Changes für den Rest meines Lebens hingeben wollte, sprach ich mit meinem Freund Ryan Carniato darüber, wie Solid JS dieses Problem mit unserem Cousin-Framework Solid Start angeht, und er sagte zuversichtlich: „Benutze einfach Vite und Nitro".

Nitro ist ein „JavaScript-Toolkit zum Erstellen von serverseitigen Frameworks mit Ihren eigenen Meinungen“, angetrieben von Vite. Was macht es also so besonders?

Es gibt eine Menge toller Funktionen in Nitro, die es extrem nützlich für den Aufbau eines Frameworks machen, aber einer der coolsten Teile ist, dass es von H3 und Vite angetrieben wird. Nitros Tagline lautet buchstäblich: „Erstellen Sie Webserver mit allem, was Sie brauchen, und **bereitstellen Sie sie, wo immer Sie möchten**“ (Hervorhebung von mir).

Einfach ausgedrückt, macht Nitro TanStack Start effektiv „*adapterlos*“. Es verwendet H3, ein HTTP-Framework, das seine eigenen Low-Level-Adapter in Ihrem Namen pflegt, sodass Sie Ihren Servercode einmal schreiben und überall verwenden können (klingt ein bisschen wie React!).

Durch die Verwendung von Nitro waren alle Adapterprobleme von TanStack Start verschwunden. Ich musste nie darüber nachdenken!

Tatsächlich war die Bereitstellung auf Vercel sogar noch einfacher als ursprünglich geplant: Übergeben Sie einfach ein vercel-Ziel an die Option server.preset unseres defineConfig, das an Nitro übergeben wird.

import { defineConfig } from '@tanstack/react-start/config'

export default defineConfig({
  server: {
    preset: 'vercel',
  },
})

import { defineConfig } from '@tanstack/react-start/config'

export default defineConfig({
  server: {
    preset: 'vercel',
  },
})

Nitro, H3 und Vite sind **gelinde gesagt beeindruckend.** Wir waren erfreut festzustellen, dass auf Anhieb eine Reihe von Vercel-Funktionen perfekt funktionierten, darunter die GitHub-Integration, Serverfunktionen, Edge-Funktionen/Middleware, unveränderliche Bereitstellungen, Umgebungsvariablen, serverseitiges Rendering und sogar Streaming.

Das ist eine riesige Liste, die wir im Wesentlichen kostenlos durch die Verwendung von Nitro und Vite erhalten haben.

Mit gelösten Build- und Bereitstellungsprozessen und integrierter Unterstützung für die Integration meiner GitHub-Repos in meine persönlichen Lieblings-Hosting-Provider konnte ich mich endlich auf das konzentrieren, was TanStack Start meiner Meinung nach besonders macht

• Ein erstklassiger, vollständig typsicherer Router
• Flexible Primitiven zum Erstellen von servergebundenen RPCs
• Opt-in-Serverfunktionalität (SSR, APIs, RSCs usw.)
• Und tiefe Integration mit anderen TanStack-Primitiven wie TanStack Query
• Und noch viel mehr kommt!

Es ist großartig, dass wir so viel an Nitro und Vite auslagern und so viele großartige Funktionen erhalten konnten, aber es ist definitiv keine 100% vollständige Lösung für die Verwendung *aller* Funktionen einer Hosting-Plattform, insbesondere Vercel, wo wir mehr als nur Bereitstellungen zur Verfügung haben. Wir haben uns auch mehr Gedanken über Funktionen wie Edge-Network-Caching und mein persönlicher Favorit, *Skew Protection*. *gemacht.

TanStack Start ist derzeit in der Beta-Phase! Klicken Sie auf die Schaltfläche "Deploy" unten, um eine frische Kopie der TanStack Start „Basic“-Vorlage in etwa 1 Minute zu erstellen und auf Vercel bereitzustellen.

Wir hoffen, dass Sie das, was wir bauen, genießen und freuen uns auf Ihr Feedback!