Saindo do SPA da toca do coelho com trilhos modernos

TL; DR: A trilha do SPA é escura e cheia de horrores. Você pode enfrentá-los sem medo ... ou escolher outro caminho que o levará ao lugar certo: Rails modernos.



Lembro-me de pensar que o Rails estava focado no objetivo errado quando o DHH anunciou a Turbolinks em 2012. Fiquei convencido de que o tempo de resposta instantânea durante a interação do usuário era a chave para o UX superior. Devido a atrasos na rede, essa interatividade só é possível se você minimizar a dependência da rede e, em vez de chamadas de rede, manter a maior parte do estado no cliente.

Eu pensei que era necessário para os aplicativos que eu estava trabalhando. E com essa opinião, tentei muitas abordagens e estruturas para implementar o mesmo modelo: Aplicativos de página única (SPA). Eu acreditava que o SPA é o futuro. Alguns anos depois, não tenho certeza do que é o futuro, mas definitivamente quero encontrar uma alternativa.

SPA para coelhos

Um aplicativo de uma página é um aplicativo JavaScript que, uma vez baixado, obtém controle total sem precisar recarregar a página: renderização, recebimento de dados do servidor, processamento da interação do usuário, atualização da tela ...

Esses aplicativos parecem mais nativos do que as páginas da Web tradicionais, onde o aplicativo depende do servidor. Por exemplo, se você usa o Trello, pode observar a rapidez com que os cartões são criados.

Obviamente, grande responsabilidade vem com grande força. Nos aplicativos da Web tradicionais, o aplicativo do servidor inclui um modelo de domínio e regras de negócios, tecnologia de acesso a dados para trabalhar com um banco de dados e uma camada de controlador para controlar como as páginas HTML são montadas em resposta a solicitações HTTP.

C SPA é um pouco mais complicado. Você ainda precisa de um aplicativo de servidor que inclua seu modelo e regras de domínio, um servidor Web, um banco de dados e algum tipo de tecnologia de acesso a dados ... e várias outras coisas adicionais:

Para servidor:

• Uma API que atende às necessidades de dados do seu cliente
• Um sistema de serialização JSON para troca de dados com o cliente e um sistema de cache que suporta esse

Para o novo cliente JavaScript:

• Sistema de modelo para converter dados em HTML
• Apresentação do seu modelo e regras de domínio
• A camada de acesso a dados no aplicativo cliente para transferir dados para o servidor
• Sistema para atualizar visualizações quando os dados são alterados
• Um sistema para vincular URLs e telas (espero que você não use um endereço para tudo, ele não se parece com um aplicativo da web)
• Um sistema para colar todos os componentes necessários para exibir telas e obter dados para este
• Novos modelos e arquitetura para organizar tudo quando
• Sistema para tratamento de erros, registro em log, rastreamento de exceções, etc.
• Sistema para gerar JSON para solicitações do servidor
• Estrutura de teste automatizada que suporta o seu SPA
• Um conjunto adicional de testes para escrever e dar suporte
• Um conjunto adicional de ferramentas para montar, empacotar e implantar um novo aplicativo

Em suma, com o SPA, você terá outro pedido de suporte. E um novo conjunto de problemas para resolver. E observe que você não pode substituir um aplicativo por outro. Você ainda precisa do aplicativo do servidor (agora ele renderizará JSON em vez de HTML).

Se você nunca trabalhou com o SPA, pode subestimar as dificuldades que encontrará. Eu sei disso porque cometi os mesmos erros no passado. Renderizar JSON? Eu posso lidar com isso. Um modelo de objeto de domínio avançado em JavaScript? Isso parece engraçado. E, você sabe, essa estrutura resolverá todos esses problemas. Ótimo bolo!

Errado.

API e troca de dados.

A comunicação entre seu novo aplicativo e o servidor é um problema complexo.

Existem duas forças opostas:

• Você deseja fazer o menor número possível de solicitações de servidor, a fim de melhorar o desempenho.
• A conversão de um único registro para JSON é simples. Mas misturar modelos grandes de vários registros para minimizar o número de consultas não é de todo. Você precisará desenvolver cuidadosamente a lógica de serialização para otimizar o número de consultas ao banco de dados e manter o desempenho no nível.

