A diferencia del Frontend, donde existe al menos un estándar base, en el Backend la variedad es muchísima entre lenguajes de programación, frameworks, gestores de bases de datos, servidores, etc.
Cuando algo es complejo, una decisión sencilla suele ser decantarse por el camino más transitado y este, hoy en día, es del de Javascript que en el caso de Backend estaría representado por el runtime NodeJS.
Desarrollado en 2009 por Ryan Dahl al frustrarse debido a las capacidades limitadas de los servidores web de entonces. Es multiplataforma, válido para Windows, Mac, y Linux, orientado a eventos y basado en el motor desarrollado por Google para Chrome, V8.
Al ser tan popular, se han creado muchos paquetes de software que pueden ser usados para construir nuestras soluciones, más de 100.000 están disponibles en NPM (Node Package Manager). De este modo los proyectos de software son más fáciles y económicos de implementar.
Sin embargo, esta fortaleza y facilidad de uso también esconde una debilidad. Cada una de estas librerías que yo incorporo a mi código es una “dependencia” de mi programa y además esas dependencias tienen dentro sus propias dependencias con lo que el control sobre lo que hay al final en tu programa es, a veces, cuestionable. A veces, si te paras a analizar tus dependencias, puedes ver que tu código depende de mil librerías de otra gente que ya no es un código que tu controlas.
El resultado de todo esto tiene efecto no solo en la seguridad, sino también en el tamaño de tu programa, ya que cuando instalas todas tus dependencias pueden llegar a ocupar varias decenas de megabytes. Además, solo estamos hablando de código, texto plano, pero esos varios megas pueden fácilmente equivaler a varios millones de líneas de código del que tú no sabes realmente qué hace (sólo sabes lo que su autor te dice que hace).
Tu código depende de mil librerías de otra gente, por lo que no es un código que tu controlas.
La ventaja de ser parte de una comunidad tan grande y dinámica como la de Javascript es que siempre está al día. Cualquier error se arregla rápido, pero también se rompen más cosas y todas esas dependencias tienen efecto en tu código, que puede dejar de funcionar correctamente ya que dependes siempre de paquetes externos.
¿Cuál es la solución? Usar lenguajes alternativos que eviten estas debilidades. Sin embargo, debemos saber que serán lenguajes con una menor comunidad que los respalde con sus trabajos y que, por tanto, tendrás que realizar más trabajo de programación en algunos casos, pues no habrá tantas soluciones útiles ya creadas.
En concreto hablamos de lenguajes como Go o Nim, que hacen compilación estática y que una vez compilado tu ejecutable contenga todo el código que necesitas, incluyendo todas las dependencias, lo que hace que después de la compilación te olvides por completo del manejo de dependencias. Lo único que necesitas para ejecutar tu servidor es copiar tu ejecutable en tu servidor, y ¡ejecutarlo!
¿Cuál es la solución? Usar lenguajes alternativos que eviten estas debilidades
Go o Golang es un lenguaje de programación compilado a nativo y de propósito general. Creado e impulsado por Google en 2007 que, a día de hoy en 2019, ya se puede ver en las listas de los mejores lenguajes de programación entre los 10 primeros, e incluso muchas veces entre los 5 primeros.
Por su parte Nim, antes conocido como Nimrod, es un lenguaje más nuevo, lanzado en 2017 aunque lleva en desarrollo desde 2008. También es de tipo estático y tiene como punto fuerte la rapidez en el tiempo de ejecución. Nim genera código en C que luego es compilado por un compilador de C, lo que da como resultado ejecutables muy pequeños y además puede ser compilado y ejecutado en cualquier plataforma con un compilador de C (prácticamente cualquier hardware).
Todo esto y más lo podéis encontrar en esta magnifica “Interacso Talk” dentro de nuestro canal de Youtube. Todo un curso sobre lo que nos puede aportar conocer otros lenguajes.
