Deutsch (du)

APIs und serverseitige Logik

Beschreibe das gewünschte Produktverhalten. condoo.Vibe entwickelt APIs, Berechtigungen, Validierung und Geschäftslogik hinter der Oberfläche.

Hinter jeder nützlichen Anwendung stehen Regeln, die bestimmen, was bei Nutzeraktionen geschieht.

Wenn jemand eine Buchung erstellt, einen Kunden aktualisiert, eine Zahlung abschließt, ein Teammitglied einlädt oder den Status eines Abschlusses ändert, benötigt deine Anwendung Logik, um diese Aktion zu verarbeiten.

condoo.Vibe kann die dafür erforderlichen APIs und serverseitigen Funktionen entwickeln.

Du musst nicht jeden Endpunkt selbst entwerfen.

Beschreibe, was deine Anwendung tun soll. condoo.Vibe kann die Logik dahinter entwickeln.

Du definierst das Verhalten. condoo.Vibe entwickelt die Logik, die es ermöglicht.

Was ist serverseitige Logik?

Deine Anwendung enthält sichtbare Elemente und Vorgänge, die im Hintergrund ablaufen.

Die Oberfläche zeigt vielleicht eine Schaltfläche:

[Create Lead]

Ein Klick darauf muss aber möglicherweise:

Die Schaltfläche ist der sichtbare Teil.

Die Regeln und Operationen dahinter gehören zur Anwendungslogik.

Frontend und Backend

Eine Anwendung lässt sich vereinfacht so betrachten:

NUTZER
 ↓
FRONTEND
Was der Nutzer sieht und bedient
 ↓
BACKEND
Verarbeitet Anfragen und wendet Regeln an
 ↓
DATENBANK / DIENSTE
Speichert Daten oder kommuniziert mit anderen Systemen

Das Frontend kann Folgendes enthalten:

Das Backend kann Folgendes übernehmen:

condoo.Vibe kann beide Bereiche bearbeiten.

Was ist eine API?

Eine API ermöglicht verschiedenen Softwareteilen eine strukturierte Kommunikation.

Zum Beispiel muss deine Lead-Seite Leads aus dem Backend der Anwendung abrufen.

Vereinfacht:

Lead-Seite
    ↓
„Die Leads abrufen“
    ↓
API
    ↓
Datenbank
    ↓
API
    ↓
Lead-Seite

Wenn jemand einen Lead erstellt:

Formular zum Erstellen eines Leads
      ↓
API-Anfrage
      ↓
Daten validieren
      ↓
In der Datenbank speichern
      ↓
Lead zurückgeben
      ↓
Oberfläche aktualisieren

Der Nutzer muss diese Anfragen weder sehen noch verstehen.

Er erlebt einfach eine funktionierende Anwendung.

condoo.Vibe kann APIs für deine Anwendung erstellen

Wenn die beschriebene Anwendung APIs benötigt, kann condoo.Vibe sie als Teil der Implementierung erstellen.

Angenommen, du fragst:

Eine Lead-Verwaltung entwickeln. Nutzer sollen Leads erstellen, ansehen, bearbeiten, suchen, filtern und löschen können.

Dafür benötigt die Anwendung möglicherweise folgende Operationen:

Ein Entwickler würde diese möglicherweise als API-Endpunkte betrachten.

Als Nutzer von condoo.Vibe kannst du mit dem gewünschten Produktverhalten beginnen.

Endpunktnamen müssen nicht vorgegeben werden

Technische Nutzer können ausdrückliche API-Anforderungen angeben.

Zum Beispiel:

GET /api/leads
POST /api/leads
GET /api/leads/:id
PATCH /api/leads/:id
DELETE /api/leads/:id

Das ist jedoch optional.

Du kannst einfach sagen:

Nutzer sollen Leads erstellen, ansehen, bearbeiten und löschen können.

condoo.Vibe kann bestimmen, welche Anwendungsinfrastruktur nötig ist.

Geschäftslogik

Serverseitige Funktionen werden besonders wichtig, wenn deine Anwendung Regeln hat.

Zum Beispiel:

Wenn ein Abschluss auf Closed Won gesetzt wird, das Abschlussdatum erfassen und den Wert zum gewonnenen Umsatz hinzufügen.

Das ist eine Geschäftsregel.

Oder:

