NEAR para Desarrolladores de Backend: Tus Habilidades, Descentralizadas

Introducción
Si construyes backends hoy, ya sabes cómo diseñar APIs, almacenar estado y gestionar usuarios. NEAR Protocol te permite usar los mismos instintos, pero en una red descentralizada en lugar de tus propios servidores. Piensa en NEAR como “un backend que no necesitas alojar”. Tu lógica de negocio se ejecuta como contratos inteligentes (mini programas), tus datos residen en un almacén replicado gestionado por la red y la identidad del usuario se verifica mediante criptografía, no contraseñas. En esta lección, mapearemos ideas familiares de backend a conceptos de NEAR, recorreremos un ejemplo simple al estilo de Twitter y mostraremos cómo funcionan las lecturas y escrituras. Al final, verás que pasar de web2 a NEAR es una adaptación, no una reinvención.

NEAR como un Backend Descentralizado

Imagina desplegar un servicio que se ejecuta en un clúster global que no mantienes. Eso es NEAR. Tu aplicación es una cuenta (por ejemplo, twitter-app.tunombre.near) con su propio código y datos. Validadores independientes (nodos de red) mantienen esos datos replicados y disponibles. Cuando los usuarios interactúan, la red alcanza la finalidad, un acuerdo indiscutible sobre el resultado, generalmente en ~1-2 segundos.

Revisión de términos

• Validador: un nodo que ejecuta software NEAR, ejecuta contratos y participa en el consenso.

• Finalidad: el punto en el que un cambio queda bloqueado y no puede revertirse.

Estado de la Aplicación: Espaciado y Replicado

En NEAR, los datos de cada aplicación están limitados a su cuenta, como un esquema de base de datos o espacio de nombres dedicado.

• Estado aislado: Solo tu código de contrato puede modificar el almacenamiento clave-valor de tu aplicación.

• Registro de auditoría: Cada cambio se registra en la cadena, creando un historial inmutable y verificable.

• Alta disponibilidad: Muchos validadores almacenan y sirven tu estado. Si algunos se desconectan, tu aplicación sigue siendo accesible.

• Consistencia eventual rápida: Las solicitudes se procesan, se ejecuta el consenso y en ~1-2 segundos el nuevo estado es definitivo en toda la red.

Analogía: Piensa en una base de datos en la nube con replicación de escritura multi-región y un registro de auditoría incorporado que no puedes desactivar.

Lógica de Backend: Contratos Inteligentes (Wasm)

Tus reglas de negocio residen en un contrato inteligente, un pequeño programa compilado a WebAssembly (Wasm) y almacenado bajo la cuenta de tu aplicación.

• Opciones de lenguaje: Rust es la opción más común por rendimiento y seguridad. JavaScript/TypeScript también se utilizan a través de las herramientas de NEAR que se compilan a Wasm. [aclaración: confirma si deseas enfatizar solo Rust o incluir near-sdk-js/TypeScript explícitamente.]

• Ejecución aislada: Wasm es eficiente y se ejecuta en un entorno seguro y determinista en los validadores.

• Límites claros: Cada contrato gestiona su propio estado y expone funciones que los clientes llaman.

Revisión de términos

• Contrato inteligente: código de backend que se ejecuta en la cadena de bloques.

• WebAssembly (Wasm): un formato binario para una ejecución rápida y portátil.

Identidad y Autorización: Criptográfico por Defecto

En lugar de contraseñas, NEAR utiliza cuentas y firmas digitales.

• Transacciones: Cualquier escritura (cambio de estado) es una transacción firmada de una cuenta NEAR.

• ¿Quién me llamó?: En el contrato, predecessor_account_id te dice qué cuenta activó la función, como leer el usuario de un token verificado, pero respaldado por criptografía.

• Control de acceso: Establece verificaciones como “solo esta cuenta puede eliminar su tweet” utilizando el ID de cuenta del llamante.

Analogía: Es como JWTs sin un servidor de inicio de sesión: la identidad está integrada en la plataforma.

Un Ejemplo Simple al Estilo de Twitter (Conceptual)

Supongamos que modelas Tweet { id, author, text, timestamp, likes }.

• Métodos de escritura (cambio de estado):

  • post_tweet(text): crea un tweet, autor = predecessor_account_id.

  • like_tweet(id): incrementa el contador de “me gusta”.

  • delete_tweet(id): solo el autor del tweet puede eliminarlo.

• Métodos de lectura (vista):

  • get_tweet_by_id(id)

  • get_all_tweets(from, limit)

  • get_tweets_by_author(author, from, limit)

En cuanto al diseño, piensa en “patrones de acceso simples e indexados”. Las consultas ad-hoc complejas (por ejemplo, joins) no existen en el contrato, por lo que planificas tus estructuras de datos e iteradores con eso en mente.

Cómo los Clientes Llaman a tu Contrato

Hay dos tipos de llamadas, reflejando REST:

1. Llamadas de cambio de estado (como POST/PUT/DELETE)

   • Enviadas como transacciones: incluyen receiver_id (tu contrato), method_name, args (JSON), gas (presupuesto de tarifa), depósito opcional deposit, y la firma de la cuenta del llamante.

   • Herramientas: NEAR CLI para scripts/operaciones; near-api-js para frontends web y móviles (la billetera maneja la firma).

2. Llamadas de vista (como GET)

   • Solo lectura y gratuito a nivel de contrato.

   • Enviadas a un punto final de RPC; no se necesita firma ni gas del usuario (los proveedores pueden limitar la velocidad).

Analogía: Las escrituras son como POSTs pagados y firmados que pasan por una cola global y se confirman. Las lecturas

Updated: septiembre 26, 2025