Al principio…

Vamos a empezar desde el principio. Comenzamos con una pila de backend que comprendía GraphQL, PostgreSQL y, por supuesto, GoLang. Un equipo de ingeniería comienza como un grupo de dos personas: una persona en el backend y otra en el frontend que trabajaba en una aplicación para iOS. Cuando un miembro se une al equipo, estos dos ingenieros se habían ido, pero dejaron un backend lleno de problemas.

No se utilizó ORM, por lo que las consultas a la base de datos se realizaron de forma explícita. Las consultas escritas eran tan ineficientes que siguieron alcanzando los límites de memoria y encontraban largos tiempos de espera antes de que se cumplieran las consultas. El código no tenía arquitectura; era un completo revoltijo de código con archivos por todas partes. No se utilizó ninguna biblioteca GraphQL con GoLang. Estaba claro que el ingeniero de backend anterior estaba tratando de ir completamente a por el caramelo, lo que no era un camino ideal a seguir si desea escalar rápidamente.

GoLang en sí mismo no era el problema

Ninguno de estos problemas es un problema específico de GoLang. Estos fueron problemas introducidos por un ingeniero que no era competente con GoLang. Esto presentó un problema al emprendimiento.

Hay muy pocos ingenieros de GoLang e incluso menos competentes. se encontraban contratando y despidiendo a dos ingenieros de GoLang, cada uno de los cuales intentaba solucionar los problemas en su backend, pero sin éxito. Los ingenieros competentes son caros y, en ese momento, están mucho más allá del presupuesto de un joven emprendimiento.

Como emprendimiento, estaban corriendo para llevar una versión MVP de su  aplicación al mercado y esto significaba que necesitn velocidad. Un pequeño conjunto de bibliotecas disponibles para GoLang y GraphQL, junto con una pequeña comunidad, significaba que estaban abriéndose camino a través de problemas a un ritmo lento. Agregue a esto la inexperiencia con GoLang, pasaron más tiempo solucionando problemas que construyendo funciones. La aplicación en sí estaba destinada a volverse más compleja, lo que significaba que las cosas no eran sostenibles a largo plazo. Necesitn una alternativa.

El cambio de GoLang a NodeJS

En algún momento, se sentaron a discutir la reescritura del backend. Necesitaban abordar los siguientes problemas:

1. Necesitaban un ingeniero de backend competente a un precio de mercado justo que su  emprendimiento pudiera pagar.
2. Necesitaban una pila de backend con muchas soluciones prefabricadas para problemas comunes para moverse a gran velocidad.
3. Necesitan una pila de backend con suficientes recursos para resolver problemas menos comunes a medida que se acercaban a la complejidad.

La decisión fue reemplazar GoLang con NodeJS. Esto abordó todos sus problemas que realmente se centraron en la velocidad y el costo.

• NodeJS tiene un mercado de ingenieros más grande disponible que GoLang.
• Los ingenieros de NodeJS con experiencia son mucho más baratos que los ingenieros de GoLang.
• NodeJS tiene muchos paquetes existentes para resolver problemas comunes que nos permiten concentrarnos en construir nuestra aplicación y no en arreglarla.

Para concluir, su decisión de cambiarse a NodeJS se basó en gran medida en la dinámica empresarial de nuestra puesta en marcha. Mientras que a menudo se debate si NodeJS o GoLang encajan en su proyecto dependiendo de los méritos técnicos del proyecto, el suyo se redujo a los haría avanzar del prototipo a MVP en un período de tiempo razonable.