Nur Owner und Admins eines Arbeitsbereichs dürfen Teammitglieder einladen.

Eine weitere Geschäftsregel.

Oder:

Eine Buchung darf nicht angelegt werden, wenn eine andere bestätigte Buchung den ausgewählten Zeitraum bereits belegt.

Noch eine Regel.

condoo.Vibe kann das Anwendungsverhalten anhand dieser Anforderungen entwickeln.

Regeln in normaler Sprache beschreiben

Du musst Geschäftsregeln nicht in Code umwandeln, bevor du sie condoo.Vibe gibst.

Zum Beispiel:

Nutzer dürfen Buchungen bis 24 Stunden vor dem Termin stornieren. Danach darf die Schaltfläche Cancel nicht mehr verfügbar sein, und das Backend muss Stornierungsversuche ablehnen.

Das sagt condoo.Vibe:

Das reicht aus, um konkretes Produktverhalten zu definieren.

Nicht nur auf die Oberfläche vertrauen

Angenommen, nur Administratoren dürfen Nutzer löschen.

Es reicht nicht, gewöhnlichen Nutzern einfach:

[Delete User]

nicht anzuzeigen.

Ein Nutzer darf die Oberfläche nicht umgehen und den eingeschränkten Vorgang trotzdem ausführen können.

Das Backend muss die Regel ebenfalls durchsetzen.

Vereinfacht:

Anfrage zum Löschen eines Nutzers
        ↓
Ist der Anfragende authentifiziert?
        ↓
Ist der Anfragende ein Admin?
       ↙ ↘
      Ja  Nein
      ↓     ↓
   Löschen Ablehnen

Deshalb ist serverseitige Logik für Berechtigungen und sensible Vorgänge wichtig.

Authentifizierung und APIs

Viele APIs sollten nur für authentifizierte Nutzer funktionieren.

Zum Beispiel:

Nur angemeldete Nutzer dürfen Projekte erstellen.

Die Anwendung muss vor der Freigabe einer Anfrage ermitteln, wer sie stellt.

Vereinfacht:

Projekt erstellen
      ↓
API-Anfrage
      ↓
Ist der Nutzer angemeldet?
   ↙         ↘
  Ja         Nein
  ↓            ↓
Fortfahren    Ablehnen

Bei Teamanwendungen kann eine weitere Prüfung hinzukommen.

Projekt erstellen
      ↓
Angemeldet?
      ↓
Mitglied des Arbeitsbereichs?
      ↓
Berechtigung vorhanden?
      ↓
Projekt erstellen

So werden Authentifizierung, Autorisierung und Anwendungslogik kombiniert.

Auf Arbeitsbereiche begrenzte Daten

Mandantenfähige SaaS-Anwendungen erfordern besonders sorgfältige serverseitige Logik.

Angenommen, zwei Unternehmen nutzen dasselbe CRM:

Acme Realty
├── Leads
├── Abschlüsse
└── Immobilien

Northstar Realty
├── Leads
├── Abschlüsse
└── Immobilien

Wenn jemand von Acme Realty Leads anfragt, darf die Anwendung nur die Leads von Acme zurückgeben, nicht sämtliche Leads in der Datenbank.

Vereinfacht:

Authentifizierter Nutzer
       ↓
Arbeitsbereich bestimmen
       ↓
Mitgliedschaft prüfen
       ↓
Datensätze abrufen
WHERE workspace = user's workspace
       ↓
Ergebnisse zurückgeben

Diese Trennung muss im Backend erfolgen.

Serverseitige Validierung

Formulare können Informationen in der Oberfläche validieren. Wichtige Prüfungen müssen jedoch auch serverseitig stattfinden.

Angenommen, deine Anwendung verlangt:

Jeder Lead muss einen Namen und entweder eine E-Mail-Adresse oder eine Telefonnummer haben.

Das Frontend kann dem Nutzer helfen, indem es Validierungsfehler sofort anzeigt.

Der Server muss ungültige Anfragen aber ebenfalls ablehnen.

Warum?

Weil letztlich das Backend für den Schutz der Datenintegrität deiner Anwendung verantwortlich ist.

Mit deiner Datenbank arbeiten

APIs liegen oft zwischen der Oberfläche deiner Anwendung und ihrer Neon-Datenbank.

Zum Beispiel:

Dashboard
    ↓
DATEN ABRUFEN
    ↓
Server
    ↓
Neon Postgres
    ↓
Server
    ↓
Dashboard

Wenn Informationen geändert werden:

Kunde bearbeiten
      ↓
Speichern
      ↓
Server validiert die Anfrage
      ↓
Neon Postgres wird aktualisiert
      ↓
Aktualisierter Kunde wird zurückgegeben
      ↓
Oberfläche wird aktualisiert

Diese Trennung hält Datenbankoperationen im dafür vorgesehenen Teil der Anwendung.

Berechnungen und Aggregationen

Serverseitige Logik kann auch Informationen aus gespeicherten Daten berechnen.

Angenommen, deine Datenbank enthält Hunderte von Abschlüssen.

Du fragst condoo.Vibe:

Den gesamten Pipeline-Wert, die Anzahl aktiver Abschlüsse, die gewonnenen Abschlüsse dieses Monats und die durchschnittliche Abschlussgröße im Dashboard anzeigen.

Die Anwendung kann diese Kennzahlen aus den zugrunde liegenden Datensätzen berechnen.

Zum Beispiel:

Abschlüsse
  ↓
Aktive Abschlüsse filtern
  ↓
Gesamtwert berechnen
  ↓
Kennzahl zurückgeben
  ↓
Dashboard

$4.2M Pipeline-Wert

Die angezeigte Zahl kann aus echten Anwendungsdaten stammen statt aus fest hinterlegten Inhalten.

Zeitabhängige Logik

Anwendungen benötigen häufig zeitabhängige Regeln.

Zum Beispiel:

Diese Anforderungen können als Anwendungslogik rund um deine gespeicherten Daten umgesetzt werden.

Externe Dienste verbinden

Dein Backend kann auch mit externen Diensten kommunizieren.

Angenommen, ein Kunde schließt eine Buchung ab.

Der Ablauf könnte sein:

Kunde sendet eine Buchung
         ↓
Server validiert die Anfrage
         ↓
Buchung in Neon speichern
         ↓
Bestätigung über Resend senden
         ↓
Erfolg zurückgeben
         ↓
Bestätigungsansicht anzeigen

Oder bei einer Zahlung:

Kunde wählt Pro
         ↓
Stripe-Checkout erstellen
         ↓
Kunde bezahlt
         ↓
Stripe bestätigt die Zahlung
         ↓
Server verarbeitet das Ereignis
         ↓
Abonnement aktualisieren
         ↓
Pro-Funktionen freischalten

condoo.Vibe kann die Anwendungslogik entwickeln, die diese Systeme verbindet.

Webhooks

Manche externen Dienste müssen deiner Anwendung mitteilen, wenn etwas geschieht.

Dafür wird üblicherweise ein Webhook verwendet.

Zum Beispiel nach einer Stripe-Zahlung:

Deine Anwendung
      ↓
Stripe-Checkout
      ↓
Zahlung
      ↓
Stripe-Webhook
      ↓
Deine Anwendung
      ↓
Abonnement aktualisieren

Der Kunde kann die Checkout-Seite bereits verlassen haben, wenn Stripe diese Information sendet.

Deshalb dürfen zuverlässige Zahlungssysteme nicht allein davon abhängen, was im Browser geschieht.

Webhooks nutzen, ohne ihre Technik kennen zu müssen

Du kannst das gewünschte Verhalten beschreiben.

Zum Beispiel:

Wenn Stripe bestätigt, dass ein Abonnement erfolgreich aktiviert wurde, den Tarif des Nutzers in unserer Datenbank aktualisieren und die darin enthaltenen Funktionen freischalten.

condoo.Vibe kann die erforderliche technische Umsetzung bestimmen.

Technische Nutzer können bei Bedarf selbstverständlich genauere Webhook-Anforderungen angeben.

Hintergrundaktionen

Manche Abläufe enthalten Aktionen, die die unmittelbare Interaktion des Nutzers nicht blockieren müssen.

Zum Beispiel:

Nach der Registrierung eines neuen Kunden dessen Konto erstellen und anschließend eine Willkommens-E-Mail senden.

Die für den Kunden unmittelbar wichtige Aktion ist das Erstellen des Kontos.

Die E-Mail ist eine Folgeaktion.

Ebenso:

Wenn ein Lead einem Makler zugewiesen wird, den Lead sofort aktualisieren und den Makler benachrichtigen.

Deine Anwendung kann mehrere Aktionen rund um ein einzelnes Nutzerereignis koordinieren.

Fehlerbehandlung

Serverseitige Vorgänge können fehlschlagen.

Eine Datenbank kann eine Anfrage ablehnen.

Ein externer Dienst kann nicht verfügbar sein.

Eine Zahlung kann fehlschlagen.

Eine Anfrage kann ungültige Informationen enthalten.

Eine gute Anwendung sollte diese Situationen kontrolliert behandeln.

Zum Beispiel:

Buchung erstellen
      ↓
Etwas schlägt fehl
      ↓
KEINEN Buchungserfolg vortäuschen
      ↓
Fehler zurückgeben
      ↓
Hilfreiche Meldung anzeigen
      ↓
Erneuten Versuch ermöglichen

Du kannst condoo.Vibe ausdrücklich vorgeben, wie wichtige Fehler behandelt werden sollen.

Zum Beispiel:

Wenn die Buchung nicht gespeichert werden kann, keine Bestätigungs-E-Mail senden. Dem Kunden einen Fehler anzeigen und einen erneuten Versuch ermöglichen.

Überlegen, was bei Fehlern geschieht

Betrachte diesen Ablauf:

Zahlung
   ↓
Bestellung erstellen
   ↓
E-Mail senden

Was passiert, wenn die Zahlung erfolgreich ist, das Erstellen der Bestellung aber fehlschlägt?

Bei kritischen Abläufen mit Geld, Zugriff, Lagerbeständen oder wichtigen Kundendaten muss das Verhalten bei Fehlern sorgfältig durchdacht werden.

Für solche Systeme ist Plan Mode vor der Umsetzung häufig sinnvoll.

Optimistische Aktualisierungen

Manche Anwendungen wirken schneller, wenn die Oberfläche sofort aktualisiert wird, während der Server die Änderung verarbeitet.

Zum Beispiel beim Verschieben eines Abschlusses zwischen Pipeline-Phasen:

Qualifiziert → Verhandlung

kann die Karte sofort sichtbar verschoben werden.

Anschließend speichert die Anwendung die Änderung.

Wenn das Speichern fehlschlägt, kann die Oberfläche den Abschluss in die vorherige Phase zurücksetzen und dem Nutzer mitteilen, dass etwas schiefgegangen ist.

Dieses Muster heißt optimistische Aktualisierung.

Du musst es nicht für jede Interaktion anfordern. Bei stark interaktiven Anwendungen kann es das Benutzererlebnis jedoch verbessern.

Beispiel: CRM-Ablauf

Angenommen, du sagst condoo.Vibe:

Wenn ein Makler einen Abschluss auf Closed Won setzt, die neue Phase speichern, das Abschlussdatum erfassen, einen Aktivitätseintrag erstellen, den Umsatz im Dashboard aktualisieren und eine Erfolgsmeldung anzeigen.

Diese eine Aktion umfasst mehrere Teile:

Makler verschiebt Abschluss
       ↓
Berechtigung prüfen
       ↓
Abschluss aktualisieren
       ↓
Abschlussdatum erfassen
       ↓
Aktivität erstellen
       ↓
Kennzahlen neu berechnen
       ↓
Erfolg zurückgeben
       ↓
Oberfläche aktualisieren

Du beschreibst Produktverhalten.

condoo.Vibe übernimmt die Umsetzung dahinter.

Beispiel: Buchungssystem

Betrachte:

Kunden können Termine bei einem bestimmten Mitarbeiter buchen. Ein Zeitraum darf nicht doppelt gebucht werden. Nach dem Erstellen einer Buchung diese speichern und dem Kunden eine Bestätigungs-E-Mail senden.

Der serverseitige Ablauf könnte vereinfacht so aussehen:

Buchungsanfrage
      ↓
Kundeninformationen validieren
      ↓
Verfügbarkeit prüfen
      ↓
Zeitraum verfügbar?
   ↙          ↘
  Ja          Nein
  ↓             ↓
Buchung        Anfrage
erstellen      ablehnen
  ↓
Bestätigung senden
  ↓
Erfolg zurückgeben

Der Kunde erlebt einfach ein korrekt funktionierendes Buchungssystem.

