Saltar al contenido

Tecnología · APIs en Rust

APIs y backends en Rust con Axum

Axum es el framework con el que se construyen en Rust las API y los servicios web. Cada petición se convierte en datos con forma conocida antes de tocar tu lógica; lo que no encaja se rechaza en la puerta. Desarrollamos backends nuevos con Axum y pasamos a Rust el servicio que hoy se te queda corto.

Se combina con

Fig. 01Torre de capasACCESO · LÍMITE · FORMA · RUTAen vivoFORMALÍMITE422ACCESO429401/pedidos/clientes/stockEn bucle
La petición baja de escalón en escalón, acceso, límite y forma, y solo si los pasa llega al distribuidor que la lleva a su manejador. La que no encaja sale por el lateral hacia el cartel con su respuesta.

Situaciones

Qué puedes resolver con un backend en Axum

Un backend en Rust compensa cuando el servicio es crítico: recibe mucho tráfico, corre en una máquina modesta o un error en él cuesta dinero.

  • Un servicio que no da más de sí

    La API responde despacio en los picos o necesita cada vez más servidores. En Rust, el mismo servicio suele atender más peticiones con menos máquina.

  • Datos mal formados que llegan hasta dentro

    Un campo que falta o viene con otro tipo provoca errores a mitad del proceso. Aquí la petición se comprueba entera al entrar y la lógica solo recibe datos válidos.

  • Un servidor dentro de la propia aplicación

    Una app de escritorio o un equipo en planta que tiene que ofrecer una API a otros programas de la red local, sin instalar nada más.

  • Un servicio que tiene que durar años

    Código que se toca poco y no puede romperse al tocarlo. El compilador señala cada sitio afectado por un cambio antes de publicarlo.

La plantilla: la petición que no tiene la forma esperada no pasa

Qué conviene revisar al empezar

  • Qué peticiones recibe hoy el servicio y cuáles son las críticas
  • Quién lo consume: una web, una app, otros sistemas
  • Qué base de datos y qué servicios externos usa
  • Qué debe seguir igual para quien ya lo llama

Servicios

Qué desarrollamos con Axum

Cuatro tipos de encargo. Lo más frecuente es el tercero: un solo servicio que pasa a Rust mientras el resto se queda donde está.

  • Módulo 1 · Distribuidor

    APIs y backends nuevos

    Rutas, datos de entrada y de salida con forma declarada, acceso a base de datos y documentación de la API generada a partir del propio código.

    Ejemplos de entregables

    • API de una app o un portal
    • Servicio interno entre sistemas
    • Documentación de la API al día
  • Módulo 2 · Capas

    Acceso, límites y registro

    Lo que toda petición atraviesa antes de llegar a la lógica: quién llama, cuántas veces puede hacerlo, qué queda anotado y qué se mide.

    Ejemplos de entregables

    • Acceso por token o por sesión
    • Límite de peticiones por cliente
    • Trazas de cada petición
  • Módulo 3 · Manejadores

    Paso a Rust de un servicio crítico

    El servicio que hoy está en Node.js o en Python y se queda corto, reescrito con el mismo contrato para que quien lo llama no note más cambio que la velocidad.

    Ejemplos de entregables

    • Servicio con el mismo contrato
    • Migración ruta a ruta
    • Comparación de respuestas antes de cambiar
  • Módulo 4 · Línea abierta

    Servidor local y tiempo real

    Una API embebida en una app de escritorio o en un equipo de planta, y canales abiertos para enviar cambios a los clientes según ocurren.

    Ejemplos de entregables

    • API local de una app de escritorio
    • Eventos en vivo por WebSocket
    • Servicio en un equipo sin nube

Un ejemplo en funcionamiento

Una petición bien hecha y cuatro que no

Demostración simulada. Rellena el pedido y envíalo. Prueba a quitar el token, a escribir letras en la cantidad o a enviarlo muchas veces seguidas, y mira en qué capa se detiene cada intento.

Demostración simulada · datos de muestra

La petición

Por dónde pasa

  1. Acceso
  2. Límite
  3. Forma
  4. Manejador

Peticiones que admite ahora3

Respuesta (simulada)

  1. Todavía no se ha enviado nada.

No hay ningún servidor detrás: las capas y sus respuestas están simuladas en tu navegador y nada de lo que escribas se envía. El orden de las comprobaciones es el de un servicio real.

Integración

Cómo encaja con tus sistemas

