NEAR para Desenvolvedores de Backend: Suas Habilidades, Descentralizadas

Introdução
Se você constrói backends hoje, já sabe como projetar APIs, armazenar estado e gerenciar usuários. O protocolo NEAR permite que você use os mesmos instintos—apenas em uma rede descentralizada em vez de seus próprios servidores. Pense no NEAR como “um backend que você não precisa hospedar”. Sua lógica de negócios é executada como contratos inteligentes (mini programas), seus dados estão em um armazenamento replicado gerenciado pela rede, e a identidade do usuário é verificada por criptografia, não por senhas. Nesta lição, vamos mapear ideias familiares de backend para conceitos do NEAR, percorrer um exemplo simples no estilo do Twitter e mostrar como leituras e escritas funcionam. No final, você verá que a mudança do web2 para o NEAR é uma adaptação—não uma reinvenção.

NEAR como um Backend Descentralizado

Imagine implantar um serviço que roda em um cluster global que você não mantém. Isso é o NEAR. Sua aplicação é uma conta (por exemplo, twitter-app.seunome.near) com seu próprio código e dados. Validadores independentes (nós da rede) mantêm esses dados replicados e disponíveis. Quando os usuários interagem, a rede alcança a finalidade—acordo incontestável sobre o resultado—geralmente em ~1–2 segundos.

Verificação de termos técnicos

• Validador: um nó que executa o software NEAR, executa contratos e participa do consenso.

• Finalidade: o ponto em que uma mudança é bloqueada e não pode ser revertida.

Estado da Aplicação: Isolado e Replicado

No NEAR, os dados de cada aplicação são limitados à sua conta—como um esquema de banco de dados dedicado ou namespace.

• Estado isolado: Apenas o código do seu contrato pode modificar o armazenamento chave-valor de sua aplicação.

• Trilha de auditoria: Cada mudança é registrada na cadeia, criando um histórico imutável e verificável.

• Alta disponibilidade: Muitos validadores armazenam e servem seu estado. Se alguns ficarem offline, sua aplicação permanece acessível.

• Consistência eventual rápida: As solicitações são processadas, o consenso é executado, e em ~1–2 segundos o novo estado é final em toda a rede.

Analogia: Pense em um banco de dados na nuvem com replicação de gravação multi-região e um log de auditoria integrado que não pode ser desativado.

Lógica do Backend: Contratos Inteligentes (Wasm)

Suas regras de negócios estão em um contrato inteligente—um pequeno programa compilado para WebAssembly (Wasm) e armazenado sob a conta de sua aplicação.

• Opções de linguagem: Rust é a escolha mais comum para desempenho e segurança. JavaScript/TypeScript também são usados via ferramentas do NEAR que compilam para Wasm. [esclarecer: confirmar se deseja enfatizar apenas Rust ou incluir explicitamente near-sdk-js/TypeScript.]

• Execução isolada: Wasm é eficiente e roda em um ambiente seguro e determinístico nos validadores.

• Limites claros: Cada contrato gerencia seu próprio estado e expõe funções que os clientes chamam.

Verificação de termos técnicos

• Contrato inteligente: código de backend que roda na blockchain.

• WebAssembly (Wasm): um formato binário para execução rápida e portátil.

Identidade e Autorização: Criptográfico por Padrão

Em vez de senhas, o NEAR usa contas e assinaturas digitais.

• Transações: Qualquer gravação (mudança de estado) é uma transação assinada de uma conta NEAR.

• Quem me chamou?: No contrato, predecessor_account_id informa qual conta acionou a função—como ler o usuário de um token verificado, mas com respaldo de criptografia.

• Controle de acesso: Construa verificações como “apenas esta conta pode excluir seu tweet” usando o ID da conta do chamador.

Analogia: É como JWTs sem um servidor de login—a identidade está integrada na plataforma.

Um Exemplo Simples no Estilo do Twitter (Conceitual)

Suponha que você modele Tweet { id, author, text, timestamp, likes }.

• Métodos de escrita (mudança de estado):

  • post_tweet(text): cria um tweet, autor = predecessor_account_id.

  • like_tweet(id): incrementa o contador de curtidas.

  • delete_tweet(id): apenas o autor do tweet pode excluir.

• Métodos de leitura (visualização):

  • get_tweet_by_id(id)

  • get_all_tweets(from, limit)

  • get_tweets_by_author(author, from, limit)

Em termos de design, pense em “padrões de acesso simples e indexados”. Consultas ad hoc complexas (por exemplo, junções) não existem no contrato, então planeje suas estruturas de dados e iteradores com isso em mente.

Como os Clientes Chamam Seu Contrato

Existem dois tipos de chamadas, espelhando REST:

1. Chamadas de mudança de estado (como POST/PUT/DELETE)

   • Enviadas como transações: incluem receiver_id (seu contrato), method_name, args (JSON), gas (orçamento de taxa), deposit opcional, e a assinatura da conta do chamador.

   • Ferramentas: NEAR CLI para scripts/operações; near-api-js para frontends web e móveis (a carteira lida com a assinatura).

2. Chamadas de visualização (como GET)

   • Somente leitura e gratuito no nível do contrato.

   • Enviado para um ponto de extremidade RPC; nenhuma assinatura ou gás do usuário é necessária (os provedores podem limitar a taxa).