Além disso, você precisa pensar no que fazer o download e quando fazê-lo em cada uma das telas. Quero dizer, você precisa de um equilíbrio entre o bootstrap, o que precisa imediatamente e o que pode ser carregado preguiçosamente, e desenvolver uma API que permita fazer isso.

Alguns padrões podem ajudar aqui. API JSON para padronizar o formato JSON; ou GraphQL, para selecionar apenas os dados necessários, tão complexos quanto necessários, em uma consulta. Mas nenhum deles salvará você de:

• A elaboração de cada troca de dados
• Implementando consultas para selecionar dados com eficiência no servidor

E esses dois aspectos representam uma quantidade suficiente de trabalho adicional.

Tempo de inicialização

As pessoas estão acostumadas a associar SPAs com velocidade, mas a verdade é que fazê-los carregar rapidamente não é tão fácil. Existem muitas razões para isso:

• Um aplicativo precisa de dados antes de renderizar algo e leva tempo para analisar uma quantidade suficientemente grande de JavaScript.
• Além da solicitação HTTP inicial para baixar o aplicativo, você geralmente precisa fazer uma ou mais solicitações para obter os dados JSON necessários para renderizar a tela.
• O cliente deve converter JSON em HTML para mostrar pelo menos alguma coisa. Dependendo do dispositivo e da quantidade de JSON a ser convertida, isso pode causar atrasos visíveis.

Isso não significa que é impossível forçar o SPA a carregar rapidamente. Eu apenas digo que é difícil e você deve cuidar disso, porque não vem com a arquitetura do SPA.

Por exemplo, o Discourse, um SPA baseado em Ember, tem tempos de carregamento fantásticos, mas, entre outras coisas, pré-carrega uma grande quantidade de dados JSON como parte do HTML inicial, para não fazer solicitações adicionais. E noto que a equipe do Discurso é louca no bom senso de velocidade e suas habilidades estão bem acima da média. Pense nisso antes de poder reproduzir facilmente o mesmo no seu SPA.

Uma solução ambiciosa para esse problema é o JavaScript isomórfico: renderize sua página inicial no servidor e entregue-a rapidamente ao cliente, enquanto, no segundo plano do SPA, ele carrega e obtém controle total quando estiver pronto.

Essa abordagem requer a execução do tempo de execução JavaScript no servidor e também não ocorre sem problemas técnicos. Por exemplo, os desenvolvedores devem considerar os eventos de carregamento do SPA à medida que o processo de carregamento muda.

Gosto da oportunidade de reutilizar o código nessa ideia, mas não vi uma implementação que me permitisse seguir na direção oposta. Além disso, esse processo de renderização de página me parece muito engraçado:

- Servidor: solicitação à API do servidor
- Servidor: consulta ao banco de dados
- Servidor: gera JSON
- Servidor: converte JSON em HTML
- Cliente: exibe HTML inicial
- Cliente: download SPA
- Cliente: analisa o HTML inicial e assina eventos DOM

Você poderia apenas solicitar os dados do banco de dados, gerar o HTML e começar a trabalhar?

Isso não é totalmente justo, porque você não será o SPA e porque a maior parte dessa mágica está oculta por trás da estrutura, mas ainda me parece errado.

Arquitetura

O desenvolvimento de aplicativos com uma interface de usuário avançada é difícil. Tudo isso porque esse é um dos problemas que inspiraram o surgimento de uma abordagem orientada a objetos e de muitos padrões de design.

Gerenciar o status do cliente é difícil. Os sites tradicionais geralmente se concentram em telas de responsabilidade única que perdem o estado quando são reiniciadas. No SPA, o aplicativo é responsável por garantir que todas as atualizações de estado e tela durante o uso sejam consistentes e passem sem problemas.

Na prática, se você começou a escrever JavaScript em pequenas porções para melhorar a interação, no SPA terá que escrever toneladas de código JavaScript adicional. Aqui você deve ter certeza de que está fazendo tudo certo.

Existem tantas arquiteturas diferentes quanto as estruturas do SPA:

