NEAR for Backend Developers: 您的技能，去中心化

Introduction
If you build backends today, you already know how to design APIs, store state, and manage users. NEAR Protocol lets you use the same instincts—just on a decentralized network instead of your own servers. Think of NEAR as “a backend you don’t have to host.” Your business logic runs as smart contracts (mini programs), your data lives in a replicated store managed by the network, and user identity is verified by cryptography, not passwords. In this lesson, we’ll map familiar backend ideas to NEAR concepts, walk through a simple Twitter-style example, and show how reads and writes work. By the end, you’ll see that moving from web2 to NEAR is an adaptation—not a reinvention.

NEAR as a Decentralized Backend

Imagine deploying a service that runs on a global cluster you don’t maintain. That’s NEAR. Your application is an account (e.g., twitter-app.yourname.near) with its own code and data. Independent validators (network nodes) keep that data replicated and available. When users interact, the network reaches finality—undisputed agreement on the result—usually in ~1–2 seconds.

Jargon check

• Validator: a node that runs NEAR software, executes contracts, and participates in consensus.

• Finality: the point a change is locked in and cannot be reversed.

Application State: Namespaced and Replicated

On NEAR, each app’s data is scoped to its account—like a dedicated database schema or namespace.

• Isolated state: Only your contract code can modify your app’s key-value storage.

• Audit trail: Every change is recorded on-chain, creating an immutable, verifiable history.

• High availability: Many validators store and serve your state. If some go offline, your app remains accessible.

• Fast eventual consistency: Requests are processed, consensus runs, and within ~1–2 seconds the new state is final across the network.

Analogy: Think of a cloud database with multi-region write replication and a built-in audit log you can’t turn off.

Backend Logic: Smart Contracts (Wasm)

Your business rules live in a smart contract—a small program compiled to WebAssembly (Wasm) and stored under your app’s account.

• Language options: Rust is the most common choice for performance and safety. JavaScript/TypeScript are also used via NEAR’s tooling that compiles to Wasm. [clarify: confirm if you want to emphasize Rust-only or include near-sdk-js/TypeScript explicitly.]

• Sandboxed execution: Wasm is efficient and runs in a safe, deterministic environment on validators.

• Clear boundaries: Each contract manages its own state and exposes functions that clients call.

Jargon check

• Smart contract: backend code that runs on the blockchain.

• WebAssembly (Wasm): a binary format for fast, portable execution.

Identity and Authorization: Cryptographic by Default

Instead of passwords, NEAR uses accounts and digital signatures.

• Transactions: Any write (state change) is a signed transaction from a NEAR account.

• Who called me?: In the contract, predecessor_account_id tells you which account triggered the function—like reading the user from a verified token, but backed by cryptography.

• Access control: Build checks like “only this account can delete its tweet” using the caller’s account ID.

Analogy: It’s like JWTs without a login server—identity is baked into the platform.

A Simple Twitter-Style Example (Conceptual)

Suppose you model Tweet { id, author, text, timestamp, likes }.

• Write methods (state-changing):

  • post_tweet(text): creates a tweet, author = predecessor_account_id.

  • like_tweet(id): increments the like counter.

  • delete_tweet(id): only the tweet’s author can delete.

• Read methods (view):

  • get_tweet_by_id(id)

  • get_all_tweets(from, limit)

  • get_tweets_by_author(author, from, limit)

Design-wise, think “simple, indexed access patterns.” Complex ad-hoc queries (e.g., joins) don’t exist in-contract, so you plan your data structures and iterators with that in mind.

How Clients Call Your Contract

There are two kinds of calls, mirroring REST:

1. State-changing calls (like POST/PUT/DELETE)

   • Sent as transactions: include receiver_id (your contract), method_name, args (JSON), gas (fee budget), optional deposit, and the signature from the caller’s account.

   • Tools: NEAR CLI for scripts/ops; near-api-js for web and mobile frontends (wallet handles signing).

2. View calls (like GET)

   • Read-only and free at the contract level.

   • Sent to an RPC endpoint; no signature or gas from the user is needed (providers may rate-limit).

Analogy: Writes are like paid, signed POSTs that go through a global queue and get confirmed. Reads are lightweight RPC lookups.

Why Backend Developers Care

• Built-in auditability: Every write is a timestamped, immutable record. Great for provenance and compliance needs.

• Less trust, more guarantees: Users don’t need to trust your server. They can trust the neutral execution of the network and your published code.

• Identity included: Accounts and signatures replace home-grown auth stacks for core identity flows.

• Resilience out of the box: No single point of failure; validators replicate your state and logic.