Instant 1.0 – Eine Backend-Plattform für mit AI entwickelte Apps

• Ein Open-Source-Backend, das mit Vibe Coding erstellten Apps Echtzeit-Synchronisierung, Offline-Modus, Authentifizierung und Dateispeicher auf einmal hinzufügt
• Die Backend-Erstellung bedeutet nicht das Starten einer VM, sondern das Hinzufügen einer DB-Zeile – dadurch entsteht ein Backend in wenigen Millisekunden und kostet bei Nichtnutzung null
• Im Frontend lassen sich mit db.useQuery und db.transact relationale Abfragen und Datenänderungen direkt ausführen – ein separater API-Server ist nicht nötig
• Optimistische Updates sind standardmäßig aktiviert, sodass die UI selbst bei langsamer Netzwerkverbindung sofort reagiert und bei Fehlern automatisch zurückgerollt wird
• Auch Datei-Uploads werden als DB-Zeilen verwaltet; wird ein Beitrag gelöscht, werden Anhänge ebenfalls per CASCADE gelöscht – eigener S3-Synchronisierungscode ist nicht nötig
• Authentifizierungsarten wie Magic Code, OAuth und Guest Auth lassen sich frei wählen, und mit Presence kann auch „wer gerade verbunden ist“ sofort umgesetzt werden
• AI-Agenten können per API/CLI direkt Apps erstellen, Schemas ändern und Berechtigungen setzen, sodass sich per Prompt sogar das Deployment einer Full-Stack-App anstoßen lässt
• Mit nur einer Zeile npx create-instant-app lässt sich sofort ein Projekt in der gewünschten Umgebung wie NextJS, Bun oder Vite erstellen
• Die Abfragesprache InstaQL verwendet direkt die Syntax von JavaScript-Objekten und ermöglicht dadurch dynamische Abfragen wie bei GraphQL – ohne Build-Schritt oder Codegen
• Eine über 4 Jahre entwickelte Postgres-basierte Multi-Tenant-Architektur betreibt Tausende von Apps auf einer einzigen Instanz; der vollständige Open-Source-Code ist auf GitHub veröffentlicht

[GN⁺]

Hacker-News-Kommentare

• Ehrliche Frage: Ich verstehe nicht, warum vibe-coded Apps ein Framework brauchen.
  Man kann dem Coding-Agenten doch einfach sagen, dass das Frontend in HTML5/Vanilla JS/CSS und das Backend in einer beliebigen Sprache geschrieben werden soll.
  Man braucht keine hunderten Abhängigkeiten, und das Deployment kann man ebenfalls dem Agenten überlassen.

  • Ich habe das tatsächlich ausprobiert, und die aktuellen LLMs waren deutlich effizienter, wenn sie auf einem Framework gearbeitet haben.
    Je größer der Code wird, desto schlechter werden nicht nur die Kosten, sondern auch die Performance, und Bugs sowie unnötige Abstraktionen nehmen zu.
    Am Ende verschwendet man Zeit damit, das Modell dazu zu bringen, selbst ein gutes Framework zu bauen.
    Ich denke, es ist besser, ein bestehendes Framework zu verwenden, das bereits in den Trainingsdaten enthalten ist.
    Mit den aktuellen Modellen würde ich das für alles empfehlen, was über eine Landingpage hinausgeht.
  • Das klingt vielleicht wie ein Scherz, aber aus demselben Grund codieren wir auch nicht in Assembler.
    Gute Abstraktionen verbessern Lesbarkeit und Wartbarkeit, und reines HTML/CSS/JS ist ohnehin nicht mehr Mainstream.
    Es muss für Menschen verständlich und überprüfbar bleiben, und sonst verschwendet man Tokens und Zeit damit, das Rad neu zu erfinden.
    Auch LLMs können wie Menschen in komplexem Spaghetti-Code steckenbleiben.
  • Dafür gibt es einige Gründe.
    1. Unbegrenzte Projekte: Herkömmliche VM-basierte Backends sind teuer, aber mit Instant lassen sich unbegrenzt viele erzeugen.
    2. User Experience: Funktionen wie Multiplayer, Offline-Modus und optimistische Updates lassen sich leicht umsetzen.
    3. Umfangreiche Features: Dateispeicherung, Cursor-Sharing, Token-Streaming und mehr sind bereits eingebaut.
       Als Beispiel kann man per Knopfdruck ein Backend erstellen und mit 25 Zeilen Code eine Echtzeit-Todo-App fertigstellen.
  • Mit einem Framework bekommt man die ersten mehr als 10.000 Zeilen Scaffolding-Code praktisch für 0 Token Kosten.
    Man kann direkt zur Business-Logik übergehen und arbeitet innerhalb bereits erprobter Muster und Werkzeuge.
    Enterprise-Software braucht weiterhin große Codebasen, daher ist der Wert von Frameworks hoch.
    Sie liefern battle-tested Lösungen, die viele Edge Cases bereits gelöst haben.
  • Ganz einfach: Man reduziert den Bereich, den man selbst verwalten muss, und übergibt diese Verantwortung an das Framework.
    Wenn man ein gutes Framework wählt, spart man sich tausende Entscheidungen und viel Wartungsaufwand.
    Frameworks existieren letztlich wegen Skalierbarkeit.

