Continuación de la historia sobre hellolawyer — un tablón de empleo jurídico. En este post contaré cuáles fueron las soluciones técnicas (malas)

La primera idea fue hacer un bot de Telegram que publicara vacantes de forma personalizada teniendo en cuenta los intereses y filtros seleccionados: ubicación, puesto, formato, áreas del derecho.

Se decidió hacer dos repositorios: uno para el bot y otro para la lógica del backend.

Boy oh boy, it was a mistake.


1. Despliegue problemático — había que implementar el despliegue para dos repositorios.
2. Llamadas de red y contratos — había que configurar la conectividad de red de los dos contenedores. Sí, simplemente docker network, pero había que hacerlo.
3. Modelos de datos repetidos.

Destaco por separado el intento de usar una nueva herramienta interesante para trabajar con la base de datos — edgedb (ahora es www.geldata.com bajo la adquisición de vercel) — en ese entonces todavía estaba en beta. Al final lo reescribimos a asyncpg 😎

4. Refactorizaciones. Cuán insatisfecho estaba con el código que escribí. Pero funcionaba y cumplía su rol: aparecían usuarios. Pero el ingeniero no moría y quería reescribir todo. En tres años de existencia incluso apareció una v2 de la API 😰

Luego decidimos hacer un cliente web...

Una vez más, después de ver videos de moda en YouTube, tomé nextjs. Y por supuesto, todas esas solicitudes había que proxyarlas de nuevo al backend. Por suerte para entonces ya sabía sobre openapi a.k.a swagger. Al menos las solicitudes a ese backend se podían escribir menos.

Luego comenzó otra era. La era del trabajo en la UI, más concretamente en las tarjetas de vacante. Cómo queríamos meter todo allí y que brillaran y fueran bonitas. Y por supuesto, de nuevo hubo intentos de refactorizar las vistas y componentes 💪

Continuará ☕️

La imagen fue generada amablemente por chatgpt