Duvida na separação de front-end e back-end

[Vinicius Piassa]

Boa tarde a todos,

Estou com uma duvida sobre o desenvolvimento de aplicações web segue abaixo minha duvida. 

Hoje existe muitos Frameworks que nos auxilia no desenvolvimento de aplicações web onde posso citar alguns como Django, Flask e Web2py, porem eu tenho visto uma mudança no rumo do desenvolvimento web com o advento do protocolo HTTP 2.0, mas para exemplificar e ir direto ao ponto darei exemplos de como eu vejo o desenvolvimento hoje e como eu imagino o futuro.

- Hoje: Desenvolvimento em Django e ele faz todo o processamento do site (renderização da pagina, conexão com o banco de dados entre outros) e já entrega para o usuário final o site pronto.

- Futuro: Desenvolvimento do site dividido em duas parte Front-end totalmente em HTML, CSS, JAVASCRIPT sendo que não dependa de nenhum Framework no máximo de bibliotecas e a segunda parte back-end poderia ser em Django, porem ele somente serviria os dados através de web service. (Este cenário é visto hoje em desenvolvimento mobile)

As minhas perguntas são! 

Estou certo nesta maneira de ver as coisas? 

Esse tipo de desenvolvimento já existe hoje na Web? E se existe tem algum nome de definição?

Obrigado.

Pode ser visto um exemplo do que eu digo em Front-end no site https://develsis.com.br  o formulário não faz nada porem apos carregar o site desconectem da internet e tente acessar novamente o site.

Vinicius Piassa

[Diego Nascimento]

Olá Vinicius,

Eu particularmente faço assim, faço a página toda com html, e
javascript e uso o javascript para comunicar via post e get com um
webservice, eu não sei se isso leva um nome, se é um padrão, mas sei
que funciona bem, é a forma que acho mais fácil de vc dinamizar
páginas estáticas, tipo criadas com geradores de páginas estáticas..
exemplo, vc cria um site com uma galeria de fotos e vc quer permitir
que eles votem na foto.. vc gera página estática e deixa só essa parte
comunicando com um webservice , aonde pega as informações dos votos e
joga na tela.. e quando a pessoa vota, ele manda uma mensagem via ajax
para o webservice para atualizar o valor na base de dados.

Tbm fico curioso com esse tipo de desenvolvimento, aproveito sua
dúvida para tbm deixar a minha, minha principal dúvida é sobre a
segurança de se fazer assim, se algum desenvolvedor mais experiente
puder falar sobre seria legal.

> --
> --
> ------------------------------------
> Grupo Python-Brasil
> http://www.python.org.br/wiki/AntesDePerguntar
>
> <*> Para visitar o site do grupo na web, acesse:
> http://groups.google.com/group/python-brasil
>
> <*> Para sair deste grupo, envie um e-mail para:
> python-brasi...@googlegroups.com
>
> ---
> Você recebeu essa mensagem porque está inscrito no grupo "Python Brasil" dos
> Grupos do Google.
> Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie
> um e-mail para python-brasi...@googlegroups.com.
> Para mais opções, acesse https://groups.google.com/d/optout.

[Guilherme Medeiros]

Vinicius,

respondendo as tuas perguntas de uma forma simples (espero que eu consiga ajudar):

1 - você está parcialmente errado.

2 - sim, existe.

Palavras chave para vc por no google, caso não queria ler todo o texto gigante que vem abaixo:

REST, Single Page Application, AngularJS, EmberJs, Django-Rest-Framework

HTTP é um padrão de comunicação entre duas máquinas (cliente e servidor). A nova versão deste protocolo só define novas maneiras dessa comunicação acontecer, criptografia, cache e coisas do tipo.

O que você exemplificou e está falando é um PADRÃO DE PROJETO.

O padrão mais comum, que a forma básica que os frameworks que você comentou trabalham, é exatamente da meneira que vc descreveu.

Uma requisição que chega a aplicação, que recebe essa informação, prepara a página HTML e retorna para o usuário.

Nesse padrão existe sim CSS, HTML, JavaScript no lado do cliente.

A questão é que para cada ação na tela que precise de informação do servidor a tela toda é recarregada.

A galera chamava esse ato de WEB 1.0

Aconteceu então a evolução da comunicação entre o cliente e o servidor.

AO invés de você pedir a página toda para o servidor, você pede uma parte da página.

Para isso usa-se AJAX. Uma requisição assíncrona, geralmente feita em JavaScript.