• Ich frage mich, ob die Leute so etwas wirklich brauchen.
  Wie viele bauen schon Multiplayer-Apps wie Figma oder Linear?
  Die meisten werden doch CRUD-Apps sein — warum sollte man sich dafür an proprietäre Technologie binden?

  • Der interessante Punkt ist: Wenn Multiplayer-Apps einfacher zu bauen sind, werden auch mehr Apps so gebaut werden.
    Linear ist zum Beispiel Multiplayer, und ich sehe keinen Grund, warum andere CRUD-Apps das nicht sein sollten.
    Wenn die Abstraktion gut gemacht ist, lassen sich Apps auf Basis einer Sync-Engine sogar einfacher entwickeln.
    Das Team von Linear hat das auch in diesem Tweet so erwähnt.
  • Zur Info: Instant ist zu 100 % Open Source.
    GitHub-Repository
  • Stimme zu. Heutzutage wird der meiste Code von LLMs geschrieben, daher braucht man keine komplexe Technologie.
    CRUD-Apps sind simpel und repetitiv und damit ideal für AI.
    Ein Go-Binary fürs Backend und React fürs Frontend decken in 99,9 % der Fälle alles ab.
    Selbst ein 5-Dollar-Node kann problemlos 100.000 MAU bedienen.

• Scheint ein perfektes Tool für persönliche Projekte zu sein.
  Allerdings wäre es schön, wenn der „Agent“-Teil noch nahtloser integriert wäre.
  Könnte ich irgendwie sehen, wie mein Coding-Agent damit umgeht?
  Es wäre gut, im Blog einen Link zu den entsprechenden Skills hinzuzufügen.

  • Guter Vorschlag. Ich habe den Essay direkt aktualisiert.
    PR-Link
  • Es gibt bereits einen Skill.
    Er lässt sich mit dem Befehl npx skills add instantdb/skills hinzufügen.
    Für das Projekt-Scaffolding wird außerdem bunx/pnpx/npx create-instant-app empfohlen.

• Glückwunsch zum Launch! InstantDB war eines der angenehmsten Tools, die ich je benutzt habe.
  Ich habe damit nur kleine Toy-Projekte gemacht, aber in diesem Bereich ist es mit Abstand das einfachste und intuitivste.
  Allerdings ist das Kernprodukt so gut, dass der AI-Fokus etwas unnatürlich wirkt.
  Vielleicht braucht man heute so ein Positioning, um Funding zu bekommen.

  • Danke!
    Seit der Open-Source-Freigabe im August 2024 haben wir die Website nicht aktualisiert.
    Seit dem damaligen Post ist die Zahl der Nutzer, die Apps mit AI bauen, stark gestiegen.
    Deshalb haben wir das Messaging neu aufgestellt und investiert, um die Agent-Erfahrung angenehmer zu machen.
  • Danke. Die Betonung von AI ist kein Marketing, sondern basiert auf dem tatsächlichen Nutzerverhalten.
    Die meisten unserer Nutzer programmieren mit AI, deshalb haben wir dafür optimiert.

