← Todos los casos de estudio

Caso de estudio · 2023 — 26

Resolver los problemas en la capa arquitectónica correcta

La pantalla lenta casi nunca es un problema de frontend. Ser full-stack es lo que te permite arreglarla donde realmente vive.

ReactNode.jsGraphQL / Apollo ServerMongoDBREST APIs

Contexto

A lo largo de tres roles — Sophos, SmartBeemo y House Edge — el mismo patrón aparecía una y otra vez mientras construía funcionalidades: una pantalla era lenta, o un endpoint no devolvía exactamente lo que la UI necesitaba. La jugada fácil es parcharlo en el frontend. La mejor jugada suele estar en otra parte.

Desafío

Cuando una funcionalidad rinde mal, el síntoma aparece en la UI, así que ahí es donde los equipos suelen intentar arreglarlo — añadiendo workarounds del lado del cliente, peticiones extra, o remodelado defensivo de los datos. Eso enmascara el problema en lugar de resolverlo, y se acumula con el tiempo.

Arquitectura

El hábito que desarrollé es diagnosticar qué capa es dueña del problema, y arreglarlo ahí. El método es consistente cada vez:

  1. Entender qué necesita realmente el consumidor — normalmente el frontend.
  2. Analizar el endpoint y la consulta detrás de él.
  3. Encontrar el over-fetching o la ineficiencia.
  4. Arreglarlo en la capa que es dueña del problema.
  5. Confirmar que el frontend sigue comportándose bien.

Ser genuinamente full-stack es la condición habilitante: no puedes arreglar en la capa correcta si solo puedes ver una capa.

Implementación

  • En Sophos, cuando los endpoints del dashboard bancario no devolvían lo que el frontend necesitaba o las consultas eran lentas, hice ajustes de backend y API en lugar de forzar workarounds en la UI.
  • En SmartBeemo, el trabajo de rendimiento consistió en revisar consultas y recortar lo que la API enviaba al frontend — a veces llegando hasta el propio modelo de datos en MongoDB — lo que redujo los tiempos de carga de página en aproximadamente un 25%.
  • En House Edge, optimicé consultas de backend que corrían sobre conjuntos de datos muy grandes.

El resultado concreto y medido es la reducción de ~25% en tiempos de carga en SmartBeemo; los demás fueron mejoras cualitativas — sistemas más rápidos y limpios, y arreglos que eliminaron problemas en lugar de esconderlos.

Lecciones

Dos cosas se me quedaron grabadas. Primero, resuelve donde el problema realmente está — un arreglo en la capa de API o de datos suele ganarle a tres workarounds en la UI. Segundo, ser full-stack es lo que lo hace posible. Es el mismo instinto detrás de cómo me gusta trabajar en general: ser dueño de una funcionalidad de extremo a extremo, a través de cada capa que toca.

↑↓ navegar · abrir · esc cerrar