En la auditoría nos encargamos de revisarlas, ver con qué nos quedamos y que descartaríamos (como por ejemplo, GraphQL). codely.com/cursos/audit...

- ¿Cuál es la mejor forma de irnos del legacy para poder ganar velocidad?
- ¿Tiene sentido programar nuevas funcionalidades allí?
- ¿Cómo hacemos para que ese código interaccione bien con la IA?

Por todas esas dudas, hicieron 2 propuestas de refactor para poder acabar saliendo del monolito.

Ya 100% publicada esta sesión de auditoría de Arquitectura de Software. codely.com/cursos/audit...

En cambio, si es una buena base, el porcentaje de acierto aumenta mucho.

Por ello desde Green Slope quieren hacer un refactor de la base de su código para que sea escalable.

Para ello nos pidieron que auditáramos su plan de proceso de refactor, y eso hicimos, además de proponerles el nuestro.

Una auditoría diferente a las otras, más centrado en cómo hacer este proceso de refactoring y hacer que sea un éxito.

Esperamos que te guste tanto como a nosotros prepararla. 😊

codely.com/cursos/audit...

Acabamos de publicar la primera parte de su auditoría, donde analizamos a macro diseño cómo poder modernizar una aplicación:

- Compartiendo su código
- Analizando (y descartando) alternativas como GraphQL
- Pasito a pasito

Eso les está pasando a Green Slope, una empresa que gestiona torneos de Golf. Por ello han creado 2 planes de refactoring, para poder salir de ese legacy.

Y nos han pedido que se los auditemos. Y eso hemos hecho.

→ codely.com/cursos/embed...

Donde pasito a pasito dominamos la bd.

Esto hace que añadir funcionalidades que tengan que ver con la IA sea mucho más rápido y sencillo.

Si quieres aprender cómo hacer estas combinaciones y delegar esta generación a la base de datos, acabamos de publicar al 100% el curso de Embeddings automáticos en Postgres.

Por estos motivos, si tenemos que escoger una base de datos generalista a día de hoy, nos quedamos con Postgres.

Además, si combinas peticiones http, con crones y sistema de colas, puedes delegar en la base de datos la generación de embeddings.

Todo de forma nativa a la base de datos (todo funciona mediante tablas que se crea en su propio esquema).

¡Hasta tiene sistema de retries!

Además, con otras extensiones puede ser una base de datos timeseries, de grafos, geoespacial (con PostGIS, muy utilizado en la industria).

✔︎ Ser un sistema de colas MQ
SQS, RabbitMQ… están muy bien, pero si no tenemos experiencia con ellos y nos queremos meter en el mundo de los sistemas de colas de mensajería, con pgmq podemos tenerlo dentro del propio Postgres.

✔︎ Tener un sistema de CRON
Gracias a pg_cron, puedes configurar que cada X tiempo se ejecute una función.

Si lo combinas con la capacidad de HTTP, puedes simplificar mucho tu stack.

✔︎ Hacer peticiones HTTP
Con extensiones como pgsql-http (síncrono) o pg_net (asíncrono) es capaz de hacer llamadas a otros servidores.

Hasta aquí podríamos entender que es una base de datos vitaminadas, pero es que es mucho más que eso.

Y lo es gracias a las extensiones y a la comunidad que tiene.

Con extensiones (algunas creadas por grandes empresas como Timescale o Supabase), Postgres también es capaz de:

Si quieres saber cómo llevar toda esa lógica a Postgres, acabamos de publicar en Codely Pro Standard el curso de Embeddings automáticos en Postgres. 😊

- Comparamos diferentes formas de generarlos
- Trigger vs colas mq vs eventos de dominio
- De la forma más escalable

→ codely.com/cursos/embed...

Conclusión
No siempre es clara la línea entre qué es dominio y qué infraestructura, pero conocer al 100% las herramientas que utilizamos nos puede ayudar a saber donde poner cada cosa.

Una con la que sí que se puede es con Postgres, ya que permite hacer llamadas HTTP con sus triggers + tiene sistema de colas para poder hacerlo más escalable.