A lo largo de tu carrera profesional uno se enfrenta a decisiones que son determinantes para que el desarrollo de un producto o proyecto termine con éxito. Si estás al día con el ecosistema de JavaScript, y concretamente, con el mundo frontend, sabrás bien que el abanico de frameworks y librerías ha crecido a un ritmo vertiginoso. Tal variedad de opciones, además del afán de que querer “estar a la última” que solemos tener los desarrolladores, pueden llevarnos a que elegir una tecnología, librería o framework concretos no sea trivial.
Aunque el desarrollo web no forme parte del core de soluciones que queramos ofrecer en Keepler Data Tech a nuestros clientes, sí puede haber casos en los que el cliente demande una interfaz web y, por tanto, tener que enfrentarnos a decidir qué tecnologías se ajustan más para satisfacer sus requisitos. Por ejemplo: un cliente puede demandar un pequeño portal de gestión de sus datos o un pequeño portal con dashboards de AWS Quicksight embebidos en él, etc.
Independientemente del alcance de la interfaz web, lo que es seguro es que conllevará el desarrollo de la propia interfaz (frontend) más todos aquellos servicios (backend) que este consuma, así como su despliegue para ser utilizado por sus usuarios. Sin entrar al flujo de desarrollo típico de una web desde la idea a su materialización (que daría para otro artículo independiente), lo que es seguro es que, en una organización especializada en Cloud pública, BigData, Machine Learning, IoT, etc. como es Keepler Data Tech, es de vital importancia que el desarrollo frontend aporte siempre un plus de valor al producto final sin comprometer los plazos de entrega ni su calidad final. Esto implica que, a la hora de elegir las herramientas y tecnologías para desarrollar el frontend, consideramos que se deberían valorar los siguientes aspectos de la tecnología / herramienta:
- Madurez y Comunidad
- Curva de Aprendizaje
- Ritmo de Delivery
Antes de entrar a analizar tecnologías y herramientas concretas, queremos dedicarle unas líneas a cada uno de los puntos anteriores.
Factores para inspeccionar una tecnología
Madurez y comunidad
Para asegurar unos criterios de calidad mínimos y plazos de entrega adecuados, deberíamos optar por soluciones que ya estén asentadas en el mercado, con una buena documentación y que tengan una comunidad de desarrolladores notable de cara a poder buscar soluciones cuando se nos presenten dudas más complejas o para seguir las mejores prácticas posibles. Por supuesto que una tecnología menos madura o con poca comunidad puede cumplir las expectativas pero conllevan un riesgo inherente en el momento en el que se presenten adversidades o casuísticas más complejas.
Curva de aprendizaje
Que una tecnología esté muy asentada en el mercado y que tenga una amplia comunidad no implica que desarrollar con ella con un mínimo dominio sea rápido. Este punto puede ser subjetivo según quién vaya a desarrollar con la tecnología ya que no todos aprendemos igual de rápido y está bastante ligado a los plazos de desarrollo de un proyecto.
Ritmo de delivery
En este punto nos referimos a cómo de rápido es desarrollar funcionalidades con una tecnología concreta. Si desarrollar funcionalidades conlleva un tiempo excesivo frente a otras tecnologías, esta puede no ser la adecuada incluso estando muy asentada o teniendo una curva de aprendizaje sea aceptable.
Caso real (y de éxito) en Keepler
Llegados a este punto, presentamos un caso real con uno de nuestros clientes que demandaba una aplicación web en forma de un portal para la gestión íntegra de sus datos (proyecto de ámbito BigData en Cloud pública e IoT) además de otras funcionalidades que han ido surgiendo a medida que pasaban los Sprints.
El DevTeam constaba de un Cloud Architect y de cuatro Cloud Engineers, de los cuales solamente uno tenía unos años de experiencia previa como frontend. Esto implícitamente obligó a elegir unas tecnologías que facilitaran y agilizaran el desarrollo de la aplicación web.
Tras analizar y valorar múltiples tecnologías y herramientas en el mercado, se optó por GatsbyJs y Ant Design. En base a los factores expuestos anteriormente, vamos a analizar por qué se optó por estas herramientas, qué ventajas proporcionaban frente a otras y cuál ha sido la experiencia final con las mismas.
GatsbyJs
En cuanto a elegir GatsbyJs frente a otras tecnologías, React + Redux, VueJs o Angular (en sus versiones recientes) probablemente el lector pueda pensar que ya el punto de Madurez y Comunidad no se cumple frente a ninguna de las otras, puesto que su primera versión estable data de julio de 2017 mientras que las otras llevan un tiempo mayor en el mercado y con una comunidad más amplia y asentada. Sin embargo, al ritmo que ha evolucionado JavaScript y todo su ecosistema, 2 años y medio es tiempo suficiente para que una tecnología se considere estable y madura.
GatsbyJs se basa en JAMStack y permite al usuario olvidarse del mantenimiento de estados en la aplicación, proclive a problemas y menos flexible ante cambios si nos falta experiencia, ya que cada página (ruta) es independiente de otras. Además, proporciona suficientes soluciones para problemas típicos como la autenticación, autorización, enrutamiento, etc. de manera sencilla. Pese a que GatsbyJs no es las herramienta más popular, sí que goza de una buena comunidad, una rica documentación y, sobre todo, se desarrolla con React, por lo que, en su conjunción, los criterios de Madurez y Comunidad quedan cubiertos de acuerdo a las necesidades.
Respecto a la Curva de Aprendizaje GatsbyJs, en su scaffold más básico, crea automáticamente la estructura del proyecto web en el cual solamente debemos seguir algunas reglas sencillas, siguiendo los principios de Convention over Configuration. A partir de ahí, la flexibilidad es enorme gracias a las posibilidades de React y porque, gracias a GatsbyJs, nos podemos centrar en desarrollar componentes reutilizables entre páginas (y las propias páginas) y olvidarnos de gestionar sus ciclos de vida o estados, de modo que su integración con las API (backend) se simplifica.
En cuanto al ritmo de delivery, gracias a la capacidad de reutilizar componentes (propios o de terceros), la amplia cantidad de componentes ya desarrollados en la comunidad, la amplitud de la propia comunidad de React y la cantidad de plugins (incluidos para las fases de build, test y deploy de la aplicación web), han permitido desarrollar en pocas semanas una aplicación con múltiples páginas y de complejidad alta alguna de ellas.
Ant Design
Como era de esperar, en el desarrollo frontend suele haber varios agentes involucrados con distintas especializaciones. Una de ellas es la del arte de la maquetación web (desarrolladores con fuertes conocimientos de HTML, CSS, accesibilidad, etc.). Por la naturaleza de los miembros de Keepler, este es un perfil inusual entre nosotros, por lo que encontrar una herramienta que permita mostrar a nuestros clientes una aplicación web atractiva y coherente, y sin complicar al desarrollo a personas menos expertas en maquetación, es clave.
Lo más probable es que en primera instancia alguien hubiera pensado en Bootstrap para cubrir esta necesidad pero, sin embargo, se optó por una solución en la que se proporcionara un catálogo de componentes visualmente uniforme y, si procediera, sobreescribir sus estilos a demanda. Una de las ventajas de Ant Design frente a Bootstrap es que no solo cubre la parte visual de la aplicación web, sino que cubre también el desarrollo de muchos componentes funcionales (componentes React) gracias a su rico catálogo.
Utilizar Ant Design ha permitido, en muchos casos, simplemente “pegar” componentes en su HTML (JSX), configurar cada uno de ellos y conectarlos entre sí sin tener que hacer desarrollos propios, por lo que desarrollar páginas en algunos casos es inmediato. Esto hace que se cumplan nuestros requisitos de Curva de Aprendizaje y Ritmo de delivery. La primera, por ser un componente React como cualquier otro y, la segunda, por lo anteriormente expuesto.
En cuanto a la Madurez y Comunidad, Ant Design goza de varios años de recorrido y una amplia comunidad, lo más importante y lo que valoramos (al ser simplemente componentes React) es que su documentación fuera la adecuada y, en realidad, resulta ser excelente.
Pese a todo, existen multitud de librerías visuales para React en la comunidad, como Material UI, que seguramente probaremos en algún momento.
Conclusiones
Independientemente de las tecnologías por las que uno se decida, lo importante es que estas se adecúen lo mejor posible a cada casuística, dedicando un tiempo suficiente a analizar pros y contras de cada opción ya que, una vez tomada la decisión y comenzado su desarrollo, es poco probable que haya marcha atrás.
No hay una solución única ni una tecnología mejor que la otra, igual que sucede con un lenguaje de programación. Lo que hay es un amplio conjunto de opciones que, si analizamos objetivamente cuál nos conviene más para resolver un problema y no nos dejamos influir por modas, pueden hacernos conseguir más casos de éxito para nuestros clientes y para nuestra organización. Además, nos permite enriquecernos a nosotros mismos como profesionales gracias al aprendizaje de nuevas tecnologías y la aplicación efectiva de nuestras capacidades analíticas en casos reales.
Y tú, ¿qué criterios sigues para escoger una tecnología entre un amplio abanico de opciones?
Imagen: Unsplash | @bdchu614
Deja un comentario