E ai o mundo evoluiu para o ponto que temos agora, que é o que você achou legal.

O padrão de projeto chama-se SAP (Single Page Application).

Neste cenário, ao acessar a página, o Javascript carrega coisa pra caramba para não precisar mais ter que carregar a tela.

Cada ação que precisa de dados pede para o servidor, geralmente usando um padrão chamado REST.

Assim sua tela nunca é recarregada.

Caso ficou afins, tutoriais em portugues:
- https://danilosi.gitbooks.io/criando-aplicacao-com-django-e-angular/content/
- http://www.mateuspaduaweb.com.br/iniciando-com-django-rest-framework-e-angularjs/

Você está recebendo esta mensagem porque se inscreveu no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasi...@googlegroups.com.

Para obter mais opções, acesse https://groups.google.com/d/optout.

[Eduardo Cuducos]

Concordo em quase tudo que o Guilherme falou.

Resumiu bem: REST, Single Page Application, AngularJS, EmberJs, Django-Rest-Framework.

Pessoalmente só acho que o Angular e o Ember devem ceder lugar a frameworks que são totalmente independente de back-end, como React e Elm. Mas de qualquer jeito, a pegada é essa, só aposto diferentes frameworks de javascript para o front-end hehe…

[Vinicius Assef]

Pessoal, esse é um assunto que eu me interesso bastante.

Vou tentar ajudar com um pouquinho que sei.

Começando pelo começo (meu xará que iniciou a thread).

Vinicius, o cenário que você descreveu como "hoje" é isso mesmo, pelo que vejo. Mas muita gente já partiu para o que você descreveu como "futuro".

Então, o "hoje" é misto. Até porque, como você bem pontuou, se o sistema tem um cliente mobile, precisa dar um jeito de aproveitar o backend. A única ressalva que faço é que sempre vai haver framework para desenvolvimento profissional em ambiente web, mesmo em frontend. Então, sim, vamos ter que aprender mais coisas! hehehe

Sobre o que o Guilherme respondeu, o fato de gerar HTML no backend não necessariamente precisa recarregar a página toda. Ajax também se vira bem com esse modo de trabalhar. Eu sei que pelo excelente nível da sua resposta, você já sabe disso, Guilherme. Talvez você tenha só se expressado mal ou esquecido desse detalhe.

É difícil dizer o que vai vingar ou o que vai morrer, mas eu não acredito em "one size fits all". Como os dois paradigmas têm características que beneficiam um ou outro tipo de aplicação, eu arriscaria dizer que ambos vão conviver harmoniosamente por um bom tempo.

O ruim dessa tecnologia toda é que pra desenvolvimento em larga escala só rola JS no frontend, por enquanto. Por enquanto! :-)

--

Vinicius Assef.

[Vinicius Assef]

Pessoal, encontrei hoje esse texto que fala justamente sobre o assunto dessa thread: https://dev.to/ben/the-fat-client---thin-client-debate

[Vinicius Piassa]

Pessoal,

(La vai 300 paginas abaixo hehe!)

Muito esclarecedor todos os comentários, pois me mostra que eu não sou o único a ter essa linha de raciocínio, pois depois de tanto estudar estava meio receoso das minhas qualidades mentais sobre o assunto. hehe!

Guilherme excelente sua explanação mas eu estava pensando em algo alem do AngularJS ou do EmberJs ou até mesmo o que o Eduardo falou React para o front-end eu li bastante sobre os frameworks e ja ate desenvolvi algumas aplicações para teste, porem quando eu li sobre o projeto Polymer eu vi algo novo que tanto o Angular e o Ember ainda não tem que é a questão dos Web Components eu sei que é errado comparar os dois, pois Angular e Ember são frameworks completos já o Polymer é somente uma biblioteca inclusive esta se sustentando através de polyfills visto que os navegadores ainda tem que se adequar a W3C e o modelo de HTTP 2.0. 

Mas o Polymer me fez colocar em pratica algo que eu já estava querendo a muito tempo e não é sobre processamentos AJAX e sim a necessidade de um site estar no ar mesmo o cliente estando fora do ar exemplo:

O cliente acessa o site https://xpto.com.br/ todo o site vai para o cache do navegador (Dai a necessidade de somente existir HTML, CSS, JAVASCRIPT). 

Depois o site faz um carregamento do banco de dados do servidor para o navegador através de localstorage (REST ou Graphql). 

Quando o cliente vai trabalhar em um formulário ele envia os dados para localstorage e então o localstorage envia para o servidor REST ou Graphql (que ao meu ver é bem promissor)

