Salir del Rabbit Hole SPA con rieles modernos

TL; DR: El sendero SPA está oscuro y lleno de horrores. Puedes luchar sin miedo contra ellos ... o elegir otro camino que te lleve al lugar correcto: los rieles modernos.



Recuerdo haber pensado que Rails se estaba centrando en el objetivo equivocado cuando DHH anunció Turbolinks en 2012. Entonces estaba convencido de que el tiempo de respuesta instantáneo durante la interacción del usuario era la clave para una experiencia de usuario superior. Debido a retrasos en la red, esta interactividad solo es posible si minimiza la dependencia de la red y, en lugar de las llamadas de red, mantiene la mayor parte del estado en el cliente.

Pensé que era necesario para las aplicaciones en las que estaba trabajando. Y con esa opinión, probé muchos enfoques y marcos para implementar la misma plantilla: aplicaciones de una sola página (SPA). Yo creía que SPA es el futuro. Unos años más tarde, no estoy seguro de cuál es el futuro, pero definitivamente quiero encontrar una alternativa.

Hueco de conejo SPA

Una aplicación de una página es una aplicación de JavaScript que, una vez descargada, obtiene el control total sin tener que volver a cargar la página: renderizar, recibir datos del servidor, procesar la interacción del usuario, actualizar la pantalla ...

Dichas aplicaciones se ven más nativas que las páginas web tradicionales, donde la aplicación depende del servidor. Por ejemplo, si usa Trello, puede notar la rapidez con que se crean las tarjetas.

Por supuesto, una gran responsabilidad viene con gran fuerza. En las aplicaciones web tradicionales, su aplicación de servidor incluye un modelo de dominio y reglas comerciales, tecnología de acceso a datos para trabajar con una base de datos y una capa de controlador para controlar cómo se ensamblan las páginas HTML en respuesta a las solicitudes HTTP.

C SPA es un poco más complicado. Aún necesita una aplicación de servidor que incluya su modelo y reglas de dominio, un servidor web, una base de datos y algún tipo de tecnología de acceso a datos ... y un montón de cosas adicionales además:

Para el servidor:

• Una API que satisfaga las necesidades de datos de su cliente
• Un sistema de serialización JSON para el intercambio de datos con el cliente y un sistema de almacenamiento en caché que lo admite.

Para el nuevo cliente de JavaScript:

• Sistema de plantillas para convertir datos a HTML
• Presentación de su modelo de dominio y reglas
• La capa de acceso a datos en la aplicación cliente para transferir datos al servidor
• Sistema para actualizar vistas cuando cambian los datos
• Un sistema para vincular URL y pantallas (espero que no use una dirección para todo, no parece una aplicación web)
• Un sistema para pegar todos los componentes necesarios para mostrar pantallas y obtener datos para esto
• Nuevas plantillas y arquitectura para organizar todo cuando
• Sistema para manejo de errores, registro, seguimiento de excepciones, etc.
• Sistema para generar JSON para solicitudes de servidor
• Marco de prueba automatizado que respalda su SPA
• Un conjunto adicional de pruebas para escribir y apoyar
• Un conjunto adicional de herramientas para ensamblar, empaquetar e implementar una nueva aplicación

En resumen, con SPA tendrá otra aplicación de soporte. Y un nuevo conjunto de problemas para resolver. Y tenga en cuenta que no puede reemplazar una aplicación con otra. Aún necesita la aplicación del servidor (ahora representará JSON en lugar de HTML).

Si nunca ha trabajado con SPA, puede subestimar las dificultades que encontrará. Sé esto porque cometí los mismos errores en el pasado. Renderizar JSON? Yo puedo manejarlo. ¿Un modelo de objeto de dominio rico en JavaScript? Eso suena gracioso Y, ya sabes, este marco resolverá todos estos problemas. Gran pastel!

Mal.

API e intercambio de datos.

La comunicación entre su nueva aplicación y el servidor es un problema complejo.

Hay dos fuerzas opuestas:

• Deberá realizar la menor cantidad posible de solicitudes de servidor para mejorar el rendimiento.
• Convertir un solo registro a JSON es simple. Pero mezclar modelos grandes de varios registros para minimizar el número de consultas no es nada. Deberá desarrollar cuidadosamente la lógica de serialización para optimizar el número de consultas de la base de datos y mantener el rendimiento a nivel.