• A maioria das estruturas difere do modelo tradicional do MVC. O Ember foi inspirado inicialmente pelo Cocoa MVC, mas mudou bastante seu modelo de programação nas versões recentes.
• Há uma tendência de que os desenvolvedores prefiram os componentes do que a separação tradicional do controlador e da apresentação (algumas estruturas, como Ember e Angular, passaram para essa abordagem nas versões recentes). Todas as estruturas implementam algum tipo de ligação de dados unidirecional. A ligação frente e verso é desencorajada devido aos efeitos colaterais que podem contribuir.
• A maioria das estruturas inclui um sistema de roteamento que permite mapear URLs e telas e determina como instanciar componentes para renderização. Essa é uma abordagem da Web exclusiva que não existe nas interfaces tradicionais da área de trabalho.
• A maioria das estruturas separa os modelos HTML do código JavaScript, mas o React mistura a geração HTML e o JavaScript e faz isso com bastante sucesso, devido ao seu uso generalizado. Também há um hype em torno da incorporação de CSS em JavaScript. O Facebook, com sua arquitetura Flux, influenciou bastante o setor, e contêineres como Redux, vuex etc. são fortemente influenciados por ele.

De todas as estruturas que eu já vi, Ember é o meu favorito. Adoro a consistência dele e o fato de ele ser bastante teimoso. Também gosto do seu modelo de programação em versões recentes, combinando MVC, componentes e roteamento tradicionais.

Por outro lado, sou fortemente contra o campo Flux / Redux. Vi tantas pessoas inteligentes usando-as que fiz todos os esforços para estudá-lo e compreendê-lo, e nem uma vez. Não posso deixar de balançar a cabeça em frustração quando vejo o código. Não me vejo feliz ao escrever esse código.

Finalmente, não consigo suportar a mistura de HTML e CSS em componentes cheios de lógica JavaScript. Entendo o problema que isso resolve, mas os problemas que essa abordagem traz não fazem valer a pena.

Vamos deixar as preferências pessoais, a conclusão é que, se você escolher o caminho do SPA, terá um problema muito difícil: criar a arquitetura do seu novo aplicativo corretamente. E o setor está longe de concordar em como fazer isso. Todos os anos, novas estruturas, modelos e versões de estruturas são exibidas, o que altera levemente o modelo de programação. Você precisará escrever e manter uma tonelada de código com base na sua escolha de arquitetura; portanto, pense corretamente.

Duplicação de código

Ao trabalhar com o SPA, você provavelmente encontrará duplicação de código.

Para sua lógica de SPA, você desejará criar um modelo rico de objetos que representam sua área de domínio e lógica de negócios. E você ainda precisa da mesma coisa para a lógica do servidor. E é uma questão de tempo até você começar a copiar o código.

Por exemplo, suponha que você esteja trabalhando com faturas. Você provavelmente tem uma classe de fatura em JavaScript que contém um método total que resume o preço de todos os elementos para poder renderizar o valor. No servidor, você também precisará da classe Invoice com o método total para calcular esse custo para enviá-lo por email. Você vê? As classes de cliente e servidor de fatura implementam a mesma lógica. Duplicação de código.

Como dito acima, o JavaScript isomórfico pode atenuar esse problema, facilitando a reutilização de código. E digo a nível, porque a correspondência entre o cliente e o servidor nem sempre é 1 para 1. Você quer ter certeza de que algum código nunca sai do servidor. Uma grande quantidade de código faz sentido apenas para o cliente. Além disso, alguns aspectos são simplesmente diferentes (por exemplo, o elemento do servidor pode salvar dados no banco de dados e o cliente pode usar a API remota). Reutilizar código, mesmo se possível, é um problema complexo.

Você pode apostar que não precisa de um modelo rico em seu SPA e, em vez disso, trabalhará diretamente com objetos JSON / JavaScript, distribuindo a lógica entre os componentes da interface do usuário. Agora você tem a mesma duplicação de código misturada com o código da interface do usuário, boa sorte com isso.

E o mesmo acontece se você deseja modelos para renderizar HTML entre o servidor e o cliente. Por exemplo, para SEO, que tal gerar páginas no servidor para mecanismos de pesquisa? Você precisará reescrever seus modelos no servidor e garantir que eles estejam sincronizados com o cliente. Novamente duplicação de código.

A necessidade de reproduzir a lógica dos padrões no servidor e no cliente, na minha experiência, é a fonte do infortúnio crescente dos programadores. Fazer isso uma vez é normal. Quando você fizer isso pela 20ª vez, você apertará sua cabeça. Tendo feito isso pela 50ª vez, você pensará se todas essas peças do SPA são necessárias.

Fragilidade

Na minha experiência, desenvolver bons SPAs é uma tarefa muito mais complicada do que escrever aplicativos da Web com geração de servidores.

