NEAR für Backend-Entwickler: Deine Fähigkeiten, dezentralisiert

Einführung
Wenn Sie heute Backends erstellen, wissen Sie bereits, wie man APIs entwirft, den Zustand speichert und Benutzer verwaltet. NEAR Protocol ermöglicht es Ihnen, dieselben Instinkte zu verwenden – nur auf einem dezentralen Netzwerk anstelle Ihrer eigenen Server. Denken Sie an NEAR als “ein Backend, das Sie nicht hosten müssen”. Ihre Geschäftslogik läuft als Smart Contracts (Mini-Programme), Ihre Daten befinden sich in einem replizierten Speicher, der vom Netzwerk verwaltet wird, und die Benutzeridentität wird durch Kryptografie und nicht durch Passwörter überprüft. In dieser Lektion werden wir vertraute Backend-Ideen mit NEAR-Konzepten verknüpfen, ein einfaches Beispiel im Twitter-Stil durchgehen und zeigen, wie Lese- und Schreibvorgänge funktionieren. Am Ende werden Sie feststellen, dass der Wechsel von Web2 zu NEAR eine Anpassung ist – keine Neuerfindung.

NEAR als dezentrales Backend

Stellen Sie sich vor, Sie deployen einen Dienst, der auf einem globalen Cluster läuft, den Sie nicht warten. Das ist NEAR. Ihre Anwendung ist ein Konto (z.B. twitter-app.yourname.near) mit eigenem Code und Daten. Unabhängige Validatoren (Netzwerkknoten) halten diese Daten repliziert und verfügbar. Wenn Benutzer interagieren, erreicht das Netzwerk Finalität – unbestrittene Einigung über das Ergebnis – normalerweise in ~1-2 Sekunden.

Jargon-Check

• Validator: ein Knoten, der NEAR-Software ausführt, Verträge ausführt und am Konsens teilnimmt.

• Finalität: der Punkt, an dem eine Änderung gesperrt ist und nicht rückgängig gemacht werden kann.

Anwendungsstatus: Namensräume und Replikate

Auf NEAR ist die Daten jedes Apps auf ihr Konto beschränkt – wie ein dediziertes Datenbankschema oder Namensraum.

• Isolierter Status: Nur Ihr Vertragscode kann den Schlüssel-Wert-Speicher Ihrer App ändern.

• Prüfpfad: Jede Änderung wird on-chain protokolliert und erzeugt eine unveränderliche, überprüfbare Historie.

• Hohe Verfügbarkeit: Viele Validatoren speichern und bedienen Ihren Status. Wenn einige offline gehen, bleibt Ihre App zugänglich.

• Schnelle endgültige Konsistenz: Anfragen werden verarbeitet, Konsens wird hergestellt und innerhalb von ~1-2 Sekunden ist der neue Status im gesamten Netzwerk endgültig.

Analogie: Denken Sie an eine Cloud-Datenbank mit Multi-Regionen-Schreibreplikation und einem integrierten Audit-Log, den Sie nicht ausschalten können.

Backend-Logik: Smart Contracts (Wasm)

Ihre Geschäftsregeln befinden sich in einem Smart Contract – einem kleinen Programm, das zu WebAssembly (Wasm) kompiliert und unter dem Konto Ihrer App gespeichert ist.

• Sprachoptionen: Rust ist die häufigste Wahl für Leistung und Sicherheit. JavaScript/TypeScript werden auch über NEAR-Tools verwendet, die zu Wasm kompilieren. [klarstellen: bestätigen, ob Sie nur Rust oder explizit near-sdk-js/TypeScript betonen möchten.]

• Abgeschottete Ausführung: Wasm ist effizient und läuft in einer sicheren, deterministischen Umgebung auf Validatoren.

• Klare Grenzen: Jeder Vertrag verwaltet seinen eigenen Status und stellt Funktionen bereit, die von Clients aufgerufen werden.

Jargon-Check

• Smart Contract: Backend-Code, der auf der Blockchain ausgeführt wird.

• WebAssembly (Wasm): ein binäres Format für schnelle, portable Ausführung.

Identität und Autorisierung: Kryptografisch standardmäßig

Anstelle von Passwörtern verwendet NEAR Konten und digitale Signaturen.

• Transaktionen: Jede Schreiboperation (Zustandsänderung) ist eine signierte Transaktion von einem NEAR-Konto.

• Wer hat mich angerufen?: Im Vertrag sagt Ihnen predecessor_account_id, welches Konto die Funktion ausgelöst hat – ähnlich wie das Lesen des Benutzers aus einem verifizierten Token, aber durch Kryptografie abgesichert.

• Zugriffskontrolle: Erstellen Sie Überprüfungen wie “nur dieses Konto kann seinen Tweet löschen”, indem Sie die Kontonummer des Anrufers verwenden.

Analogie: Es ist wie JWTs ohne einen Anmeldeserver – Identität ist in die Plattform integriert.

Ein einfaches Beispiel im Twitter-Stil (konzeptionell)

Angenommen, Sie modellieren Tweet { id, author, text, timestamp, likes }.

• Schreibmethoden (zustandsändernd):

  • post_tweet(text): erstellt einen Tweet, author = predecessor_account_id.

  • like_tweet(id): erhöht den Like-Zähler.

  • delete_tweet(id): nur der Autor des Tweets kann löschen.

• Lese-Methoden (Ansicht):

  • get_tweet_by_id(id)

  • get_all_tweets(from, limit)

  • get_tweets_by_author(author, from, limit)

Designmäßig denken Sie an “einfache, indexierte Zugriffsmuster”. Komplexe Ad-hoc-Abfragen (z.B. Joins) existieren nicht im Vertrag, daher planen Sie Ihre Datenstrukturen und Iteratoren entsprechend.

Wie Clients Ihren Vertrag aufrufen

Es gibt zwei Arten von Aufrufen, die REST spiegeln:

1. Zustandsändernde Aufrufe (wie POST/PUT/DELETE)

   • Als Transaktionen gesendet: enthalten receiver_id (Ihr Vertrag), method_name, args (JSON), gas (Gebührenbudget), optional deposit und die Signatur des Aufrufers Kontos.

   • Werkzeuge: NEAR CLI für Skripte/Operationen; near-api-js für Web- und Mobile-Frontends (Wallet übernimmt die Signatur).

2. Ansichtsanrufe (wie GET)

   • Nur-Lesen und auf Vertragsebene kostenlos.