Además, debe pensar qué descargar y cuándo hacerlo para cada una de sus pantallas. Quiero decir, necesitas un equilibrio entre bootstrap, lo que necesitas de inmediato y lo que se puede cargar perezosamente, y desarrollar una API que te permita hacer esto.

Algunas normas pueden ayudar aquí. API JSON para estandarizar el formato JSON; o GraphQL, para seleccionar solo los datos necesarios, tan complejos como sea necesario, en una consulta. Pero ninguno de ellos te salvará de:

• La elaboración de cada intercambio de datos.
• Implementación de consultas para seleccionar datos de manera eficiente en el servidor

Y ambos aspectos representan una cantidad suficiente de trabajo adicional.

Tiempo de arranque

Las personas están acostumbradas a asociar los SPA con la velocidad, pero la verdad es que hacer que se carguen rápido no es tan fácil. Hay muchas razones para esto:

• Una aplicación necesita datos antes de representar algo, y lleva tiempo analizar una cantidad suficientemente grande de JavaScript.
• Más allá de la solicitud HTTP inicial para descargar la aplicación, generalmente debe realizar una o más solicitudes para obtener los datos JSON necesarios para representar la pantalla.
• El cliente debe convertir JSON a HTML para mostrar al menos algo. Dependiendo del dispositivo y la cantidad de JSON para convertir, esto puede introducir retrasos notables.

Esto no significa que sea imposible forzar la carga rápida del SPA. Solo digo que es difícil y que debes ocuparte de eso, porque no vendrá junto con la arquitectura SPA.

Por ejemplo, Discourse, un SPA basado en Ember, tiene tiempos de carga fantásticos, pero entre otras cosas, precargan una gran cantidad de datos JSON como parte del HTML inicial para no realizar solicitudes adicionales. Y noto que el equipo de Discurso está loco en el buen sentido de la velocidad y sus habilidades están muy por encima del promedio. Piénselo antes de poder reproducirlo fácilmente en su SPA.

Una solución ambiciosa para este problema es el JavaScript isomorfo: muestre su página de inicio en el servidor y entréguela rápidamente al cliente, mientras que en el fondo del SPA se carga y obtiene el control total cuando está listo.

Este enfoque requiere ejecutar el tiempo de ejecución de JavaScript en el servidor, y tampoco está exento de problemas técnicos. Por ejemplo, los desarrolladores deben considerar los eventos de carga de SPA a medida que cambia el proceso de carga.

Me gusta la oportunidad de reutilizar el código en esta idea, pero no he visto una implementación que me permita ir en la dirección opuesta. Además, este proceso de representación de páginas me parece muy divertido:

- Servidor: solicitud a la API del servidor
- Servidor: consulta de base de datos
- Servidor: generar JSON
- Servidor: convierte JSON a HTML
- Cliente: muestra HTML inicial
- Cliente: descargar SPA
- Cliente: analizar HTML inicial y suscribirse a eventos DOM

¿Podría solicitar los datos de la base de datos, generar el HTML y comenzar a trabajar?

Esto no es del todo justo, porque no serás SPA y porque la mayor parte de esta magia está oculta detrás del marco, pero todavía me parece equivocado.

Arquitectura

Desarrollar aplicaciones con una rica interfaz de usuario es difícil. Todo esto se debe a que este es uno de los problemas que inspiró la aparición de un enfoque orientado a objetos y muchos patrones de diseño.

Administrar el estado del cliente es difícil. Los sitios web tradicionales generalmente se centran en pantallas de responsabilidad única que pierden estado cuando se reinician. En SPA, la aplicación es responsable de garantizar que todas las actualizaciones de estado y pantalla durante el uso sean consistentes y pasen sin problemas.

En la práctica, si comenzó a escribir JavaScript en pequeñas porciones para mejorar la interacción, en SPA tendrá que escribir toneladas de código JavaScript adicional. Aquí debes asegurarte de que estás haciendo todo bien.

Hay tantas arquitecturas diferentes como marcos de SPA:

• La mayoría de los marcos difieren de la plantilla MVC tradicional. Ember se inspiró inicialmente en Cocoa MVC, pero cambió mucho su modelo de programación en versiones recientes.
• Existe una tendencia a que los desarrolladores prefieran componentes en lugar de la separación tradicional del controlador y la presentación (algunos marcos, como Ember y Angular, se han movido a este enfoque en versiones recientes). Todos los marcos implementan algún tipo de enlace de datos unidireccional. Se desaconseja la unión de doble cara debido a los efectos secundarios que puede contribuir.
• La mayoría de los marcos incluyen un sistema de enrutamiento que le permite mapear URL y pantallas, y determina cómo instanciar componentes para renderizar. Este es un enfoque web único que no existe en las interfaces de escritorio tradicionales.
• La mayoría de los marcos separan las plantillas HTML del código JavaScript, pero React combina la generación HTML y JavaScript y lo hace con bastante éxito, dado su uso generalizado. También hay una exageración en torno a incrustar CSS en JavaScript. Facebook, con su arquitectura Flux, ha influido bastante en la industria, y los contenedores como Redux, vuex, etc. están fuertemente influenciados por ella.

De todos los marcos que he visto, Ember es mi favorito. Adoro su consistencia y el hecho de que es bastante terco. También me gusta su modelo de programación en versiones recientes, que combina MVC tradicional, componentes y enrutamiento.

Por otro lado, estoy firmemente en contra del campo Flux / Redux. Vi a tanta gente inteligente usándolos que hice todo lo posible para estudiarlo y comprenderlo, y ni una sola vez. No puedo evitar sacudir la cabeza con frustración cuando veo el código. No me veo feliz mientras escribo tal código.

Finalmente, no puedo soportar la combinación de HTML y CSS en componentes llenos de lógica de JavaScript. Entiendo qué problema resuelve esto, pero los problemas que trae este enfoque no hacen que valga la pena.

Dejemos las preferencias personales, la conclusión es que si elige la ruta SPA, tendrá un problema muy difícil: crear la arquitectura de su nueva aplicación correctamente. Y la industria está bastante lejos de acordar cómo hacer esto. Cada año, aparecen nuevos marcos, plantillas y versiones de marcos, que cambian ligeramente el modelo de programación. Tendrá que escribir y mantener una tonelada de código en función de su elección arquitectónica, así que piénselo bien.

Duplicación de código

Cuando trabaje con SPA, probablemente encontrará duplicación de código.

Para su lógica SPA, querrá crear un modelo rico de objetos que representen su área de dominio y lógica empresarial. Y aún necesita lo mismo para la lógica del servidor. Y es cuestión de tiempo antes de comenzar a copiar el código.

Por ejemplo, suponga que está trabajando con facturas. Probablemente tenga una clase Factura en JavaScript que contiene un método total que resume el precio de todos los elementos para que pueda representar el valor. En el servidor, también necesitará la clase Factura con el método total para calcular este costo para enviarlo por correo electrónico. Ves? Las clases de cliente y servidor de Factura implementan la misma lógica. Duplicación de código.

Como se dijo anteriormente, el JavaScript isomorfo podría mitigar este problema y facilitar la reutilización del código. Y digo nivelar, porque la correspondencia entre el cliente y el servidor no siempre es 1 a 1. Deberá asegurarse de que algún código nunca abandone el servidor. Una gran cantidad de código tiene sentido solo para el cliente. Y también, algunos aspectos son simplemente diferentes (por ejemplo, el elemento del servidor puede guardar datos en la base de datos y el cliente puede usar la API remota). Reutilizar el código, incluso si es posible, es un problema complejo.

Puede apostar que no necesita un modelo rico en su SPA y que en su lugar trabajará con objetos JSON / JavaScript directamente, distribuyendo la lógica entre los componentes de la interfaz de usuario. Ahora tiene la misma duplicación de código mezclada con su código de UI, buena suerte con eso.

Y lo mismo sucede si desea plantillas para representar HTML entre el servidor y el cliente. Por ejemplo, para SEO, ¿qué tal generar páginas en el servidor para motores de búsqueda? Deberá volver a escribir sus plantillas en el servidor y asegurarse de que estén sincronizadas con el cliente. Nuevamente duplicación de código.

La necesidad de reproducir la lógica de los patrones en el servidor y el cliente, en mi experiencia, es la fuente de la creciente desgracia de los programadores. Hacer esto una vez es normal. Cuando hagas esto por vigésima vez, te agarrarás la cabeza. Después de haber hecho esto por 50ª vez, pensará si se necesitan todas estas piezas de SPA.

Fragilidad

En mi experiencia, desarrollar buenos SPAs es una tarea mucho más complicada que escribir aplicaciones web con generación de servidores.