Una API es la puerta de un sistema. A un lado llaman la web, la app y otros programas; al otro están tus datos y los servicios de los que dependes.

De dónde viene

AxumAPI en Rust con Axumcomprueba, decide y responde

A dónde llega

Dependencias que conviene revisar

  • Qué contrato tiene hoy la API y quién depende de él
  • Qué base de datos se usa y con qué bibliotecas de Rust se accede
  • Dónde se despliega y qué recursos tiene esa máquina
  • Qué servicios externos pueden fallar y qué se responde entonces

Cómo trabajamos y qué entregamos

Cómo trabajamos un encargo con Axum

  1. 01

    Revisión inicial

    Miramos el servicio que hay o el que hace falta: rutas, tráfico, dependencias y lo que hoy falla.

  2. 02

    Alcance

    Escribimos el contrato de la API, las capas por las que pasa cada petición y lo que queda fuera.

  3. 03

    Primera entrega

    Las rutas principales respondiendo contra datos reales, con su documentación y sus medidas.

  4. 04

    Validación

    Lo pruebas con tu web o tu app, con peticiones mal hechas y con carga.

  5. 05

    Documentación

    El contrato, cómo se despliega, qué se mide y cómo añadir una ruta nueva.

Qué recibes al cerrar el encargo

  • El código del servicio en tu repositorio, con sus pruebas
  • La documentación de la API, generada del código
  • La configuración de despliegue
  • La lista de lo que queda fuera y por qué

Preguntas

Preguntas sobre Axum

¿Falta la tuya? Escríbela a info@veodar.com y te respondemos con una pregunta concreta, no con un dossier.

¿Por qué una API en Rust y no en Node.js?

Para la mayoría de los proyectos, Node.js es suficiente y más rápido de desarrollar. Rust compensa cuando el servicio recibe mucho tráfico, corre con pocos recursos o es tan crítico que conviene que el compilador revise cada cambio. Solemos proponerlo para una pieza concreta, no para todo.

¿Hay que reescribir todo el backend?

No. Se puede poner en Rust solo el servicio que lo necesita y dejar el resto donde está. Los dos conviven detrás de la misma dirección y quien llama no distingue cuál responde.

¿Qué significa que las peticiones se comprueban por su forma?

Que cada ruta declara qué datos espera: qué campos, de qué tipo, cuáles son obligatorios. Si la petición no encaja, se rechaza con un mensaje claro antes de ejecutar nada, y tu lógica no tiene que defenderse de datos a medias.

¿Puede una app de escritorio llevar su propia API?

Sí, y es un uso frecuente: la aplicación abre un pequeño servidor en el equipo para que otros programas de la red local le pidan datos o le den órdenes. Con Axum ese servidor va dentro del mismo ejecutable.

¿Qué base de datos se usa?

La que ya tengas, casi siempre. Rust tiene bibliotecas maduras para PostgreSQL, MySQL y SQLite, y algunas comprueban las consultas contra el esquema al compilar. Lo que revisamos al principio es que exista una buena para tu caso.

¿Cómo se despliega?

Como un único ejecutable o una imagen pequeña de contenedor, en tu servidor o en la nube que uses. No necesita un intérprete ni un entorno instalado, lo que simplifica las actualizaciones.

Actualizado:

Otras tecnologías

Con qué se combina

Todas las tecnologías
  • Desarrollo en RustAplicaciones, servicios y módulos que no pueden fallar ni ir lentos. Programamos en Rust el núcleo de tu producto o la pieza que hoy lo frena.
  • Servicios concurrentes con TokioServicios en Rust que atienden muchas conexiones y aparatos a la vez sin bloquearse, con tiempos de espera, reintentos y parada ordenada.
  • Backend con Node.jsAPIs, conexiones entre sistemas y procesos en segundo plano. Automatizamos el intercambio de información entre tu web y tus herramientas de gestión.

Empezar

Cuéntanos qué servicio se te queda corto.

Con saber qué hace, quién lo llama y dónde se resiente nos basta para una primera respuesta.

Qué ayuda a valorarlo

  • Qué hace el servicio y quién lo llama
  • Dónde falla o se queda lento
  • Qué base de datos y dependencias tiene
  • Dónde está desplegado

¿Antes de escribir? Mira cómo presupuestamos un proyecto o las soluciones por área de la empresa.

Fig. 07Manipulador MorseH · O · L · A