¿Qué son Edge Computing y las Funciones de Edge?

Edge computing es un modelo que ejecuta cómputo cerca de usuarios o fuentes de datos; las funciones de edge son código serverless que corre en POPs de CDN. El término amplio — definido canónicamente por Shi et al. como computación colocada cerca de las fuentes de los datos — abarca IoT de piso de fábrica e infraestructura MEC de telecomunicaciones. Para quien desarrolla backend significa algo específico: funciones pequeñas desplegadas en los mismos puntos de presencia globales que usa una CDN, ejecutándose en el POP más cercano a cada solicitud — la evolución de la CDN de cachear contenido a ejecutar código.

Puntos clave

Una función de edge, y la capa donde vive

// JavaScript — an edge function (web-standard APIs, runs at every POP)
// Gateway logic at the edge; the backend stays the source of truth
export default async function handler(request) {
  const url = new URL(request.url);
  const country = request.headers.get('x-user-country') ?? 'US';

  if (url.pathname === '/' && country !== 'US') {
    return Response.redirect(`${url.origin}/${country.toLowerCase()}/`, 302);
  }
  // Verify a session quickly at the edge; data work goes to the origin
  const auth = request.headers.get('Authorization');
  if (!auth) return new Response('Unauthorized', { status: 401 });

  return fetch(request); // pass through to the origin backend
}

// Flutter / Dart — Back4app Flutter SDK
// The three-layer picture from the client's seat:
// CDN serves static assets · edge handles gateway logic · origin owns data
final query = QueryBuilder<ParseObject>(ParseObject('Post'))
  ..whereEqualTo('status', 'published')
  ..setLimit(20);
final response = await query.query();
// This query talks to the ORIGIN backend — where the database lives.
// Moving it "to the edge" would move the round trip, not remove it.

// iOS / Swift — Back4app Swift SDK
// The three-layer picture from the client's seat:
// CDN serves static assets · edge handles gateway logic · origin owns data
let query = Post.query("status" == "published")
  .limit(20)
let posts = try await query.find()
// This query talks to the ORIGIN backend — where the database lives.
// Moving it "to the edge" would move the round trip, not remove it.

// Android / Kotlin — Back4app Android SDK
// The three-layer picture from the client's seat:
// CDN serves static assets · edge handles gateway logic · origin owns data
val query = ParseQuery.getQuery<ParseObject>("Post")
query.whereEqualTo("status", "published")
query.limit = 20
val posts = query.find()
// This query talks to the ORIGIN backend — where the database lives.
// Moving it "to the edge" would move the round trip, not remove it.

La pestaña de JavaScript es la función de edge en sí — Request/Response estándar web, sin framework, interceptando el tráfico antes del origen. Las pestañas de cliente muestran el otro lado de la arquitectura: los datos de la aplicación siguen fluyendo hacia el backend de origen, porque ahí es donde vive la base de datos — la frase a la que este artículo entero no deja de volver.

Isolates vs. contenedores: por qué el edge arranca en milisegundos

Miles de isolates comparten un único proceso de larga vida por máquina — el mismo mecanismo que mantiene separadas las pestañas del navegador — así que “arrancar” una función significa crear un contexto, no bootear un runtime. Esa arquitectura, y no pools precalentados, es la razón por la que las plataformas de edge pueden afirmar honestamente cold starts cercanos a cero. La cuenta llega en la tercera y cuarta fila: una frontera de aislamiento más débil (parchada con mitigaciones cuidadosas) y un runtime donde buena parte de npm no corre — sin sistema de archivos, sin módulos nativos, sin evaluación dinámica, con la superficie portable ahora en proceso de estandarización como la Minimum Common API.

Edge vs. origen: la división de cargas

La parte honesta: tu base de datos sigue en un solo lugar