Primero, no importa cuán cuidadoso sea, no importa cuántas pruebas escriba. Cuanto más código escriba, más errores tendrá. Y SPA representa (lo siento, si presiono mucho) una gran cantidad de código para escribir y apoyar.

En segundo lugar, como se mencionó anteriormente, desarrollar una GUI rica es complicado y se traduce en sistemas complejos que consisten en muchos elementos que interactúan entre sí. Cuanto más complejo sea el sistema que cree, más errores tendrá. Y en comparación con las aplicaciones web tradicionales que usan MVC, la complejidad de SPA es simplemente una locura.

Por ejemplo, para mantener la coherencia en el servidor, puede usar restricciones en la base de datos, la validación del modelo y las transacciones. Si algo sale mal, está respondiendo con un mensaje de error. En el cliente, todo es un poco más complicado. Tanto puede salir mal porque están sucediendo muchas cosas. Es posible que algunos registros se guarden correctamente y otros no. Quizás se desconectó en medio de algún tipo de operación. Debe asegurarse de que la interfaz de usuario se mantenga constante y que la aplicación se esté recuperando de un error. Todo esto es posible, por supuesto, solo que mucho más complicado.

Desafíos organizacionales

Suena tonto, pero para desarrollar un SPA, necesita desarrolladores que sepan qué hacer con él. Al mismo tiempo, no debe subestimar la complejidad del SPA, no debe pensar que cualquier desarrollador web experimentado con la motivación y la comprensión adecuadas puede escribir un gran SPA desde cero. Necesita las habilidades y la experiencia adecuadas, o espera que se cometan errores importantes. Lo sé porque es exactamente mi caso.

Este es quizás un desafío más importante para su empresa de lo que cree. El enfoque SPA alienta a equipos altamente especializados en lugar de equipos de generalistas:

• Los marcos de SPA son piezas complejas de software que requieren innumerables horas de experiencia para ser productivos. Solo las personas de su empresa que pasen estas horas en el código podrán admitir estas aplicaciones.
• Los marcos de SPA requieren API bien pensadas y productivas. El cumplimiento de estos requisitos requiere un conjunto completamente diferente de habilidades que las que requieren trabajar con SPA.

Lo más probable es que se encuentre con personas que no pueden trabajar con SPA, y que no pueden trabajar en el lado del servidor, simplemente porque no saben cómo.

Esta especialización puede ser ideal para Facebook o Google y sus equipos que consisten en varias capas de tropas de ingeniería. ¿Pero será bueno para su equipo de 6 personas?

Rieles modernos

Hay 3 cosas que entran en los Rails modernos que pueden cambiar de opinión sobre el desarrollo de aplicaciones web modernas:

• uno de ellos es Turbolinks y esta es una explosión cerebral
• el otro es un viejo amigo que hoy se pasa por alto: respuestas SJR y solicitudes simples de AJAX para renderizar
• y el último fue agregado recientemente: Estímulo

Es difícil entender qué es aplicar cualquier enfoque sin jugar con él. Por lo tanto, haré algunas referencias a Basecamp en las siguientes secciones. No tengo nada que ver con Basecamp, excepto como un usuario feliz. En cuanto a este artículo, este es solo un buen ejemplo en vivo de Rails modernos que puedes probar gratis.

Turbolinks

La idea detrás de Turbolinks es simple: agilice su aplicación reemplazando por completo la recarga de páginas con solicitudes AJAX que reemplacen el elemento ``. La brujería interna que hace este trabajo está oculta. Como desarrollador, puede centrarse en la programación tradicional del lado del servidor.

Turbolinks está inspirado en pjax y pasó por varias revisiones.

Solía ​​preocuparme por su rendimiento. Estaba equivocado La aceleración es enorme. Lo que me convenció fue cómo lo usé en el proyecto, pero puedes probar la versión de prueba en Basecamp y jugar con ella. Intente crear un proyecto con algunos elementos y luego navegue por ellos haciendo clic en las secciones. Esto le dará una buena idea de cómo se ve Turbolinks.

No creo que Turbolinks sea simplemente sorprendente con su novedad (pjax - 8 años). O su sofisticación técnica. Me sorprende cómo una idea simple puede aumentar su productividad en un orden de magnitud en comparación con la alternativa al SPA.

Permítanme resaltar algunos de los problemas que soluciona:

• Intercambio de datos. No lo tienes No es necesario serializar JSON, crear API o pensar en solicitudes de datos que satisfagan las necesidades del cliente en términos de rendimiento.
• Carga inicial A diferencia del SPA, este enfoque estimula tiempos de carga rápidos (por diseño). Para representar la pantalla, puede obtener los datos que necesita directamente de la base de datos. HTML — .
• : JavaScript-. , SPA.

El MVC en el servidor, en la versión utilizada por Rails y muchos otros marcos, es mucho más simple que cualquiera de las plantillas utilizadas para la arquitectura de GUI enriquecida: obtenga una solicitud, trabaje con la base de datos para satisfacerla y muestre la página HTML como respuesta.

Finalmente, la limitación que siempre se reemplaza tiene un efecto maravilloso: puede concentrarse en la representación inicial de las páginas en lugar de actualizar ciertas secciones (o actualizar algunas condiciones en el mundo SPA). En el caso general, él simplemente hace todo.

• Duplicación de código. Solo hay una vista de su aplicación que vive en el servidor. Su modelo de dominio, sus reglas, pantallas de aplicación, etc. No es necesario duplicar conceptos en el cliente.
• . SPA, JavaScript , . , , , .

Tenga en cuenta que no estoy hablando de problemas de nombres, sino de solucionarlos. Por ejemplo, GraphQL o la rehidratación SPA son soluciones súper inteligentes para problemas muy complejos. Pero, ¿qué pasa si, en lugar de tratar de encontrar una solución, te pones en una situación en la que estos problemas no existen? Este es un cambio en el enfoque del problema. Y me llevó años apreciar completamente la capacidad de este enfoque para resolver problemas.

Por supuesto, Turbolinks no es una bala de plata sin problemas. El mayor problema es que puede romper el código JavaScript existente:

• Turbolinks se envía con su evento personalizado de "carga de página", y los complementos existentes que dependen de cargas de página regulares no funcionarán. Hoy en día hay mejores formas de agregar comportamiento al DOM, pero los widgets heredados no funcionarán si no están adaptados.
• El código JavaScript que modifica el DOM debe ser idempotente porque se puede ejecutar varias veces. Nuevamente, esto invalida una gran cantidad de JavaScript existente.
• La velocidad es excelente, pero no es como en SPA, que puede manejar algunas interacciones sin cargar el servidor. Hablaré más sobre compromisos más adelante.

Representación AJAX y respuestas SJR

¿Recuerdas cuando renderizar HTML a través de Ajax era tendencia hace 15 años? Adivina que? Esta sigue siendo una gran herramienta en tu arsenal:

• HTML DOM, ( 100 ).
• HTML , .

Puede ver cómo se siente este enfoque en Basecamp abriendo el menú de su perfil haciendo clic en el botón superior derecho: se



abre al instante. Desde el lado del desarrollo, no necesita preocuparse por la serialización JSON y el lado del cliente. Simplemente puede mostrar este fragmento en el servidor, utilizando todas las características de Rails.

Una herramienta similar que Rails ha incluido a lo largo de los años son las respuestas de JavaScript del lado del servidor (SJR). Le permiten responder a las solicitudes de Ajax (generalmente presentaciones de formularios) con JavaScript que ejecuta el cliente. Proporciona los mismos beneficios que la representación AJAX de fragmentos de HTML: se ejecuta muy rápido, puede reutilizar el código en el lado del servidor y puede acceder directamente a la base de datos para crear una respuesta.

Puede ver cómo sucede esto si ingresa a Basecamp e intenta crear un nuevo todo. Después de hacer clic en "Agregar todo", el servidor guardará el todo y responderá con un fragmento de JavaScript que agrega un nuevo todo al DOM.

Creo que muchos desarrolladores hoy miran el renderizado AJAX y las respuestas SJR con desprecio. Yo también lo recuerdo. Son una herramienta y, como tal, pueden ser abusados. Pero cuando se usa correctamente, esta es una solución excelente. Le permite ofrecer una excelente experiencia de usuario e interactividad a un precio muy bajo. Desafortunadamente, como Turbolinks, son difíciles de evaluar si aún no has luchado contra el SPA.

Estímulo

Stimulus es un marco de JavaScript publicado hace unos meses. No le importa el renderizado o la gestión de estado basada en JavaScript. En cambio, es solo una forma agradable y moderna de organizar JavaScript, que utiliza para agregar HTML:

• Utiliza MutationObserver para vincular el comportamiento al DOM, lo que significa que no le importa cómo aparece el HTML en la página. Por supuesto, esto funciona muy bien con Turbolinks.
• Le ahorrará una tonelada de código repetitivo para adjuntar el comportamiento al DOM, para adjuntar controladores de eventos a eventos y para colocar elementos en el contenedor especificado.
• Su objetivo es hacer que su código HTML sea legible y comprensible, lo cual es bueno si alguna vez ha encontrado el problema de descubrir qué parte de JavaScript está actuando en este maldito elemento.
• Fomenta la persistencia en el DOM. Nuevamente, esto significa que no le importa cómo se genera el HTML, lo cual es adecuado para muchos escenarios, incluidos los Turbolinks.

Si acepta la ruta Rails, su JavaScript se centrará en modificar el código HTML del lado del servidor y mejorar la interacción (con un poco de JavaScript). Stimulus está diseñado para organizar dicho código. Este no es un sistema SPA y no pretende ser uno.

Usé Stimulus en varios proyectos, y realmente me gusta. Elimina un montón de código repetitivo, está construido sobre los últimos estándares web y se lee muy bien. Y algo que me encanta especialmente: ahora esta es la forma estándar de hacer algo que aún tenía que resolverse en cada aplicación.

Juego de compromiso

Turbolinks generalmente se vende como "Obtenga todos los beneficios de SPA sin ningún inconveniente". No creo que esto sea completamente cierto:

• Las aplicaciones creadas con Rails modernos se ven rápido, pero SPA aún responderá más rápido a las interacciones que son independientes del servidor.
• Hay escenarios en los que SPA tiene más sentido. Si necesita ofrecer un alto nivel de interactividad, debe administrar una gran cantidad de estados, ejecutar una lógica compleja en el lado del cliente, etc. El marco SPA le facilitará la vida.

Ahora el desarrollo es un juego de compromiso. Y en este juego:

• Modern Rails le permite crear aplicaciones que son lo suficientemente rápidas y se ven geniales.
• Para una gran variedad de aplicaciones, Rails le permite implementar las mismas funciones con menos código y menos complejidad.

Creo que con Rails puede obtener el 90% de lo que SPA ofrece con un 10% de esfuerzo. En términos de rendimiento, Rails mata a SPA. En cuanto a UX, creo que muchos desarrolladores cometen el mismo error que yo, suponiendo que SPA UX no tiene igual. Esto no es asi. De hecho, como se discutió anteriormente, es mejor que sepa lo que está haciendo al crear su SPA, o UX en realidad será peor.

Conclusión

Observo a las compañías aceptar masivamente los marcos de SPA y veo innumerables artículos sobre cómo hacer cosas elegantes de estilo SPA. Creo que hay muchos "usos de la herramienta incorrecta para el trabajo", ya que creo firmemente que los tipos de aplicaciones que justifican el uso de SPA son limitados.

Y digo que lo justifican porque los SPA son complejos. En cualquier caso, espero haberte convencido de esto. No digo que sea imposible crear excelentes aplicaciones de SPA, o que las aplicaciones modernas de Rails son excelentes por definición, solo un enfoque es súper complicado y el otro es mucho más simple.

Mientras preparaba este artículo, me encontré con este tweet:



Me hizo reír porque elegiría las primeras opciones si la alternativa no estuviera justificada. También es un representante del tipo de pensamiento de los desarrolladores que aman la complejidad y se nutren de ella, incluso pensando que otras personas con diferentes criterios están locas.

Después de muchos años, me di cuenta de que la complejidad es a menudo una opción. Pero en el mundo de la programación, es sorprendentemente difícil elegir la simplicidad. Valoramos tanto la complejidad que aceptar la simplicidad a menudo nos hace pensar de manera diferente, lo que por definición es difícil.

Recuerde que puede deshacerse de los problemas. Si elige la ruta SPA, asegúrese de que esté justificada y comprenda los problemas. Si no está seguro, experimente con diferentes enfoques y compruébelo usted mismo. Quizás Facebook o Google, en su escala, no pueden darse el lujo de tomar tales decisiones, pero probablemente sí.

Y si usted es un desarrollador de Rails que dejó Rails hace muchos años, le recomiendo que vuelva a él. Creo que estarás encantado.