Separar Front-end do Back-end

[Renan Ribeiro de Oliveira]

E aí galera? Seguinte, andei vendo algumas palestras sobre esse assunto e gostaria dá opinião de vocês.

Como vocês estão gerenciando as suas aplicações?

--

[]'s

Renan Oliveira

Graduando em Sistemas para Internet

[Rodrigo Mendonça]

Ainda não tomei uma atitude quanto a isso e Estou apenas contando com o CDN. Estou muito ancioso para ver as respostas.

--
--
Você recebeu essa mensagem porquê está inscrito no Google
Groups "rails-br".
Para enviar uma mensagem para o grupo, mande um email para rail...@googlegroups.com
Para se descadastrar, mande um e-mail para
rails-br+u...@googlegroups.com
Visite o grupo em http://groups.google.com/group/rails-br?hl=pt-BR
Leia nossa política de uso: http://goo.gl/YGgt7

---
Você recebeu essa mensagem porque está inscrito no grupo "rails-br" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para rails-br+u...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

--

Rodrigo Mendonça

[Danilo Formiga]

Toda aplicação que faço, estou dando preferência a separar o front-end do back-end... (a não ser que o cliente não queira)

Evito dores de cabeça no futuro, se precisar fazer a aplicação mobile já tem um serviço para consumir, se precisar criar outro front-end não tem nenhum impacto na aplicação...

E uma dica é utilizar AngularJS no frontend, facilita mais ainda sua vida :P crio um serviço para cada requisição e monto.

Em 13 de outubro de 2015 17:36, Renan Ribeiro de Oliveira <renan.o...@dce.ufpb.br> escreveu:

--

--
Você recebeu essa mensagem porquê está inscrito no Google
Groups "rails-br".
Para enviar uma mensagem para o grupo, mande um email para rail...@googlegroups.com
Para se descadastrar, mande um e-mail para
rails-br+u...@googlegroups.com
Visite o grupo em http://groups.google.com/group/rails-br?hl=pt-BR
Leia nossa política de uso: http://goo.gl/YGgt7

---
Você recebeu essa mensagem porque está inscrito no grupo "rails-br" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para rails-br+u...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

--

Danilo Formiga
Graduado em Sistemas da Informação - UFPB
Celular: + 55 (83) 8867-5156
Email: danilo...@gmail.com
Skype: danilo.formiga
Site: www.daniloformiga.com
Linux User: #506650

[Renan Ribeiro de Oliveira]

Essa é a palestra que assisti, gostei bastante da estrutura.

http://goo.gl/gtt1Sk

[Renan Ribeiro de Oliveira]

@Danilo 

Nessa separação, você separa totalmente o frontend ou faz um mix na app, utilizando os helpers do rails.

[Elmano Neto]

Nos últimos projetos em que participei todos foram assim.

Projetos independentes.

Além de ficar mais organizado, vc não precisa fazer redeploy de toda aplicação quando ela for crescendo, apenas da camada em que mudou.

att,

Elmano Neto

[Danilo Formiga]

@Renan

Atualmente é tudo modularizado, para ter noção não precisamos nem executar na mesma maquina... O backend em rails roda em uma maquina e o frontend em outra... o frontend é apenas mais um cliente consumindo o serviço.

Eu acredito que misturar as coisas não é interessante, ou é 8 ou 80 :P (apenas opinião).

[Alex Takitani]

Não separo só por separar, só uso algo mais pesado de js quando se faz necessário.

Cuidado com essa moda de usar frameworks js só pq todo mundo está usando. 

[Elmano Neto]

Sim, tem que ver de acordo com a necessidade, se for pra fazer um simples blog talvez não tenha tanta necessidade para isso.

att,

Elmano Neto

[Danilo Formiga]

@Alex,

De fato, usar qualquer framework por modinha é um tiro no pé. (e relutei bastante para começar a usar frameworks, principalmente JS)

Entretanto, havendo demanda, porque não? Produzo meus apps desta forma porque para mim acaba sendo mais produtivo.

Cada um com sua opinião e sua necessidade :P

[Everaldo Gomes]