La sección que los explicadores de proveedores omiten. Mover el cómputo al edge no mueve los datos — solo reubica la ida y vuelta de usuario → servidor a función → base de datos, y para cargas parlanchinas eso es un retroceso: una función de edge a 5 ms del usuario que hace cinco consultas secuenciales a una base de datos a 150 ms de distancia gasta 750 ms donde una función regional co-ubicada con la base gastaría ~5. La aritmética explica la corrección silenciosa de la industria — algunas grandes plataformas de edge ahora recomiendan sus runtimes regionales para la mayoría de las cargas y agregaron opciones para fijar funciones cerca de la base de datos, la admisión más contundente posible de que la localidad de los datos le gana a la localidad del cómputo. Las correcciones parciales, en orden de practicidad: ejecuta el código pesado en datos en el origen (la tabla de división de arriba); agrupa todo en una sola ida y vuelta cuando el código de edge deba tocar datos; y replica lecturas hacia afuera vía cachés clave-valor de edge — trade-offs de consistencia eventual incluidos. Las funciones de edge ganan cuando terminan en el edge; en el momento en que llaman a casa en cada solicitud, la geografía deja de estar de tu lado.

Cuándo el edge es over-engineering

La mayoría de las aplicaciones son un backend CRUD con una base de usuarios regional — para ellas, un backend en una sola región más una CDN para assets estáticos es más simple y, con frecuencia, más rápido de punta a punta que una capa de edge que hace ida y vuelta a la misma base de datos. Las funciones de edge se ganan su lugar cuando la lógica termina en el edge, para una audiencia distribuida globalmente, en una ruta visible en la latencia — tres condiciones, todas obligatorias. El modelo de costos cuenta la misma historia desde el otro lado: las plataformas de edge cobran por solicitud más milisegundos de CPU (barato para lógica delgada de gateway), mientras que las funciones regionales cobran duración de reloj — incluido el tiempo que tu código pasa esperando a la base de datos junto a la cual debería estar sentado.

Casos de uso comunes

• Puertas de autenticación — verifica un token de sesión en el POP; las solicitudes no autenticadas nunca cruzan el océano.
• Geo-personalización — idioma, moneda y enrutamiento de compliance decididos a milisegundos del usuario.
• Buckets de A/B y de features — asignación de cookie en el edge, consistente antes incluso de que cargue la página.
• Rate limiting y defensa contra bots — absorbe el abuso en el perímetro, con contadores por POP en KV de edge.
• Edge computing amplio — el sentido IoT/telecom: sensores de fábrica e infraestructura 5G procesando localmente, la profundidad de otro artículo reconocida en una línea.

¿Deberías usar funciones de edge? Matriz de decisión

Limitaciones y trade-offs

• El runtime es un subconjunto. Solo APIs estándar web; los ORMs con bindings nativos, las bibliotecas de imágenes y el código que depende del sistema de archivos no corren — revisa el árbol de dependencias antes de comprometerte.
• Los topes de CPU son estrictos. Decenas de milisegundos de cómputo es el presupuesto; las funciones de edge moldean el tráfico, no lo procesan.
• El estado vive en otro lado por diseño. Toda necesidad stateful se enruta al origen o a un KV de edge con semántica de consistencia eventual — ninguno de los dos sale gratis.
• Depurar es distribuido. Reproducir un bug que solo ocurre en un POP bajo una geografía es una disciplina aparte; loguear centralizadamente desde todas partes es la mitigación.
• El péndulo oscila. Los defaults edge-first ya se revirtieron una vez; trata el edge como una herramienta precisa para lógica de gateway, no como una identidad de arquitectura.

Edge 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. En el dibujo de tres capas que traza este artículo, Back4app es el origen bien hecho: la base de datos y la lógica de negocio en Cloud Code viven juntas — la co-ubicación que hace rápido el trabajo con datos — detrás de una CDN que sirve archivos y assets estáticos desde los mismos POPs que usaría una capa de edge. Las funciones de edge encajan entonces al frente como lógica delgada de gateway donde se cumplen las tres condiciones: una redirección aquí, una verificación de token allá, delegando en un origen que es dueño de los datos y aplica ACLs en cada solicitud. La lección de arquitectura que enseña la sección honesta — cómputo cerca del usuario, trabajo con datos cerca de los datos — es exactamente esta división, con cada capa haciendo la parte que la geografía favorece.