Primeiro, não importa quão cuidadoso você seja, não importa quantos testes você escreva. Quanto mais código você escrever, mais erros você terá. E o SPA representa (desculpe, se eu forçar) uma enorme pilha de código para escrever e dar suporte.

Em segundo lugar, como mencionado acima, o desenvolvimento de uma GUI rica é complicado e se traduz em sistemas complexos que consistem em muitos elementos interagindo entre si. Quanto mais complexo o sistema você criar, mais erros você terá. E comparado aos aplicativos da web tradicionais usando MVC, a complexidade do SPA é simplesmente insana.

Por exemplo, para manter a consistência no servidor, você pode usar restrições no banco de dados, validação de modelo e transações. Se algo der errado, você está respondendo com uma mensagem de erro. No cliente, tudo é um pouco mais complicado. Muita coisa pode dar errado, porque muita coisa está acontecendo. Pode ser que algum registro seja salvo com sucesso e outro não. Talvez você tenha ficado offline no meio de algum tipo de operação. Você deve verificar se a interface do usuário permanece consistente e se o aplicativo está se recuperando de um erro. Tudo isso é possível, é claro, apenas muito mais complicado.

Desafios organizacionais

Parece bobagem, mas para desenvolver um SPA, você precisa de desenvolvedores que saibam o que fazer com ele. Ao mesmo tempo, você não deve subestimar a complexidade do SPA, não deve pensar que qualquer desenvolvedor web experiente, com a motivação e o entendimento certos, possa criar um ótimo SPA do zero. Você precisa das habilidades e experiência corretas ou espera que erros importantes sejam cometidos. Eu sei disso porque é exatamente o meu caso.

Esse talvez seja um desafio mais importante para sua empresa do que você pensa. A abordagem do SPA incentiva equipes altamente especializadas, em vez de equipes de generalistas:

• As estruturas do SPA são peças complexas de software que exigem inúmeras horas de experiência para serem produtivas. Somente as pessoas em sua empresa que passam essas horas no código poderão oferecer suporte a esses aplicativos.
• As estruturas de SPA requerem APIs bem pensadas e produtivas. O atendimento a esses requisitos requer um conjunto de habilidades completamente diferente daquelas que exigem trabalho com o SPA.

As chances são de que você se encontre com pessoas que não podem trabalhar com o SPA e que não podem trabalhar no lado do servidor, simplesmente porque não sabem como.

Essa especialização pode ser ideal para o Facebook ou o Google e suas equipes, consistindo em várias camadas de tropas de engenharia. Mas será bom para sua equipe de 6 pessoas?

Modern Rails

Existem três coisas que entram no Rails moderno que podem mudar de idéia sobre o desenvolvimento de aplicativos Web modernos:

• um deles é Turbolinks e esta é uma explosão cerebral
• o outro é um velho amigo que hoje é esquecido: respostas de SJR e pedidos simples de renderização de AJAX
• e o último foi adicionado recentemente: Estímulo

É difícil entender o que é aplicar qualquer abordagem sem brincar com ela. Portanto, farei algumas referências ao Basecamp nas próximas seções. Não tenho nada a ver com o Basecamp, exceto como um usuário feliz. Quanto a este artigo, este é apenas um bom exemplo ao vivo do Rails moderno que você pode experimentar gratuitamente.

Turbolinks

A ideia por trás do Turbolinks é simples: acelere seu aplicativo substituindo completamente as recargas de página por solicitações AJAX que substituem o elemento ``. A bruxaria interna que faz esse trabalho está oculta. Como desenvolvedor, você pode se concentrar na programação tradicional do lado do servidor.

O Turbolinks é inspirado no pjax e passou por várias revisões.

Eu costumava me preocupar com seu desempenho. Eu estava errado. A aceleração é enorme. O que me convenceu foi como o usei no projeto, mas você pode apenas experimentar a versão de teste no Basecamp e brincar com ela. Tente criar um projeto com alguns elementos e navegue por eles clicando nas seções. Isso lhe dará uma boa idéia da aparência do Turbolinks.

Não acho que Turbolinks seja simplesmente incrível com sua novidade (pjax - 8 anos). Ou sua sofisticação técnica. Surpreende-me como uma idéia simples pode aumentar sua produtividade em uma ordem de magnitude em comparação com a alternativa ao SPA.

Deixe-me destacar alguns dos problemas que ele corrige:

• Troca de dados. Você não tem. Não há necessidade de serializar JSON, criar APIs ou pensar em solicitações de dados que atendam às necessidades do cliente em termos de desempenho.
• Carga inicial. Ao contrário do SPA, essa abordagem estimula tempos de carregamento rápidos (por design). Para renderizar a tela, você pode obter os dados necessários diretamente do banco de dados. HTML — .
• : JavaScript-. , SPA.

O MVC no servidor, na versão usada pelo Rails e muitas outras estruturas, é muito mais simples do que qualquer um dos modelos usados ​​para a rica arquitetura da GUI: obtenha uma solicitação, trabalhe com o banco de dados para satisfazê-la e exiba a página HTML como resposta.

Por fim, a limitação que sempre é substituída tem um efeito maravilhoso: você pode se concentrar na renderização inicial das páginas, em vez de atualizar determinadas seções (ou atualizar algumas condições no mundo do SPA). No caso geral, ele apenas faz tudo.

• Duplicação de código. Existe apenas uma visualização do seu aplicativo que reside no servidor. Seu modelo de domínio, suas regras, telas de aplicativos etc. Não há necessidade de duplicar conceitos no cliente.
• . SPA, JavaScript , . , , , .

Observe que não estou falando de problemas de nomeação, mas de corrigi-los. Por exemplo, a reidratação GraphQL ou SPA são soluções super inteligentes para problemas muito complexos. Mas e se, em vez de tentar encontrar uma solução, você se colocar em uma situação em que esses problemas não existem? Esta é uma mudança na abordagem do problema. E levei anos para apreciar completamente a capacidade dessa abordagem para resolver problemas.

Claro, Turbolinks não é uma bala de prata sem complicações. O maior problema é que ele pode quebrar o código JavaScript existente:

• O Turbolinks é enviado com seu evento personalizado de "carregamento da página", e os plug-ins existentes que dependem do carregamento regular da página não funcionam. Hoje existem maneiras melhores de adicionar comportamento ao DOM, mas os widgets herdados não funcionarão se não forem adaptados.
• O código JavaScript que modifica o DOM deve ser idempotente, pois pode ser executado várias vezes. Novamente, isso invalida muito JavaScript existente.
• A velocidade é excelente, mas não é exatamente como no SPA, que pode lidar com algumas interações sem carregar o servidor. Falarei mais sobre compromissos mais tarde.

Respostas de renderização AJAX e SJR

Lembra quando a renderização de HTML pelo Ajax era uma tendência há 15 anos? Adivinha o que? Essa ainda é uma ótima ferramenta no seu arsenal:

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

Você pode ver como essa abordagem é sentida no Basecamp, abrindo o menu do seu perfil clicando no botão superior direito:



Abre instantaneamente. Do lado do desenvolvimento, você não precisa se preocupar com a serialização JSON e o lado do cliente. Você pode simplesmente exibir este fragmento no servidor, usando todos os recursos do Rails.

Uma ferramenta semelhante que o Rails incluiu ao longo dos anos são as respostas JavaScript do lado do servidor (SJR). Eles permitem que você responda às solicitações do Ajax (geralmente envios de formulários) com JavaScript que é executado pelo cliente. Ele oferece os mesmos benefícios que a renderização AJAX de trechos de HTML: é executado muito rápido, você pode reutilizar o código no lado do servidor e acessar diretamente o banco de dados para criar uma resposta.

Você pode ver como isso acontece se você entrar no Basecamp e tentar criar um novo todo. Depois de clicar em "Adicionar todo", o servidor salvará o todo e responderá com um fragmento JavaScript que adiciona um novo todo ao DOM.

Eu acho que muitos desenvolvedores hoje olham para a renderização AJAX e as respostas SJR com desprezo. Eu também lembro disso. Eles são uma ferramenta e, como tal, podem ser abusados. Mas quando usada corretamente, esta é uma solução fantástica. Permite oferecer excelente experiência de usuário e interatividade por um preço muito baixo. Infelizmente, como o Turbolinks, eles são difíceis de avaliar se você ainda não lutou com o SPA.

Estímulo

O estímulo é uma estrutura JavaScript publicada há alguns meses. Ele não se importa com renderização ou gerenciamento de estado baseado em JavaScript. Em vez disso, é apenas uma maneira moderna e agradável de organizar o JavaScript, que você usa para adicionar HTML:

