¿Qué es un backend? El lado del servidor de una aplicación, explicado

Un backend es un sistema del lado del servidor: el código, la base de datos y la infraestructura que atienden las solicitudes de una app y guardan sus datos. Todo software con usuarios tiene dos mitades. La mitad que ven y tocan — pantallas, botones, formularios — es el frontend.

La mitad que nunca ven, la que decide qué pueden hacer los botones y recuerda lo que pasó después de cerrar la app, es el backend. La vieja analogía del mecánico sigue vigente: el conductor maneja el tablero, el mecánico maneja el motor.

Esta entrada trata sobre el motor.

Puntos clave

Una solicitud, de punta a punta

La forma más clara de ver un backend es seguir una solicitud que lo atraviesa. Un usuario toca “mostrar mis tareas pendientes”; esto es lo que ocurre al otro lado de la API:

GET /classes/Todo?where={"done":false} HTTP/1.1     ← el frontend pregunta
Authorization: Bearer eyJhbGci…                     ← quién pregunta

  backend ─┬─ capa de API        parsear la solicitud, verificar el token
           ├─ autorización       ¿puede este usuario leer estas filas?
           ├─ lógica de negocio  aplicar las reglas (solo las tareas de quien llama)
           ├─ capa de datos      consultar la base de datos, dar forma al resultado
           └─ respuesta          200 OK + JSON, en menos de 100 ms

{ "results": [ { "objectId": "xKd91m", "title": "Ship the release", "done": false } ] }

La misma conversación desde el lado del frontend, a través de un SDK que la convierte en una línea por plataforma:

// JavaScript / Node.js — Back4app JS SDK
// The frontend asks the backend a question; the backend answers from the database
const query = new Parse.Query('Todo');
query.equalTo('done', false);
const open = await query.find();
// Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
console.log(`${open.length} open todos`);

// Flutter / Dart — Back4app Flutter SDK
// The frontend asks the backend a question; the backend answers from the database
final query = QueryBuilder<ParseObject>(ParseObject('Todo'))
  ..whereEqualTo('done', false);
final response = await query.query();
// Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
print('${response.results?.length ?? 0} open todos');

// iOS / Swift — Back4app Swift SDK
// The frontend asks the backend a question; the backend answers from the database
let query = Todo.query("done" == false)
query.find { result in
    // Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
    if case .success(let open) = result { print("\(open.count) open todos") }
}

// Android / Kotlin — Back4app Android SDK
// The frontend asks the backend a question; the backend answers from the database
val query = ParseQuery.getQuery<ParseObject>("Todo")
query.whereEqualTo("done", false)
query.findInBackground { open, e ->
    // Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
    if (e == null) println("${open.size} open todos")
}

Frontend vs. backend

La distinción que más gente busca, en una sola tabla:

Esa última fila es la que importa para la seguridad: cualquier cosa que esté en el frontend puede ser leída y modificada por el usuario. Por eso la validación, los permisos y los secretos pertenecen al backend, y por eso cada llamada a la API se trata como no confiable hasta que el servidor la ha verificado.

Lado del cliente y lado del servidor

Los dos términos no son dos tipos de backend; son los dos extremos de cada solicitud. El lado del cliente es cualquier código que corre en el dispositivo del usuario — renderizar la interfaz, mantener estado temporal, enviar solicitudes.

El lado del servidor es cualquier código que corre en máquinas a las que el usuario no puede llegar — recibir esas solicitudes, ejecutar la lógica real, leer y escribir la base de datos, y responder. “Backend” y “lado del servidor” se usan como sinónimos para esa segunda mitad, y esta entrada hace lo mismo.

De qué está hecho un backend

El encuadre clásico llama al frontend capa de presentación y al backend capa de acceso a datos, y describe el backend como tres cosas trabajando juntas: los recursos de hardware, el software que corre sobre ellos y la infraestructura de red entre ellos y el usuario.

Sigue siendo cierto, pero es más útil leer un backend como una pila de responsabilidades, la mayoría presentes en todo producto sin importar su tamaño:

• Capa de API — el contrato público: endpoints REST o GraphQL que el frontend y otros sistemas llaman.
• Lógica de negocio — las reglas que hacen que el producto sea el producto: qué es un pedido válido, quién puede aprobar qué, cómo se calcula una puntuación.
• Capa de datos — la base de datos y el código que la modela, consulta y migra.
• Autenticación y autorización — quién llama y qué puede hacer, aplicado en cada solicitud.
• Trabajo en segundo plano — jobs y tareas programadas para todo lo que no debería bloquear una solicitud: emails, reportes, sincronizaciones, limpiezas.
• Infraestructura — los servidores, contenedores o funciones sobre los que corre todo, más despliegue, logging, monitoreo, backups y escalado.

Las primeras cinco son trabajo de producto. La sexta es operación, y es la parte que los modelos de hosting modernos existen para eliminar.

Arquitecturas de backend

La versión original de este tema describía tres familias — serverless, orientada a servidores y descentralizada — y la taxonomía sigue vigente. Lo que cambió es el default: en 2026 la familia serverless es donde empieza la mayoría de los productos nuevos, y “orientado a servidores” significa cada vez más contenedores en lugar de máquinas.

Backends basados en servidores. Tu equipo aprovisiona máquinas, máquinas virtuales o contenedores, instala un runtime y una base de datos, y los opera. Máximo control, máxima responsabilidad: la capacidad, los parches, la disponibilidad y la rotación de guardias son tuyos.

Los argumentos clásicos a su favor siguen aplicando — un único lugar que comparte datos entre varias aplicaciones, integraciones directas, un solo punto de acceso que asegurar — y la forma por dentro puede ser un monolito o microservicios; el modelo operativo es el mismo.

Backends serverless. Un proveedor opera la infraestructura y cobra por uso. Dos variantes: Function as a Service, donde despliegas código propio como funciones que escalan desde cero, y Backend as a Service, donde la base de datos, la auth, las APIs, el almacenamiento y las funciones llegan como una plataforma gestionada.

La ganancia es velocidad — no hay servidores que construir antes de la primera funcionalidad — y lo que se cede es control sobre las capas más bajas. La escalera completa de modelos de hosting se compara en IaaS vs. PaaS vs. BaaS vs. FaaS.

Backends descentralizados. Sin operador único; el estado vive en una red peer-to-peer, normalmente open-source, como en las blockchains y el almacenamiento direccionado por contenido. Bitcoin y Ethereum son los ejemplos canónicos, y el frontend de una app así suele hospedarse de la misma manera, en redes como IPFS o Swarm en lugar de en un servidor.

Resistencia a la censura y ningún punto central de control, a costa de latencia, throughput y un modelo de programación muy distinto. Un nicho con usos reales, no un reemplazo de propósito general para los otros dos.

Basado en servidores vs. serverless vs. BaaS vs. descentralizado

Casos de uso comunes

• Apps móviles y web — cuentas, datos que sobreviven a la sesión y sincronización entre dispositivos necesitan un lado del servidor.
• Productos multiusuario — cualquier cosa donde la acción de un usuario deba ser vista por otro: colaboración, marketplaces, chat.
• Pagos y operaciones sensibles — los secretos y el dinero nunca pertenecen al dispositivo; el backend guarda las claves y habla con los proveedores.
• Integraciones y automatización — webhooks, jobs programados y pipelines que corren haya o no un usuario conectado.
• Funcionalidades de IA — las llamadas a modelos, la recuperación y la ejecución de herramientas corren del lado del servidor, donde las claves se mantienen privadas y los resultados se pueden cachear y auditar.

¿Qué enfoque de backend deberías elegir? Matriz de decisión

Limitaciones y trade-offs

• El backend es donde los errores se vuelven problema de todos. Un bug de frontend rompe una pantalla; un bug de backend corrompe datos o los expone. La validación, los permisos y las pruebas pesan más aquí que en cualquier otra parte del código.
• La operación nunca desaparece — se mueve. Las plataformas gestionadas absorben servidores, escalado y backups, pero alguien sigue siendo dueño del modelo de datos, las reglas de acceso y el presupuesto. Elige un modelo por las responsabilidades que quieres conservar, no por las que quieres olvidar.
• Control y velocidad tiran en direcciones opuestas. Cuanto más del stack operas tú mismo, más puedes personalizar y más tarda todo; cuanto menos operas, más rápido lanzas y más dependes del roadmap y los precios de un proveedor.
• La red es parte del contrato. Cada llamada del frontend al backend puede ser lenta, fallar a medias o llegar dos veces; los presupuestos de latencia, los reintentos y la idempotencia son asuntos del backend desde el primer endpoint.
• “Serverless” sigue teniendo servidores. Los cold starts, los límites de ejecución y el cobro por uso son restricciones reales; simplemente son las máquinas de otro con una curva de costo distinta.

El backend en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code.

Mapeado sobre las capas de arriba: la capa de datos y la capa de API se generan a partir de tu modelo de datos, la autenticación y los permisos a nivel de clase hacen cumplir quién puede hacer qué en cada solicitud, Cloud Code aloja la lógica de negocio y los jobs en segundo plano específicos de tu producto, y la capa de infraestructura — hosting, escalado, backups, monitoreo — es trabajo de la plataforma.

La solicitud diseccionada al inicio de esta página es formato de cable real de Back4app, y los SDKs que la enviaron son la forma en que el frontend habla con ese backend desde cada plataforma principal.