Concordo com o Alex. Pra quem é iniciante é uma pedra a mais no sapato.

[Alex VKO]

O que mais me deixou satisfeito em todos os sentidos foi usar assim:

Front-end: 

- YEOMAN

- AngularJS

- Gulp (e todos seus plugins de minificar, cache, ng-annotate, autoreload, server e etc...)

- Coffee

- Jade

- Node.js

Back-end:

- rails-api

- devise-auth-token (authenticação tem que ser com token, até da pra fazer com sessão, mais sempre da problema em desenvolvimento mobile nativo)

Flw

Como uso heroku, deixo cada um em um servidor. o Front end no plano mais barato, e conforme escala vou subindo o plano só do back-end

[Renan Ribeiro de Oliveira]

@Alex

Achei legal a sua solução, só achei um pouco mais complexa. Acho que essa questão de separar frontend e backend parte muito da necessidade de cada aplicação como já foi citado acima. Acredito que rails gerencia bem seu frontend, cabe da nós programadores torna-lo mais simples para aumentar a produtividade, quanto mais tecnologias, mais coisas para se preocupar.

--

--
Você recebeu essa mensagem porquê está inscrito no Google
Groups "rails-br".
Para enviar uma mensagem para o grupo, mande um email para rail...@googlegroups.com
Para se descadastrar, mande um e-mail para
rails-br+u...@googlegroups.com
Visite o grupo em http://groups.google.com/group/rails-br?hl=pt-BR
Leia nossa política de uso: http://goo.gl/YGgt7

---
Você recebeu essa mensagem porque está inscrito no grupo "rails-br" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para rails-br+u...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

[Nelson Haraguchi]

Aqui na www.doghero.com.br comecei com projeto Rails normal. Mas já pensando em separar api do resto. Mais por causa da velocidade em colocar algo no ar rápido. 

Nosso Admin está separado usando Angular e mesmo o front-end do site público estamos transformando para consumir APIs mesmo que hoje o Rails ainda renderize o html. Não uso de maneira nenhuma os helpers pois isso vai prejudicar muito a transição para separar totalmente do Rails.

Ainda quero usar o electron.atom.io para montar o sistema interno de gerenciamento como um app HTML5 no desktop consumindo as APIs tbm.

Separar o front do back end ajuda muito. Facilita escalar e melhorar a performance.

Mesmo no back-end a separação em micro services ajuda muito. Recentemente separei as chamadas de API de mensageria que mais consumiam recursos em uma estrutura separada para poder escalá-las separadamente. Assim pude reduzir as outras chamadas para servidores menores.

Uso o AWS Opsworks para a API e o site em Rails e o Front-end em Angular está no S3 direto.

Nelson Minor Haraguchi Junior
---

Gtalk: nelso...@gmail.com
Twitter: http://twitter.com/nelsonmhjr

Linkedin: http://br.linkedin.com/in/nelsonmhjr

[Renan Ribeiro de Oliveira]

@Nelson Muito boa essa separação, e o frentend você usa dentro de um servidor http(nginx)?

[Nelson Haraguchi]

Não coloquei dentro de um servidor http próprio pois o AWS S3 funciona como website também. 

E como o frontend é basicamente HTML CSS e JS, não precisa ter nenhum processamento. 

Vantagem é que a escalabilidade dele é muito boa. E ainda dá pra colocar no CloudFront da AWS e ter o front sendo servido via CDN. 

E o custo do S3 é bem baixo. Pelos meus cálculos, 1milhão de visualizações custariam 5 dólares por mês.

Nelson Minor Haraguchi Junior
---

Gtalk: nelso...@gmail.com
Twitter: http://twitter.com/nelsonmhjr

Linkedin: http://br.linkedin.com/in/nelsonmhjr

[Felipe Casadei]

E qual a estratégia vocês pretendem utilizar para manter a compatibilidade com os search engines quando migrarem o front-end para o Angular?

Que a separação traz benefícios é inegável, mas é preciso conhecer bem o trade-off desta decisão.

[Nelson Haraguchi]

O que ajuda muito nessa questão do SEO é o Prerender.io.

Ele não funciona se o site estiver no S3, nesse caso o backend precisa estar em um web server que nós temos controle.