• Ele usa MutationObserver para vincular o comportamento ao DOM, o que significa que não se importa com a aparência do HTML na página. Obviamente, isso funciona muito bem com o Turbolinks.
• Isso economizará uma tonelada de código padrão para anexar o comportamento ao DOM, anexar manipuladores de eventos a eventos e colocar elementos no contêiner especificado.
• Seu objetivo é tornar seu código HTML legível e compreensível, o que é bom se você já encontrou o problema de descobrir qual parte do JavaScript está agindo nesse maldito elemento.
• Incentiva a persistência no DOM. Novamente, isso significa que ele não se importa com a forma como o HTML é gerado, o que é adequado para muitos cenários, incluindo Turbolinks.

Se você aceitar o caminho do Rails, seu JavaScript se concentrará em modificar o código HTML do servidor e melhorar a interação (com um pouco de JavaScript). O estímulo foi projetado para organizar esse código. Este não é um sistema de SPA e não pretende ser um.

Eu usei o Stimulus em vários projetos e realmente gosto disso. Ele elimina um monte de código padrão, é construído com os mais recentes padrões da web e lê muito bem. E algo que eu particularmente amo: agora essa é a maneira padrão de fazer algo que ainda precisava ser resolvido em todas as aplicações.

Jogo de compromisso

Turbolinks é geralmente vendido como "Obtenha todos os benefícios do SPA sem qualquer inconveniente". Eu não acho que isso seja completamente verdade:

• Os aplicativos criados com o Rails moderno parecem rápidos, mas o SPA ainda responderá mais rapidamente às interações independentes do servidor.
• Existem cenários em que o SPA faz mais sentido. Se você precisar oferecer um alto nível de interatividade, precisará gerenciar um grande número de estados, executar lógica complexa no lado do cliente etc. A estrutura do SPA facilitará sua vida.

Agora o desenvolvimento é um jogo de compromisso. E neste jogo:

• O Modern Rails permite criar aplicativos que são rápidos o suficiente e com ótima aparência.
• Para uma enorme variedade de aplicações, o Rails permite implementar as mesmas funções com menos código e menos complexidade.

Acredito que com o Rails você pode obter 90% do que o SPA oferece com 10% de esforço. Em termos de desempenho, o Rails mata o SPA. Quanto ao UX, acho que muitos desenvolvedores cometem o mesmo erro que eu, assumindo que o SPA UX seja insuperável. Isto não é verdade. De fato, como discutido acima, é melhor você saber o que está fazendo ao criar seu SPA ou o UX será realmente pior.

Conclusão

Observo as empresas massivamente aceitarem estruturas de SPA e vejo inúmeros artigos sobre como fazer coisas sofisticadas no estilo de SPA. Eu acho que existem muitos "usos da ferramenta errada para o trabalho", pois acredito firmemente que os tipos de aplicativos que justificam o uso do SPA são limitados.

E eu digo que eles justificam porque os SPAs são complexos. De qualquer forma, espero ter convencido você disso. Não estou dizendo que é impossível criar excelentes aplicativos de SPA ou que os aplicativos modernos do Rails são ótimos por definição, apenas uma abordagem é super complicada e a outra é muito mais simples.

Enquanto preparava este artigo, me deparei com este tweet:



Isso me fez rir, porque eu escolheria as primeiras opções se a alternativa não fosse justificada. Ele também é um representante do tipo de pensamento dos desenvolvedores que amam a complexidade e prosperam, mesmo pensando que outras pessoas com critérios diferentes são loucas.

Depois de muitos anos, percebi que a complexidade costuma ser uma escolha. Mas no mundo da programação, é surpreendentemente difícil escolher a simplicidade. Valorizamos tanto a complexidade que aceitar a simplicidade geralmente nos faz pensar de maneira diferente, o que é difícil por definição.

Lembre-se de que você pode se livrar dos problemas. Se você escolher o caminho do SPA, verifique se ele é justificado e entenda os problemas. Se você não tiver certeza, experimente abordagens diferentes e veja por si mesmo. Talvez o Facebook ou o Google, em sua escala, não tenham o luxo de tomar essas decisões, mas você provavelmente pode.

E se você é um desenvolvedor do Rails que deixou o Rails há muitos anos, recomendo que você retorne a ele. Eu acho que você ficará encantado.