Replies: 30 comments 1 reply
-
|
O que seria trabalhar desaclopado? Sem tocar no código do back-end? |
Beta Was this translation helpful? Give feedback.
-
|
nunca ouvir falar... |
Beta Was this translation helpful? Give feedback.
-
|
@lfeh sim, seria o front-end totalmente independente do back-end |
Beta Was this translation helpful? Give feedback.
-
|
Depende do projeto, mas acredito que o ideal seria sempre "desacoplado". Assim se dividem melhor as responsabilidades de cada área do projeto. Acho :) |
Beta Was this translation helpful? Give feedback.
-
|
Aqui o front é "desaclopado". O backend é desenvolvido em Grails e fica responsável pela API e pelos workers. Em outro projeto fica o frontend que consome a API. Não vemos sentido ter ambos no mesmo projeto e dessa forma conseguimos trabalhar bem melhor. Mais organizado, mais produtivo, mais independente etc. A infra fica toda na Amazon, o back fica em um EC2 e o front em um bucket S3. |
Beta Was this translation helpful? Give feedback.
-
|
@lagden é o front rodando em outro serviço com outra porta, e só consome a API de vários outros "back-ends"; sacou? |
Beta Was this translation helpful? Give feedback.
-
|
Creio que essa seja a melhor forma de se desenvolver pra web. |
Beta Was this translation helpful? Give feedback.
-
|
@mvfsilva Consegue resenhar melhor o workflow dessa forma? Você não roda APIs localmente, só consome de algum servidor, é isso? |
Beta Was this translation helpful? Give feedback.
-
|
Aqui na ContaAzul estamos caminhando para esse processo. Porém, como seria o workflow para pegar uma versão da API em desenvolvimento? Apontaria para um server de homologação, como rodaria a versão local? Pra mim essa é a maior questão. Outra coisa, como fazemos com aplicações como |
Beta Was this translation helpful? Give feedback.
-
|
Explicando brevemente, nesse modelo voce possui vários "ends", os dados e eventos acontecem por REST APIs. No exemplo mais simples é como se o backend e o frontend fossem sistemas distintos, sendo que o backend fornece a api e o frontend consome e interage com dados por ela. Mas to vendo um caso mais extremo onde os dados vêm de varios lugares e um sistema principal "digere" os dados para serem servidos como api principal, que então é utilizada por vários fronts diferentes (browser, android, ios, hulu, e outras plataformas de tv, além de sites diferentes, etc). O lance é interoperabilidade dos dados. Várias tecnologias diferentes (isso tambem significa muita gente, times separados) podem acessar e manipular os mesmos dados. |
Beta Was this translation helpful? Give feedback.
-
|
uma boa saída é usar um mock das requisições da api, assim vc consegue trabalhar simulando o back-end e tratando os retornos. |
Beta Was this translation helpful? Give feedback.
-
|
Para desenvolvimento, uma alternativa são os serviços como o Apiary.io Aqui no Moskit CRM, fazemos totalmente desacoplado como o @willycamargo disse ali em cima. Desenhamos a API antes, que é implementada para que depois o front seja desenvolvido consumindo ela (equipe front sempre participa da spec da api) |
Beta Was this translation helpful? Give feedback.
-
|
@lfeh sim já consigo entender melhor! |
Beta Was this translation helpful? Give feedback.
-
|
Para as aplicações como elas são hoje, "desacoplado" é o ideal. Atualmente, por exemplo, estou trabalhando em um produto em que o front-end das aplicações (web, iOS e Android apps) apenas consome uma API RESTful – um bom exemplo do que o @bernardodiasc citou. O ideal é ter uma REST API fake (como json-server), para ir fazendo a aplicação web sem dependência do back-end. |
Beta Was this translation helpful? Give feedback.
-
|
Depende muito do propósito da aplicação, hoje as apis e camadas de integração ganharam força por proporcionarem a unicidade de serviços para distintas plataformas (web, android, ios dentre outros consumindo um único serviço) porém, em cenários tais como o segmento bancário onde as transações devem ser ocultas ao extremo, fazer um sistema acoplado garante menor exposição dos serviços e acaba ser a opção mais sensata. Outra coisa, uma arquitetura orientada a serviços também possui seus contras, irei citar alguns:
Outra coisa no passado o front-end exigia somente HTML e CSS e em alguns casos a jQuery como complemento, sendo que a grande maioria indivíduos somente sabia utilizar os recursos da jQuery sem qualquer proficiência no Javascript puro. Hoje com a entrada das frameworks MVVM onde o front-end passou a exigir maior competência no desenvolvimento de aplicações, os recursos com pouca expertise em javascript e lógica acabam por ficar inúteis. Sua empresa precisa ter uma equipe bem matura no que compete ao uso das MVVM`s e outros recursos, pois se o client-side vai assumir mais responsabilidade a equipe também vai. |
Beta Was this translation helpful? Give feedback.
-
|
@felipeuntill bem interessante os pontos colocados. Só comentando algo sobre o ultimo parágrafo, isso não é uma regra, e sim uma tendência. A mesma arquitetura pode ser utilizada com client rodando num server por exemplo. Digo, usar libs mv* js no front pra renderizar no device é uma das centenas de formas de fazer isso, e IMHO não é solução para todos os casos. |
Beta Was this translation helpful? Give feedback.
-
|
@mvfsilva acho interessante existir um full stack na equipe, apenas pra existir uma ponte entre os ambientes. |
Beta Was this translation helpful? Give feedback.
-
|
beleza @lagden ;) |
Beta Was this translation helpful? Give feedback.
-
|
Eu também acho que desacoplar back-end do front-end é o ideal na maioria dos casos. O fato de ter todo o seu front-end 100% "independente" do server é uma puta vantagem se você pensar que hoje em dia os novos projetos tem como maior preocupação a velocidade de entrega no lugar da escalabilidade em si. Em outras palavras: Fazer primeiro, otimizar depois. Com o front-end totalmente independente do back-end, caso seja necessário refatorar todo o código, trocar tecnologias, ou até mesmo mudar a linguagem back-end, toda essa mudança seria 100% transparente para o front, desde que o back-end expusesse a mesma API que já estava sendo utilizada. Atualmente estou trabalhando em um projeto com meu sócio onde decidimos fazer exatamente isso. Nós temos um micro-servidor intermediário em Node.js responsável apenas por ouvir as URLs requisitadas pelo usuário e retornar o código front-end. Todas as outras interações são feitas diretamente pelo client-side se comunicando com a API Java. Ambos os servidores (Node.js para entregar o front, e Java para os serviços) estão atrás do NGINX que está fazendo papel de proxy reverso (e futuramente, load-balancer). Eu mal vejo o código back-end que meu sócio desenvolve, e ele mal vê o código front-end que eu desenvolvo, a interação ocorre apenas por meio das APIs REST, tornando o desenvolvimento 100% independente dos dois lados. |
Beta Was this translation helpful? Give feedback.
-
|
Discussão boa pra caraio pessoal. |
Beta Was this translation helpful? Give feedback.
-
|
A minha maior questão é como controlar a sessão, como faria o login e ir controlando isso, pois ficar chamando a api rest é tranquilo o ruim é amarrar a sessão. |
Beta Was this translation helpful? Give feedback.
-
|
@bosofelipe mas o conceito por trás do rest não é "não ter sessão"? Corrijam-me se eu estiver errado. Mas a solução pra esse tipo de coisa são protocolos tipo oAuth. Não? |
Beta Was this translation helpful? Give feedback.
-
|
Perfeito. Pra usar a API, vc vai trafegar dados que não dependam de sessão alguma. Lucas On Tue, May 3, 2016, 13:20 Lucas Mahle [email protected] wrote:
|
Beta Was this translation helpful? Give feedback.
-
|
@bosofelipe na verdade você sempre deverá mandar um token e o backend irá validar esse token... existe o jsonwebtoken: https://github.com/auth0/node-jsonwebtoken o cara faz a autenticação e o backend retorna um token para a sua aplicação gravar no local storage... |
Beta Was this translation helpful? Give feedback.
-
|
@bosofelipe Como o @lagden comentou, a ideia é que ao logar a primeira vez, o back-end devolva um token público com data de validade. Sempre que o front-end requisitar algo que seja restrito, ele envia esse token e o back-end valida a autenticidade ou não do valor. Caso o token tenha expirado, é como se a sessão tivesse morrido. Tudo que você requisitar vai retornar com erro de "não-autorização". A partir daí as alternativas seriam: Logar de novo manualmente, ou criar um serviço que permita atualizar o token enquanto ainda é válido (front-end percebe que a data de expiração do token está chegando, envia um request pedindo outro token, e substitui o antigo). |
Beta Was this translation helpful? Give feedback.
-
|
Porém, se a API não estiver bem feita o FrontEnd precisa mandar uns 3 requests por página para ser carregada para mais. Isso torna dificil o carregamento do app e dificil também de fazer um carregamento perfeito para o usuário. Será que em todos casos usar um WebService é o melhor caso? Existem situações que o render server side, algo assim? O que voces acham de usar Isomorphic Javascript? |
Beta Was this translation helpful? Give feedback.
-
|
Muito boa essa conversa!!! Na empresa onde eu trabalho são três devs. Eu sou front-end ( sou mais focado na questão de integração com o Back End além de UI ), um focado em back end e outro que é mais fullstack que é o chefe. Pra consumir as requisições da API eu uso na máquina local. Tenho dois servidores configurado na minha máquina. Um para o front da aplicação e outro só para tratar das requisições da API. Com isso, a única coisa que eu tenho que fazer é pegar a atividade que o dev back end desenvolveu, fazer um merge com a minha branch e integrar ao sistema. Sobre a questão de ser acoplado ou não, na minha opinião tem dois fatores... depende do tempo que você pretende lançar uma aplicação e o quanto investir. Se você teve uma ideia e precisa lançar a curto prazo e não tem recursos para investir a melhor ideia é criar algo acoplado. E depois com o tempo começa a pensar em fazer a aplicação com uma API separada. Mas caso tenha recurso para investir é melhor desacoplado, pelo simples fato que a ideia da sua aplicação pode evoluir e tomar proporções maiores, como uma aplicação para dispositivos móveis e outros dispositivos. |
Beta Was this translation helpful? Give feedback.
-
|
qual ideia do consumo via Front? Direto chamadas post ou get via js? |
Beta Was this translation helpful? Give feedback.
-
|
@gabrielfava, sim, e também respondendo a pergunta principal posso dizer que esta é a solução mais viável, pois nos dá uma nitidez do projecto, sem aquela confusão do back e front indo no mesmo canal, de modo que o cliente terá que pegar os dois pensemos um pouco, vamos lembrar do tempo em que nós juntávamos HTML e CSS no mesmo arquivo (isto era tão repugnante, vendo bem isto é mais repugnante do que pornografia infantil!!!), todos nós sabemos que isto cria uma baita confusão na parte de manutenção do projecto, e a junção do back e front representa quase o mesmo hoje, então eu acho que esta analogia de separar o servidor front do back é muito vantajosa, tanto para o usuário, pois terá uma melhor resposta e mais rápida. E para o desenvolvedor que terá uma melhor experiência no desenvolvimento (e acreditem, nós devemos ter uma boa experiência no desenvolvimento de uma aplicação!!!) |
Beta Was this translation helpful? Give feedback.
-
Depende da API... Tem uma coisa muito importante! É muito comum a utilização do SSR (server-side render) junto com sua aplicação Frontend. Ele funciona como um helper para dar melhor desempenho, ajuda no SEO, etc... Esse backend funciona como braço direito do seu frontend, ou seja, um app único. Sendo assim, ainda teremos que consumir uma outra aplicação (API). Docs:
|
Beta Was this translation helpful? Give feedback.
-
|
Complementando, esse artigo da freeCodeCamp explica como implementar a técnica de Server-Side Rendering em projetos que utilizam a biblioteca React. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Em uma longa discussão sobre um projeto aqui na empresa que eu trabalho, meu time foi questionado sobre os motivos se trabalhar de forma desacoplada e se existem vantagens sobre a performance?
Beta Was this translation helpful? Give feedback.
All reactions