• Vielleicht verstehe ich es falsch, aber ich frage mich, warum es „AI-coded“ ist.
  Für jemanden, der einfach nur ein unkompliziertes Backend sucht, wirkt es wie eine großartige Alternative.
  Aber im Vergleich zu anderen Backends ist für mich nicht klar, was daran AI-zentriert ist.
  Und da es sehr TS-zentriert wirkt, würde mich interessieren, ob native Mobile-Bindings geplant sind.

• Wirklich beeindruckende Demo. Die Idee der AI-Integration ist großartig, aber sie wird nicht gut genug erklärt.
  Ich habe mir das Tutorial angesehen, aber es konzentriert sich hauptsächlich auf die Erstellung eines SaaS-Accounts.
  Muster für reaktive Apps wie Triples, Datalog und Clojure sind in Instant gut aufgegangen.
  Persönlich fand ich Clojure schwierig und Datalog ungewohnt, daher ist die Abstraktion von Instant sehr willkommen.
  Wenn ein InstantQL-Datalog-Konverter als separate Komponente verfügbar wäre, wäre das wirklich nützlich.
  Da das Backend auf Clojure basiert, ist die Wahl von Postgres nachvollziehbar, aber für lokale Deployments könnte SQLite einfacher sein.

• Es ist beeindruckend, dass sie „relationale Queries + Echtzeit“ tatsächlich umgesetzt haben.
  Allerdings wirkt die Console-UI, als hätte sie weniger Aufmerksamkeit bekommen als die Infrastruktur oder die Website.
  Glückwunsch zum 1.0-Release — ich werde auch in Zukunft weiter mit Instant bauen.

  • Danke!
    Wir haben die Demo auf der Homepage, den Essay und die Dokumentation stark verbessert.
    Das Dashboard soll in den nächsten Wochen ein Redesign bekommen.
    Interessant ist, dass Nutzer selbst dann, wenn ein AI-Agent die App baut und das Schema verändert,
    lieber ihre Daten direkt über die Explorer-Komponente durchsuchen.

• Ich finde in der Dokumentation nichts zu Rate Limiting. Gibt es das überhaupt?

• Ich habe Pocketbase verwendet, und Instant scheint für einen ähnlichen Zweck ebenfalls gut zu sein.
  Pocketbase hatte allerdings eine starke Server-Erweiterbarkeit als Vorteil.
  Man konnte Hooks in JS oder Go schreiben, um Funktionen wie Push-Benachrichtigungen hinzuzufügen.
  Mich würde interessieren, ob so etwas auch in InstantDB möglich ist oder ob man dafür einen separaten Worker bauen muss.
  Und gibt es Pläne für ein Dart SDK?

  • Auf dem Server kann man mit db.subscribeQuery auf Änderungen reagieren.
    Eine Webhook-Funktion soll bald hinzukommen, und SDKs für andere Sprachen sind langfristig ebenfalls geplant.

• Ich kann der Sichtweise zustimmen, dass „vordefinierte Muster die Token-Kosten senken“.
  Wir hatten beim Bau von empla.io eine ähnliche Erfahrung.
  Wenn man Backend-Entscheidungen dem Agenten überlässt, steigt der Token-Verbrauch um das 3- bis 4-Fache.
  Eine deklarative Query-Sprache bringt für AI noch größere Effizienzgewinne als für Menschen.
  Ich habe zwei Fragen dazu.

  1. Wie geht ihr mit Schema-Evolution um, wenn ein Agent mitten in einer Session neue Relationen hinzufügt?
  2. Gibt es eingebaute Funktionen zur Verwaltung des Kostenbudgets pro Session, oder muss der Nutzer das selbst implementieren?

[picopress]

Wird sogar Vibecoding beworben?