Quando o cliente estiver fora do ar toda a operação é guardada em localstorage e quando ele voltar a ficar online a operação é atualizada para o servidor. 

Para mim essa é a maior conquista de todas, pois poderíamos transcender o limite da conexão e mesmo assim estar conectado.

Então na verdade era essa a forma de Futuro que eu estava a falar e não somente AJAX ou SPA, pois gostaria de saber se já existe algo sendo desenvolvido neste sentido. Eu já vasculhei muito por ai e o máximo que eu achei foi alguns artigos falando sobre o cache manifest do HTML5 mas nada de muito concreto ou algum exemplo de sistema que já esta utilizando isto. Já com SPA achei bastante coisa já feita como esses dois excelente exemplos. http://www.technics.com/global/ https://www.hpmagicwords.com.br/#en 

Agradeço o comentário de todos e ao meu xará Vinicius eu acredito que a proposta que o Polymer vem trazer é justamente melhorar essa relação do desenvolvimento de Javascript, CSS e HTML e trazer um melhor padrão para integração de APIs. E sobre o link do dev.to ele abordou o tema visando desempenho tanto no cliente quanto no servidor e eu ainda não tinha parado para pensar desta forma, mas já em se tratando de internet das coisas eu tenho que concordar com ele.

Para melhor referenciar segue alguns links abaixo:

Cache de paginas offline - https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API

O que é Polymer (excelente artigo do Beto Muniz) - http://betomuniz.com/blog/desmistificando-o-polymer-parte-1/

Vinicius Piassa

[Paul Eipper]

Re: futura web está se transformando mais em uma plataforma de runtime
para código remoto do que um protocolo de hypertexto.

https://webassembly.github.io/

Quando será a hora de um novo protocolo "web://" ?

att,
--
Paul Eipper

[Guilherme Rezende]

Eu criei a um tempo o seguinte projeto para brincar disto: http://github.com/guilhermebr/backenderia

Frontend é AngularJS-1 e o Backend está em Go, mas a ideia do projeto é justamente separar 100% os atores.

Estou estudando React para ver se vale a pena mudar o projeto...

Você está recebendo esta mensagem porque se inscreveu no grupo "Python Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para python-brasi...@googlegroups.com.

Para obter mais opções, acesse https://groups.google.com/d/optout.

--

Guilherme Bessa Rezende

Software Engineer | DevOps

Resume: https://guilhermebr.github.io/resume/

Linkedin: https://br.linkedin.com/in/guilhermerezende

Github: http://github.com/guilhermebr

Skype: gbrezende

guilhermebr.com

[Rubens Pinheiro]

Sou dev. front-end e hoje já trabalho com o front totalmente separado do server. O server fica na Amazon EC2 enquanto o front é replicado do S3 para os CDNs. Basicamente o melhor dos dois mundos, enquanto o server (REST) fica altamente escalável, o app front é fornecido de forma eficiente pelo CDN.O cuidado maior é só na configuração do CORS, para a comunicação entre o app front e back, fora isso é beeem mais tranquilo trabalhar com os dois totalmente separados.

Isso trás inúmeras vantagens, como desenvolver 'n' aplicações que consumam esse server, como desktop, mobile, etc. Testes de integração ficam muito mais simples no front, já que podemos 'mockar' o comportamento do server REST. Podemos inclusive mudar o server de linguagem! (desde que respeite a mesma api REST)

Hoje em dia as aplicações estão cada vez mais fragmentadas e mais especializadas (como micro services), dessa forma o deploy, manutenção e desenvolvimento em geral sempre ficam mais simples.

Rubens Pinheiro Gonçalves Cavalcante

Bacharel em Ciências da Computação - UECE

Pós Graduando em Arquitetura de Sistemas - Fa7

Desenvolvedor Front End - Trixlog

[André Ramos]

Aqui na empresa em que trabalho utilizamos este modelo de desenvolvimento. Uma das grandes vantagens é a facilidade para integrar com outros projetos, sendo altamente recomendado para projetos que pretendem ultrapassar as barreiras do browser.

Este artigo no wikipedia explana bem o assunto. =)

[Juscilan Moreto]

Olá,

Aproveitando o tópico fiz um rascunho de uma Stack Web, gostaria de saber opiniões.

att,

juscilan.com

Em quarta-feira, 1 de junho de 2016 17:50:03 UTC-3, Vinicius Piassa escreveu: