--- term: 'Backend (lado del servidor)' seoTitle: '¿Qué es un Backend? Significado, Frontend vs. Backend y Tipos' headline: '¿Qué es un backend? El lado del servidor de una aplicación, explicado' slug: backend category: backend-compute shortDefinition: '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.' relatedTerms: - baas-vs-custom-backend - api - serverless-architecture - backend-sdk - decoupled-architecture - scaling-application-backends contrastsWith: - decoupled-architecture faq: - question: '¿Qué significa backend?' answer: 'La parte de una aplicación que los usuarios nunca ven: el código del lado del servidor, la base de datos y la infraestructura que reciben las solicitudes de la interfaz, aplican las reglas de negocio, leen y escriben datos y devuelven una respuesta. Si el frontend es el tablero de un coche, el backend es el motor y el sistema de combustible — invisibles desde el asiento, responsables de todo lo que se mueve.' - question: '¿Qué es un frontend?' answer: 'La parte de una aplicación que los usuarios ven y con la que interactúan: las pantallas, botones, formularios y navegación que un navegador o una app móvil renderiza en su dispositivo. Es la capa de presentación. Captura la entrada y muestra resultados, pero las decisiones y los datos detrás de esos resultados viven en el backend, al que el frontend llega a través de una API.' - question: '¿Cuál es la diferencia entre frontend y backend?' answer: 'Dónde corre el código y con quién habla. El frontend corre en el dispositivo del usuario — navegador o app — y renderiza pantallas, captura la entrada y llama APIs. El backend corre en servidores que tú (o una plataforma) controlas y es dueño de los datos, las reglas y la seguridad. Los dos se encuentran en una API: el frontend pregunta, el backend decide y responde.' - question: '¿El backend es lo mismo que el servidor?' answer: 'No exactamente. Un servidor es una máquina o un proceso que responde solicitudes de red; el backend es todo el sistema detrás de la interfaz — código de aplicación, base de datos, autenticación, jobs en segundo plano y los servidores en los que corre. Un backend puede abarcar muchos servidores, y en las arquitecturas serverless el "servidor" se alquila por milisegundo y nunca se gestiona directamente.' - question: '¿Qué tipos de backend existen?' answer: 'Agrupados por quién opera los servidores: backends basados en servidores, donde tu equipo aprovisiona y opera máquinas o contenedores; backends serverless, donde un proveedor opera la infraestructura y cobra por uso — Function as a Service para código propio y Backend as a Service para el stack completo –; y backends descentralizados, donde ninguna parte opera el sistema por sí sola y los pares comparten el estado en una red. La mayoría de los productos de hoy combina los dos primeros.' - question: '¿Una base de datos es un backend?' answer: 'No — es un componente de un backend, normalmente el más importante. Una base de datos guarda y recupera datos; el backend la envuelve con una API, validación, permisos y lógica para que los clientes nunca la toquen directamente. Una plataforma que expone una base de datos mediante APIs generadas con auth y reglas de acceso es un backend; una base de datos a secas no lo es.' - question: '¿Qué es Backend as a Service (BaaS)?' answer: 'Un backend gestionado que configuras en lugar de construir: una base de datos hospedada, APIs REST y GraphQL generadas automáticamente, autenticación de usuarios, almacenamiento de archivos, notificaciones push y funciones serverless para la lógica propia. Sigues escribiendo el frontend y las reglas que importan para tu producto; la plataforma opera el resto. Es la vía más rápida a un backend de producción para una app móvil o web.' - question: '¿Qué hace un desarrollador backend?' answer: 'Diseña el modelo de datos, construye y documenta las APIs, implementa la lógica de negocio y los jobs en segundo plano, asegura la autenticación y los permisos, y mantiene el sistema rápido y disponible a medida que crece el tráfico. En la práctica, una parte grande del trabajo es operación — despliegues, monitoreo, escalado, backups –, que es exactamente la parte que absorben las plataformas gestionadas.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'Introduction to the server side — MDN Web Docs' url: 'https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Introduction' - name: 'Client-Server overview — MDN Web Docs' url: 'https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Client-Server_overview' - name: 'RFC 9110 — HTTP Semantics' url: 'https://www.rfc-editor.org/rfc/rfc9110' - name: 'The Twelve-Factor App' url: 'https://12factor.net/' - name: 'Frontend and backend — Wikipedia' url: 'https://en.wikipedia.org/wiki/Frontend_and_backend' cta: title: 'Un backend de producción, sin construir uno' text: 'Back4app le da a tu app una base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones de Cloud Code desde el día uno — todo el lado del servidor, configurado en lugar de construido.' linkText: 'Empieza gratis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-10-19' translationKey: backend-meaning --- **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 | Pregunta | Respuesta | | --- | --- | | La definición | Todo lo que hay detrás de la interfaz: código de servidor, base de datos, auth, jobs, infraestructura | | La frontera | Una API — el frontend pregunta, el backend valida, decide y responde | | Las capas | API · lógica de negocio · datos · autenticación · trabajo en segundo plano · infraestructura | | Los modelos de hosting | Basado en servidores · serverless (FaaS y BaaS) · descentralizado | | El default de 2026 | Alquila las partes genéricas (base de datos, auth, APIs); escribe solo la lógica que es tuya | ## 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: ```text 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:** ```javascript // 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 // Flutter / Dart — Back4app Flutter SDK // The frontend asks the backend a question; the backend answers from the database final query = QueryBuilder(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'); ``` **Swift:** ```swift // 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") } } ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // The frontend asks the backend a question; the backend answers from the database val query = ParseQuery.getQuery("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: | | Frontend | Backend | | --- | --- | --- | | Dónde corre | El dispositivo del usuario: navegador, app móvil, escritorio | Servidores que tú o un proveedor controlan | | De qué es dueño | Layout, interacción, estado local, accesibilidad | Datos, reglas de negocio, identidad, seguridad | | Cómo falla | Una pantalla rota para un usuario | Datos incorrectos o caída para todos los usuarios | | Lenguajes típicos | JavaScript/TypeScript, Swift, Kotlin, Dart | JavaScript/TypeScript, Python, Java, Go, C#, Ruby, PHP, Rust | | Qué significa "terminado" | Se ve y se siente bien | Es correcto, seguro y sigue siendo rápido bajo carga | | Quién ve el código | Cualquiera — se envía al dispositivo | Solo tu equipo — nunca sale del servidor | 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](/glossary/es/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. ```mermaid flowchart LR accTitle: Frontend, backend y la API entre ellos accDescr: Un frontend en el dispositivo del usuario envía solicitudes a través de una API al backend, que contiene lógica de negocio, autenticación y jobs en segundo plano, y habla con una base de datos y servicios externos antes de devolver una respuesta. F["Frontend
(navegador, app móvil)"] -->|"solicitud por la API"| B["Backend
lógica · auth · jobs"] B --> D[("Base de datos")] B --> S["Servicios externos
(pagos, email, IA)"] B -->|"respuesta"| F ``` ## 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](/glossary/es/api-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](/glossary/es/nosql-vs-sql/) y el código que la modela, consulta y migra. - **Autenticación y autorización** — [quién llama y qué puede hacer](/glossary/es/autenticacion-vs-autorizacion/), aplicado en cada solicitud. - **Trabajo en segundo plano** — [jobs y tareas programadas](/glossary/es/jobs-en-segundo-plano/) 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](/glossary/es/escalabilidad-de-backend/). 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](/glossary/es/microservicios-vs-monolito/); el modelo operativo es el mismo. **Backends serverless.** Un proveedor opera la infraestructura y cobra por uso. Dos variantes: [Function as a Service](/glossary/es/arquitectura-serverless/), 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](/glossary/es/modelos-de-servicio-en-la-nube/). **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 | Modelo | Quién opera los servidores | Tú escribes | Escala por | Ideal para | | --- | --- | --- | --- | --- | | Basado en servidores | Tu equipo | Todo: app, capa de datos, operación | Capacidad que tú añades y gestionas | Requisitos inusuales, control total, equipos de operación existentes | | Serverless (FaaS) | El proveedor | Funciones y la capa de datos | Por invocación, desde cero | Lógica orientada a eventos, tráfico con picos, equipos pequeños | | BaaS | El proveedor | Solo frontend + lógica propia | Por uso, gestionado por la plataforma | Apps móviles y web que necesitan auth, datos y APIs rápido | | Descentralizado | Una red de pares | Smart contracts, clientes | Crecimiento de la red | Sistemas de confianza minimizada, estado público compartido | ## 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 | Tu situación | Elige | | --- | --- | | Un producto móvil o web nuevo que necesita auth, datos y APIs esta semana | BaaS — configura el 80 % genérico, escribe el 20 % que es tuyo | | Lógica orientada a eventos con tráfico a ráfagas y sin una base estable | Funciones serverless | | Requisitos estrictos que las plataformas gestionadas no pueden expresar | Basado en servidores, con contenedores y un plan de operación real | | Un sistema cuyo sentido es que nadie lo opere | Descentralizado | | Un backend basado en servidores existente que es lento de cambiar | Mueve primero las partes genéricas a un [backend gestionado](/glossary/es/baas-vs-backend-propio/), conserva el núcleo propio | ## 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](/glossary/es/vendor-lock-in-en-la-nube/) 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](/glossary/es/permisos-de-clase-clp/) hacen cumplir quién puede hacer qué en cada solicitud, [Cloud Code](/glossary/es/cloud-code-funciones-serverless/) 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](/glossary/es/sdk-de-backend/) que la enviaron son la forma en que el frontend habla con ese backend desde cada plataforma principal.