Opinado o no: elegir el marco adecuado para el trabajo

Hay una pregunta fundamental con la que comienza cada proyecto: acepte la libertad de implementar sus propias soluciones junto con las cargas que conlleva, o aproveche la oportunidad de usar valores predeterminados sensatos que le permitan avanzar rápidamente, pero ocultan una multitud de decisiones y establecen usted en un camino prescriptivo. Decidir si utilizar o no un marco obstinado para su próximo proyecto tendrá implicaciones significativas, tanto a corto plazo para llevar el producto al mercado a tiempo como a largo plazo. Puede afectar la facilidad de mantenimiento y modificación de su aplicación para satisfacer las necesidades cambiantes. Es posible que la respuesta no siempre sea clara o fácil, pero lo ayudará a saber cuándo elegir el gran marco obstinado. En este artículo, veremos algunos marcos obstinados versus no obstinados y qué casos de uso tienen sentido para tomar cualquiera de los dos caminos. También aplicaremos este pensamiento a casos de uso que se ajusten mejor a una plataforma como servicio (PaaS) obstinada o para una infraestructura como servicio (IaaS) menos testaruda. Esto lo ayudará a tomar la mejor decisión al crear sus propias aplicaciones. ¿Qué son los Marcos “Opinionados”? Un marco, por definición, hace algunas suposiciones sobre la arquitectura, las mejores prácticas y las convenciones. Esto a menudo es útil para los desarrolladores y arquitectos, ya que proporciona un camino bien transitado para futuras decisiones arquitectónicas, y también puede ayudarlo a terminar con una base de código predecible, consistente y fácil de entender para otros desarrolladores. Pero incluso cuando dos marcos diferentes están escritos en el mismo idioma, pueden variar drásticamente en función de qué tan transitado sea ese camino. En un extremo, un marco se llama "obstinado". Esto significa que los diseñadores del marco han creado un "camino feliz" que hace que el desarrollo sea más fácil y rápido para las personas que usan su marco, siempre que sigan suposiciones específicas. Elegir un marco obstinado puede facilitar en gran medida el desarrollo de su aplicación, cuando sus necesidades coincidan o se alineen con el propósito del marco. Las convenciones impuestas o estrictas también pueden facilitar que los nuevos desarrolladores se unan y comiencen a proporcionar valor de inmediato. Sin embargo, a veces también significa que esas suposiciones son intencionalmente difíciles de violar. Esto puede significar una serie de cosas en la práctica, desde convenciones estrictas o aplicadas hasta la falta de extensibilidad o tal vez la restricción a un único conjunto de herramientas. En última instancia, ser obstinado significa que el marco funciona mejor como se pretendía originalmente, y variarlo a veces solo se puede hacer con mucho dolor. Decidir utilizar un marco obstinado es tanto una decisión empresarial como técnica. Si bien puede beneficiarse de la facilidad de inicio, la decisión de utilizar un marco obstinado puede tener un costo futuro si lo que necesita para extender su aplicación excede las capacidades del marco. Para agregar profundidad, veamos algunos ejemplos específicos de marcos frontend y backend. Veremos Angular vs React y Django vs Flask, pero esta línea de pensamiento también se aplicará a otros marcos como Vue, Ruby on Rails y más. Angular versus reaccionar En aras del argumento, consideraremos React como un marco sin opiniones, mientras que Angular es uno con opiniones fuertes. Ambos marcos brindan la capacidad de crear aplicaciones web de una sola página con todas las funciones y ofrecen ricas bibliotecas de componentes además de grandes bases de usuarios. Para propósitos de comparación, consideremos cómo cada marco maneja el enlace de datos. Angular proporciona un enlace de datos bidireccional listo para usar, mientras que React proporciona un enlace de datos unidireccional. Para profundizar en esto, Angular asume una arquitectura de tipo MVVM o MVC y proporciona enlaces bidireccionales entre su modelo (donde viven sus datos) y su vista (lo que se representa en la página). Eso significa que cuando un usuario cambia algo en la página, su modelo se actualiza automáticamente. React, por otro lado, te obliga a administrar esta actualización tú mismo. Como un marco fuertemente obstinado, Angular hace suposiciones sobre cómo proporcionará datos a sus componentes y hará que el estado esté disponible. Proporciona todos los vínculos necesarios para que todo lo que tenga que hacer sea declarar una variable y usarla en el modelo, sin preocuparse de cómo se actualiza la vista. Esto se llama enlace de datos, y es algo que Angular hace de manera inmediata. React, por otro lado, no proporciona esto porque tiene que manejar explícitamente los eventos de cambio en sus componentes. En el caso de cambios en el modelo que no sean iniciados por la interfaz de usuario, debe actualizar explícitamente el estado llamando a setState o usando un enlace de estado, que luego garantizará automáticamente que la vista se actualice. Esto puede generar más código en cada componente, o incluso usar otras bibliotecas como Redux para ayudar a administrar el estado de los componentes, pero también ofrece un mayor grado de personalización. React también es más liviano que Angular, por lo que si no necesita todas las capacidades integradas de Angular, React podría reducir el uso de datos y el tiempo de carga para los usuarios finales, así como la carga cognitiva de los desarrolladores que trabajan en su aplicación. Angular hace suposiciones similares sobre la conectividad de la red, la elección del idioma y las cadenas de herramientas de construcción, por ejemplo. Esto ahorrará tiempo cuando desee un entorno completamente integrado que "simplemente funcione" sin tener que considerar cada componente por separado. En última instancia, esto se reduce a una cuestión de preferencia. Tener una elección hecha por usted puede simplificar el desarrollo y enviarlo por un camino prescriptivo, lo que puede ahorrarle mucho tiempo al crear rápidamente una aplicación. En igualdad de condiciones y suponiendo que tenga desarrolladores compatibles con Angular y React, si está creando un prototipo de aplicación rápido y no quiere sufrir el dolor de cabeza de la configuración y la inversión inicial necesaria para crear una aplicación React, Angular es una elección cómoda y fácil. Su uso puede ayudar a que su aplicación despegue rápidamente, ya que se deben tomar menos decisiones y se debe integrar menos código para llegar a una solución funcional. Los conjuntos de herramientas de compilación también están muy estandarizados para Angular, y existe una gran cantidad de scripts de creación para iniciar proyectos rápidamente. Si, por otro lado, sabe que está desarrollando una aplicación web/móvil muy personalizada y desea tener la flexibilidad de hacer las cosas de manera gradual para crear una aplicación web de alto rendimiento y capacidad, React es sin duda una mejor elección Django contra Flask Se pueden hacer los mismos argumentos en torno a la elección entre Django y Flask, pero con diferentes casos de uso. Django es muy obstinado; El matraz no lo es. Django proporciona una experiencia completa, que incluye un ORM, un panel de administración y una estructura de directorios basada en convenciones para todas sus aplicaciones. Flask, por otro lado, brinda una simplicidad absoluta, un alto grado de control y la capacidad de seguir casi cualquier ruta arquitectónica que desee. También es más liviano que Django porque integra menos funciones. Ambos marcos se ejecutan en WSGI y ofrecen plantillas listas para usar. Querrá usar Django sobre Flask cuando esté creando una aplicación o servicio web bastante estándar, como un sitio de noticias, un sitio web de una organización, un sitio web de comercio electrónico o tal vez un blog. Django proporciona una tonelada de ejemplos, aplicaciones de inicio y un camino fácil y transitado para que lo sigas. Si está creando un producto con necesidades mínimas, como una pequeña API interna, o si necesita seleccionar componentes específicos, como autenticación personalizada o acceso a la capa de datos, entonces Flask es una mejor opción. Le permite seleccionar y elegir componentes en cada etapa de la arquitectura de su producto. También es una mejor opción si está creando algo completamente personalizado y no tiene un camino funcional y arquitectónico común a seguir. Flask te permite ser más flexible a la hora de tomar decisiones y no te obliga a seguir un camino predefinido. PaaS frente a IaaS Los marcos pueden ser obstinados. Y también pueden hacerlo las piezas de su infraestructura. Si se pregunta qué tan obstinada es su plataforma de implementación, la diferencia entre PaaS e IaaS se vuelve mucho más evidente. Las ofertas de PaaS le brindan un entorno llave en mano en el que construir sus aplicaciones donde las consideraciones de red, la configuración de la infraestructura, el cómputo y el almacenamiento se administran por usted. En nuestro análogo, PaaS es el marco obstinado, que hace muchas de las suposiciones de arquitectura de implementación y tiempo de ejecución por usted. Heroku y Elastic Beanstalk son ejemplos de plataformas PaaS. Lo que gana con PaaS es una plataforma administrada rentable y fácilmente escalable que le permite concentrarse en crear e implementar su aplicación. Por el contrario, los marcos de IaaS son relativamente sin opiniones y proporcionan una infraestructura flexible que puede personalizar, aprovisionar e implementar fácilmente. Si bien la infraestructura del centro de datos y del servidor está administrada, debe considerar y abordar específicamente el tamaño, la planificación de la capacidad, el soporte de la infraestructura, la integración de servicios y la arquitectura de la aplicación. Microsoft Azure, AWS y GCP ofrecen IaaS. IaaS es una excelente opción cuando la flexibilidad es una necesidad o cuando una aplicación necesita: Un sistema operativo específico Un entorno informático dedicado y no compartido Recursos desplegados en una red virtual Un entorno de implementación no cubierto por las ofertas tradicionales de PaaS En pocas palabras, use PaaS cuando desee crear su producto rápidamente sin reinventar la rueda y elija IaaS cuando tenga necesidades personalizadas o no estándar. Lo más probable es que PaaS funcione para la mayoría de los casos de uso y le evitará perder el tiempo administrando y solucionando problemas de capas de su pila que desearía que funcionaran. es un producto PaaS más establecido que se escala con su aplicación y ofrece una variedad de opciones de plataforma, para que no quede atrapado por las primeras decisiones arquitectónicas o de idioma. Heroku Utiliza patrones de diseño como para ayudarlo a crear una aplicación escalable y mantenible y evitar cometer errores no intencionales. Y si alguna vez alcanza los límites de la plataforma, facilitan la migración a una IaaS menos obstinada, donde tendrá la libertad (y la responsabilidad) de administrar partes más complejas de su infraestructura. la aplicación de doce factores Conclusión Si tiene un objetivo claro y está siguiendo un camino de desarrollo o arquitectura muy transitado, los marcos de referencia pueden ayudarlo a ahorrar tiempo y dinero al hacer que las aplicaciones sean más fáciles de desarrollar e implementar. Un marco obstinado le brinda barandillas, toneladas de código de inicio y optimiza su camino. Pero si sabe que las cosas se desviarán muy rápidamente, entonces debería considerar usar un marco no obstinado desde el principio. Por ejemplo, si desea crear una interfaz de usuario rápida o sabe que su interfaz de usuario usará componentes estándar, y tiene poca o ninguna necesidad de personalizar o modificar el comportamiento de esos componentes de formas no estándar, entonces el marco de referencia Angular puede ser una buena elección sobre React. Sin embargo, si necesita flexibilidad en sus marcos web de Python, o está creando un producto personalizado para el que Django podría no tener ejemplos o código base de fuente abierta, entonces es posible que deba considerar usar Flask sin opiniones. Extender el concepto de obstinado versus no obstinado a las opciones de implementación nos brinda una forma práctica de ver PaaS versus IaaS. Si desea un entorno llave en mano, debe considerar la opción PaaS obstinada. Para necesidades altamente personalizadas, opte por la flexibilidad de IaaS.