Beispiel: SaaS-Berechtigungen

Angenommen, dein SaaS-Produkt hat folgende Rollen:

Du legst fest:

Owner können die Abrechnung verwalten und den Arbeitsbereich löschen. Owner und Admins können Nutzer einladen. Members können Projekte erstellen und bearbeiten, aber nicht das Team verwalten.

condoo.Vibe kann diese Regeln in das serverseitige Verhalten der Anwendung integrieren.

Auch die Oberfläche kann die Berechtigungen abbilden. Das Backend bleibt jedoch dafür verantwortlich, wichtige Einschränkungen durchzusetzen.

Plan Mode für komplexe Logik verwenden

Einfache Logik lässt sich oft direkt entwickeln.

Zum Beispiel:

Wenn eine Aufgabe als erledigt markiert wird, das Abschlussdatum speichern.

Build Mode kann ausreichen.

Anders bei:

Eine nutzungsbasierte Abrechnung hinzufügen, bei der jeder Arbeitsbereich monatliche Credits erhält. Aktionen verbrauchen unterschiedlich viele Credits. Nicht genutzte Abonnement-Credits verfallen am Ende des Abrechnungszeitraums, zusätzlich gekaufte Credits verfallen nicht. Das System muss monatliche Credits vor zusätzlich gekauften Credits verbrauchen.

Das betrifft:

Das ist ein klarer Fall für:

Plan + Max → Prüfen → Build

Verhalten präzise beschreiben

Ein guter Prompt für serverseitige Funktionen beantwortet Fragen wie:

Zum Beispiel:

Owner und Admins eines Arbeitsbereichs dürfen Teammitglieder einladen. Die E-Mail-Adresse darf nicht bereits zu einem Mitglied des Arbeitsbereichs gehören. Eine ausstehende Einladung erstellen und die Einladungs-E-Mail senden. Falls der E-Mail-Versand fehlschlägt, die Einladung ausstehend lassen und dem Administrator ermöglichen, sie erneut zu senden.

Das ist deutlich aussagekräftiger als:

Einladungen hinzufügen.

Technische Anforderungen sind weiterhin möglich

Entwickler sind nicht auf Prompts auf Produktebene beschränkt.

Du kannst condoo.Vibe sagen:

Eine API für Aktivitätsdatensätze mit Cursor-Paginierung hinzufügen, neueste Einträge zuerst, mit maximal 100 Datensätzen pro Anfrage.

Oder:

Die Webhook-Signatur serverseitig validieren, bevor Stripe-Ereignisse verarbeitet werden.

Oder:

Diesen Vorgang als Transaktion ausführen, damit bei einem fehlgeschlagenen Schritt keine Teilaktualisierungen übernommen werden.

Mit condoo.Vibe kannst du auf der Abstraktionsebene arbeiten, die zu deiner Erfahrung und deinen Anforderungen passt.

Das Prinzip

Das Frontend bestimmt, womit Nutzer interagieren.

Die Datenbank bestimmt, welche Informationen vorhanden sind.

Die Authentifizierung bestimmt, wer der Nutzer ist.

Serverseitige Logik bestimmt:

Was darf geschehen?

APIs stellen die Kommunikationswege bereit, die diese Interaktionen ermöglichen.

Zusammen:

NUTZER
 ↓
OBERFLÄCHE
 ↓
API
 ↓
SERVERSEITIGE LOGIK
 ↓
DATENBANK + EXTERNE DIENSTE

condoo.Vibe kann über diesen gesamten Ablauf hinweg arbeiten.

Du konzentrierst dich darauf, das Produktverhalten zu definieren.

Weiter: Deine Projektdaten verwalten

Deine Anwendung hat jetzt eine Datenbank, authentifizierte Nutzer, Formulare, Integrationen, APIs und serverseitige Logik.

Sobald echte Nutzer Informationen erstellen, wird jedoch eine weitere Frage wichtig:

Wie arbeite ich mit den Daten, die meine Anwendung erzeugt?

Als Nächstes behandeln wir die Verwaltung deiner Projektdaten: die gespeicherten Informationen verstehen, ansehen, verändern und sicher damit arbeiten.

Deine Projektdaten verwalten

Die von deiner App gespeicherten Informationen verstehen, ansehen und sicher verändern.