desenvolvimento client-side 2016

130
23 de Abril, 2016 R. Jardim Botânico 518 2º andar Rio de Janeiro/ 55 21 35540 3540 / hugeinc.com

Upload: huge

Post on 09-Jan-2017

529 views

Category:

Technology


0 download

TRANSCRIPT

23 de Abril, 2016 R. Jardim Botânico 518 2º andar Rio de Janeiro/ 55 21 35540 3540 / hugeinc.com

Desenvolvimento Client-Side 2016

Huge Brazil

23 de Abril, 2016

1. Background

2. Uma sentença 3. Premissas4. Conceitos 5. APIs 6. Frameworks

7. Conclusões

Agenda

Background.

Computadores existem para satisfazer as nossas necessidades e automatizar tarefas. A forma como nós humanos interagirmos com qualquer sistema que automatize tarefas (não só computadores, pense em carros, por exemplo) é através de uma interface.

Antes da internet ser como conhecemos hoje, essa interface era feita através de softwares instalados no sistema operacional. Com a evolução da web e a praticidade da mesma, muitos têm tentado trazer todo o poder do computador para sistemas na web, através de interfaces no navegador.

Client-side === SPA.

Ou UniversalJS.

Se você não precisa de alguma combinação de:

AJAX, Binding, Interatividade e Input/Output.

Você não precisa de SPA.

Não ser SPA também é Front-End,e tem seus desafios como

arquitetura de pastas/arquivos, organização de CSS, templates

inteligentes, etc.

Voltando aoSingle Page Application…

Tecnologia x Ferramenta.

Tecnologia Ferramenta

Javascript Angular

Node.JS Express

PHP Symphony

Python Flask

medium.com/@caiovaccaro

Uma sentença.

Eu quero desenvolver aplicações sem me preocupar demais em aprender algo além da tecnologia, com partes reutilizáveis, de fácil manutenção e que traga uma boa experiência para os usuários.

Premisas.

Não ter que aprender algo demasiadamente específico.

Partes reutilizáveis e modulares.

Sem muita necessidade de refatoração.

Boa experiência para o usuário (rápido, transições, feedback,

fácil de usar).

Premisas.1. Não ter que aprender algo

demasiadamente específico.2. Partes reutilizáveis e modulares.3. Sem muita necessidade de refatoração.4. Boa experiência para o usuário (rápido,

transições, feedback, fácil de usar).

Desafios de 2016*.Premisas.

Sincronia de dados entreservidor e cliente/cache.

Performance.

Fácil de desenvolver e dar manutenção.

Concorrência e Paralelismo.

Offline.

Desafios.1. Sincronia de dados entre servidor e

cliente/cache.2. Performance.3. Fácil de desenvolver/dar manutenção.4. Concorrência e Paralelismo.5. Offline.

Tempo.Premisas.

Tempo.1. Curto prazo.2. Longo prazo.

Não ter que aprender algo demasiadamente específico

Partes reutilizáveis e modulares

Sem muita necessidade de refatoração

Boa experiência para o usuário (rápido, transições, feedback, fácil de usar)

Fácil de desenvolver/dar manutenção

Fácil de desenvolver/dar manutenção

Sincronia de dados entre servidor e cliente

Offline

Fácil de desenvolver/dar manutenção

Concorrência e Paralelismo

Performance

Sincronia de dados entre servidor e cliente/cache

Curto prazo Longo prazo

Boa experiência para o usuário (rápido, transições, feedback, fácil de usar)

Boa experiência para o usuário (rápido, transições, feedback, fácil de usar)

Não ter que aprender algo demasiadamente específico

Sem muita necessidade de refatoração

Partes reutilizáveis e modulares

Eu quero desenvolver aplicações sem me preocupar demais em aprender algo além da tecnologia, com partes reutilizáveis, de fácil manutenção e que traga uma boa experiência para os usuários.

Temos que escolher entre.

1. Conceitos de programação.2. Formatos de API.3. Frameworks de Front-End.

Conceitos.

Você já leu por aí.1. State.2. Stateless.3. Imperativo.4. Funcional.5. Passivo.6. Reativo.

Imperativo.1. Stateful.2. Passivo.

Funcional.1. Stateless.2. Reativo.

State.Conceitos.

Você está feliz agora,esse é seu estado.

Estado é um snapshot da memória

de uma parte do seu programaem determinado momento.

Imperativo.Conceitos.

Esse é o estilo mandão. Eu sei quem você é, eu quero que você faça aquilo pra mim. Eu mudo o

seu estado e eu sei disso.

Passivo.Conceitos.

A mesma coisa, mas do pontode vista do pau mandado.

Ele é passivo de receber ordem

e está exposto aos outros.

Reativo.Conceitos.

O contrário do imperativo e passivo, vai junto com o funcional.

Ele diz explicitamente que vai reagir quando acontecer

tal coisa nos outros.

Ninguém manda nele diretamente, ele manda em si mesmo

e se controla.

Funcional.Conceitos.

Esse é o estilo matemático.

Eu defino funções previsíveis,que apenas alteram o estado do

seu escopo e nunca causam efeitos colaterais (nunca mudam

estados fora de si).

Stateless.Conceitos.

Também vai junto com o funcional.

Advoga que a melhor forma de evitar efeitos colaterais é não

armazenar estado, simplesmente transformar e retornar.

reactivex.io/learnrx

Imperativo.1. Stateful.2. Passivo.

Funcional.1. Stateless.2. Reativo.

Comparações.Conceitos.

APIs.

APIs.1. RPC.2. REST.3. GRAPH.

RPC.APIs.

example.com/list/?rowOffset=0&rowSize=5

Mais de um recursoou entidade por chamada.

RPC.1. Ruim para cache.2. Acoplado.3. Uma chamada por view.

4. Respostas pequenas.

REST.APIs.

example.com/list/1234 example.com/user/3

Cada endpoint === uma entidade.

REST.1. Bom para cache.2. Desacoplado.3. Muitas chamadas por view.

4. Respostas grandes.

GRAPH.APIs.

Cara.. pensa em JSON 360 graus.

Olha depois aí. 1. Netflix Falcor.2. Facebook Relay/GraphQL.

Comparações.APIs.

E o REST?

Frameworks.

Frameworks. 1. MV* (Angular 1.x, Ember...).2. Flux + Components (React, Vue.js…).3. Web Components (Polymer...).4. Functional/Reactive (Cycle, Bacon…).

medium.com/@caiovaccaro

Conclusões.

zhou-yi.herokuapp.com

github.com/caiovaccaro/zhou-yi

Fácil de desenvolver + Curto prazo + Não ter que aprender algo muito específico.

Imperativo + RPC + Flux/Components.

Sincronia de dados + Performance +Longo prazo + Partes reutilizáveis.

Funcional + GRAPH +Flux/Components ou Functional/Reactive.

Ah legal.. tenho quesaber escolher disso tudo então.

Nossa aplicação pode ser independente de frameworks?

Lunar.Conclusões.

Separar framework-code de application-code.

Deixar sua lógica de negócio ser independente de ferramentas.

github.com/hugeinc/lunar

Temos que ter camadas de abstração sim, mas

sempre teremos que saber em que pé anda a

tecnologia e o papel de cada ferramenta.

Você pode ajudar.Conclusões.

Você pode ajudar.1. Soluções para paralelismo.2. Propor formas de trabalhar offline.3. Como transitar entre frameworks.4. Facilitar o modelo de dados no cliente.

Perguntas?

23 de Abril, 2016. R. Jardim Botânico 518 2º andar Rio de Janeiro/ 55 21 35540 3540 / hugeinc.com