Mas como ele funciona como um plugin do nginx (ou apache) o site ainda pode ser servido todo estático. 

Mas todo o resto pode estar no S3 já que só quem está logado pode acessar.

Nelson Minor Haraguchi Junior
---

Gtalk: nelso...@gmail.com
Twitter: http://twitter.com/nelsonmhjr

Linkedin: http://br.linkedin.com/in/nelsonmhjr

[Danilo Formiga]

@Felipe Casadei

A própria Google resolveu este tipo de crawler :P

http://blog.caelum.com.br/angularjs-seo-google-analytics-e-virtual-pages/

Existe o prerender para isto também (sendo que é pago) https://prerender.io/

Em 14 de outubro de 2015 20:25, Felipe Casadei <felipe....@gmail.com> escreveu:

--

[Felipe Casadei]

@Danilo,

Sim, assim como o prerender, existem diversas outras soluções pra esse problema. Confesso que não sei se o crawler da google já está 100% compatível com SPA, mas a tendência é só melhorar.

No próprio artigo que você mandou tem um exemplo de implementação para manter a compatibilidade com o Google Analytics, o que adiciona mais complexidade à aplicação.

Assim como este problema com SEO, existem outros como por exemplo performance do primeiro acesso. Vários players importantes (como airbnb e netflix) já publicaram seus cases sobre como atacaram esses e outros problemas. Se você ler cuidadosamente, vai ver que seus processos passaram por decisões bastante complexas, como a mudança da stack (no caso do airbnb de rails pra node.js)

Minha intenção no e-mail anterior era só levantar o exemplo de um dos vários trade-offs existentes nessa abordagem que precisam ser levados em consideração na hora de tomar esta e outras decisões arquiteturais. Não se pode optar por esse caminho somente pelo fato de ser uma tendência (que a longo prazo acredito que vai se estabilizar) ou por que é "elegante".

Segue os links dos cases que citei acima:

http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/

http://techblog.netflix.com/2015/08/making-netflixcom-faster.html

Vale lembrar que os dois cases são de aplicações com demandas absolutamente incomuns e por isso também necessitam de soluções incomuns.

Abraços

[Ruan Carlos]

http://googlewebmastercentral.blogspot.com.br/2015/10/deprecating-our-ajax-crawling-scheme.html

Q: I use a JavaScript framework and my webserver serves a pre-rendered page. Is that still ok? 
A: In general, websites shouldn't pre-render pages only for Google -- we expect that you might pre-render pages for performance benefits for users and that you would follow progressive enhancement guidelines. If you pre-render pages, make sure that the content served to Googlebot matches the user's experience, both how it looks and how it interacts. Serving Googlebot different content than a normal user would see is considered cloaking, and would be against our Webmaster Guidelines.

[Jonathan Calixto]

@Alex, como seria isso, você levanta duas aplicações rails? uma para front-end em um server e outra outros server para back-end?

Atenciosamente,

Jonathan Celestino Calixto

Desenvolvedor Web Ruby on Rails
email:     jonathan...@gmail.com
msn:       jonathan...@gmail.com
github:    https://github.com/jonathanccalixto
skype:    jonathanccalixto

twitter:    jonathanccalixt

[Antônio Roberto Silva]

Aqui a gente tem separado também utilizando:

Mithriljs + PostgRest (api) + Rails

A nossa lib front end fica separada do rails app,  dai só montamos o componente, tenho ate esse slide aqui que mostra um pouco como funciona http://pt.slideshare.net/tonnysk823/using-mithriljs-postgrest-to-build-and-consume-apis

Usamos tambémo heroku, então fica facil separar api server + rails server + front server

[]'s

[Alex VKO]

Fala @Jonathan,

Não, a aplicação rails é só pro Back end, o front end roda em um server simples com Nodejs, como descrito

[Nelson Haraguchi]

Boa noticia essa do Google....

Nelson Minor Haraguchi Junior
---

Gtalk: nelso...@gmail.com
Twitter: http://twitter.com/nelsonmhjr

Linkedin: http://br.linkedin.com/in/nelsonmhjr