[Software development Campinas meetup 2016] Aplicações isomórficas: o que são e como funcionam?

Um review do histórico que levou às aplicações isomórficas, explicação de como funcionam e exemplos em outras linguagens.

Transcript

1. Iso o que?! Aplicações isomórficas: o que são e como funcionam Talysson/@talyssonoc Front-end/Codeminer42
2. Agenda Iso o que?! Histórico; O santo graal; Mas é só com JavaScript + Node?
3. Iso o que?! Ou: mas não era universal?
4. http://www.merriam-webster.com/dictionary/isomorphic isomorphic adjective | iso·mor·phic | \ˌī-sə-ˈṁr-fik\ Definição: 1 - ser de formato, forma ou estrutura similar ou idêntica
5. Histórico
6. Histórico - jQuery API simples de usar e bem documentada; Atualização da view modificando o DOM diretamente; Inviável renderizar no servidor; Estado da aplicação era armazenado de maneira confusa.
7. Histórico - Backbone Mesmos problemas de renderização do jQuery; Adoção de template engines como o _.template e o Mustache; Padronização de gerência de estado e API através dos models; Utilizar template engines implica em duplicar as views com o servidor; Utilizar models implica em duplicar lógicas e validações dos models do servidor;
8. Histórico - SPAs Passa toda ou a maioria da renderização pro cliente; Trabalha com APIs; Muito bons para webapps mobile; Ainda implica em algumas duplicações dos models; Problemas de performance e SEO; Angular 1, Ember, ...
9. Histórico - Mojito Usa YUI no servidor e no cliente; Primeiro framework com idéias isomórficas; Sistema de módulos do YUI não funciona bem com NodeJS; Sincronizar servidor e cliente era uma tarefa difícil.
10. Histórico - Rendr Permite renderizar aplicações Backbone no servidor; Não simula o DOM no servidor, tornando a renderização mais rápida; Exporta um middleware para ser usado com o Express; Estende o Backbone com as próprias classes; Problema de atualização da view permanece; Configuração complexa.
11. Histórico - Popularização do NodeJS Necessidade de criar bibliotecas desacopladas do DOM; A visualização das possibilidades alavancou a ideia de isomorfismo; Surgimento de bibliotecas que comportam-se igualmente no servidor e no cliente, mas tem implementação diferentes entre eles; Ferramentas que permitem ao navegador entender CommonJS; React, Fetchr, Browserify, Webpack, ...
12. O santo graal Ou não
13. Aplicações isomórficas Maioria do código pode ser compartilhado entre servidor e cliente; É uma aplicação normal na primeira requisição e depois se torna um SPA; Separação implícita entre servidor e cliente; Minimização da modificação explícita do DOM; Problema do gerenciamento de estado precisou ser repensado; Difícil gerenciamento de autenticação e permissão de usuários;
14. Compartilhamento de código Exemplo: React // servidor var MyComponent = require('./MyComponent'); var ReactDOM = require('react-dom/server'); ReactDOM.renderToString(<MyComponent/>); // cliente var MyComponent = require('./MyComponent'); var ReactDOM = require('react-dom'); ReactDOM.render(<MyComponent/>, document.body);
15. Eventualmente um SPA A requisição é processada no servidor e o estado é enviado pro cliente; O cliente recupera o estado e começa a processar a partir dele usando o "mesmo" código isomórfico usado no servidor; Caso o cliente atualize a página, o processo reinicia; Se o cliente usa os links para navegar, o código é processado no cliente.
16. Separação implícita entre servidor e cliente O programador deve se preocupar o menos possível com o que está sendo rodado no servidor ou no cliente (estou de olho em você, Meteor); Comportamento das bibliotecas deve ser controlado internamente; Bom exemplo: Fetchr; Acesso ao banco no servidor lê o banco diretamente, no cliente faz requisição AJAX.
17. Minimização da modificação explícita do DOM Remoção da necessidade de simulação do DOM no servidor; Bootstraping e atualização da tela mais leves; Popularização das bibliotecas de DOM virtual: React, virtual-dom, Mithril; Utilização de eventos sintéticos para padronização cross-browser.
18. Gerenciamento e sincronização de estado Utilizar os modelos tradicionais de gerência de estado dificultava a serialização do estado para enviar para o cliente; Surgimento do Meteor, Flux, Relay, entre outros; Popularização de bibliotecas de single state tree: Redux, Baobab, …; Crescimento do uso de estruturas imutáveis.
19. Autenticação e permissão Criptografia no cliente não oferece segurança alguma; Um dos maiores problemas, juntamente com o gerenciamento de estado; Utilização de HTTPS em toda requisição para aumentar a segurança; Utilização de approaches com cookies/sessões, OAuth 2.0 e JSON Web Token (JWT); Uma das áreas que ainda precisa ser estudada e evoluída.
20. Exemplo: React + Flux 1ª requisição Servidor Executa action de navegação, renderiza e envia conteúdo das stores Cliente acessa URL Cliente preenche suas stores Executa action de navegação e requisita dados Envia somente os dados requisitados Clicks em links
21. Mas é só com JavaScript + Node?
22. Isomorfismo com outras linguagens Dois approaches: executar JavaScript no servidor ou linguagens que compilam para JavaScript; Executar JavaScript no server: servidor de renderização separado; react-rails; react-laravel. Utilização de linguagens que compilam para JavaScript:
23. Gostou da ideia? Experimente!
24. Obrigado! Talysson/@talyssonoc Front-end/Codeminer42
25. Links • Isomorphic JavaScript - The Future of Web Apps: <http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/> • Isomorphic Flux: <https://speakerdeck.com/mridgway/isomorphic-flux> • Scaling Isomorphic JavaScript Code: <http://blog.nodejitsu.com/scaling- isomorphic-javascript-code/> • Web Authentication Methods Explained: <https://blog.risingstack.com/web- authentication-methods-explained/> • ClojureScript Omelette: <https://github.com/DomKM/omelette> • Volt: <https://github.com/voltrb/volt> • Duktape: <https://github.com/olebedev/go-duktape>