Phoenix LiveView: quando você não precisa mais JavaScript *

* para criar uma página dinâmica

Há pouco tempo, em 12/12/2018, foi anunciado o lançamento de uma nova biblioteca para os fãs do framework phoenix chamada Phoenix LiveView . Gostaria de compartilhar com você minhas impressões sobre o uso e a fênix em geral, e no próximo artigo tente escrever um simples jogo de navegador. A parte do artigo com uma opinião pessoal não é exclusivamente verdadeira. Tentarei explicar as vantagens do desenvolvimento web usando o exemplo de Phoenix versus PHP.

Parte teórica

Phoenix é uma estrutura no elixir da linguagem funcional. Por favor, não confunda com Phalcon para php.

O Phoenix LiveView é uma excelente nova biblioteca que permite criar páginas da web dinâmicas sem escrever código javascript por meio de comunicação bidirecional em soquetes da web e renderização no servidor. Como sabemos, os soquetes da web phoenix estão bem implementados , portanto, haverá desempenho suficiente para a maioria das idéias que você planeja implementar.

Existem várias opções para usar o LiveView:

• Verificar a entrada de dados em formulários (validação), pressionar botões, ocultar e mostrar blocos, preenchimento automático.
• Eventos do servidor, como notificações, painéis, contadores.

Atualmente limitado e disponível no futuro:

• Navegação e paginação de páginas. Eles podem ser criados usando o LiveView, mas no momento você perderá a funcionalidade da transição "voltar / avançar". O suporte ao `pushState` está incluído no plano.
• Exiba dados em constante crescimento - bate-papos, registros on-line etc. pode ser criado usando o LiveView, mas atualmente você deve armazenar todos os dados no estado do aplicativo no servidor. O suporte para atualização parcial dos dados de status está em desenvolvimento.
• Trabalhe com atrasos quando um estado mudar. O LiveView armazena o estado do aplicativo no lado do servidor e isso garante a operação correta da interface com sérios atrasos.
• Um conjunto completo de funções para modelar essas situações aparecerá em versões futuras.

O que há de ruim no LiveView:

• Animações Por exemplo, a exibição do menu por clique pode ser implementada via LiveView, mas é melhor fornecer uma aparência suave em css ou js.
• UI otimista. O aplicativo foi projetado para funcionar continuamente com o estado do servidor e esse estado não está no cliente. Todo o código html de qualquer evento é preparado no servidor com um novo estado e passa pelos soquetes da web para o cliente, todas as alterações visíveis ocorrem substituindo o código html.

Como funciona a visualização ao vivo?

Imagem tirada da elixirschool

O LiveView começa com uma solicitação HTTP normal e uma resposta HTML e depois monitora o status do aplicativo no servidor por soquetes da Web, garantindo a exibição de uma página HTML comum, mesmo se o JavaScript estiver desativado. Cada vez que o estado do aplicativo é alterado, ele redesenha automaticamente a exibição e as atualizações são enviadas ao cliente. No cliente, usando a biblioteca de morphdom , o conteúdo é atualizado. De fato, a lógica está bem próxima das estruturas js modernas, apenas sem o uso do DOM virtual.
Para evitar que a sessão de comunicação seja perdida ao reconectar, uma sessão do usuário com os dados necessários é iniciada no controlador e transmitida ao cliente. Somente uma sessão assinada com dados primários é armazenada no cliente, é enviada ao servidor ao conectar ou reconectar em caso de falha ao estado do aplicativo.

Impressão e opinião pessoal sobre a própria Phoenix

Por experiência pessoal, direi que raramente encontrei aplicativos claramente escritos em equipes de 3 ou mais pessoas. Freqüentemente há uma grande variedade de serviços no php (server) nodejs (websocker) react / vue (front), e também existem coisas que funcionam "lentamente" no php. Colocaremos as filas em redis, conectaremos o rabbitmq, e um dos desenvolvedores não saberá usá-los e o implementará no sql. Alguém sabe como usar corretamente a coroa via rebanho e não cria a lógica de proteção de relançamento no código, e outros executam daemons em php, o que às vezes coloca estacas nas rodas ao atualizar o código e a estrutura do banco de dados. O estado do aplicativo começa a ser armazenado em todos os lugares, em estática da classe, em singleton, às vezes até em uma variável de método estático, as regras para escrever código começam a se multiplicar para combater a ignorância da linguagem e a correta construção da arquitetura, mas e se o projeto fosse iniciado por um programador de nível médio ou júnior no joelho, sem pensar que tudo vai se transformar em um negócio real? Manter isso sozinho não é tão fácil, parte da lógica é duplicada no cliente e no servidor (validação, por exemplo). No SPA, quando a frente começa a usar a API pública, começamos a pensar em versionamento. O suporte está ficando mais difícil porque você precisa satisfazer não apenas as necessidades de serviços e clientes externos, mas também a sua frente que muda constantemente, e não deseja duplicar o código. Graphql parafusado. Com o tempo, o zoológico de bibliotecas cresce e as empresas começam a contratar mais desenvolvedores.

Aqui eu vejo a superioridade de Phoenix. Fora da caixa, temos o php de substituição (elixir + Phoenix), nodejs (websockets no Phoenix.Socket), react / vue (Phoenix.LiveView), redis (ets), rabbitmq (ets), rabbitmq (ets), cron (possivelmente via GenServer), daemons (GenServer) ), banco de dados truncado (mnésia). Temos cache na própria linguagem através de mnésia ou ets, coroas ou demônios sem nenhum problema. multitarefa e trabalhar em segundo plano por anos no "elixir no sangue". O armazenamento de estado é mais frequentemente no servidor de genes. API pública exclusivamente para as necessidades de serviços externos, o spa em breve será gravado no LiveView. O suporte à API será muito mais fácil. Escalabilidade em qualquer direção por meio da linguagem, a velocidade do trabalho é limitada apenas pela fonte de armazenamento de dados, tudo o mais funciona muito rapidamente. Um esquema de trabalho bastante claro se você aprender uma vez como o plugue funciona e qual é a conexão. Geração de código, "arquitetura de microsserviço" - observe o aplicativo abrangente. Eles estão tentando resolver tudo isso com estivadores com orquestração etc. criando empregos para um grande número de engenheiros de devops.

Sumário

Tente instalar o elixir e executar o phoenix. Neste artigo, tentei declarar a “água”, a opinião pessoal e a parte teórica, de modo que no próximo me limitarei apenas ao código e à lógica. Escreveremos um jogo simples no formato DogView do DogView, mas sem a funcionalidade do clicker. Este é o meu primeiro artigo, peço que você não julgue estritamente e não leve muito a sério, mostrei intencionalmente unilateralmente as vantagens da Phoenix e perdi suas deficiências. É melhor senti-los na prática do que assim na opinião de um estranho.

Participe da comunidade de desenvolvedores de proelixir no elixir ou encontre @proelixir no telegrama. Notícias sobre novos idiomas são coletadas pelo bot no canal @proelixir_news.