mean - exemplo

8/16/2019 Mean - Exemplo

http://slidepdf.com/reader/full/mean-exemplo 1/30



Original English language edition published by Manning Publications Co., Copyright © 2014 by ManningPublications. Portuguese-language edition for Brazil copyright © 2016 by Novatec Editora. All rights reserved.

Edição original em Inglês publicada pela Manning Publications Co., Copyright © 2014 pela Manning Publications.Edição em Português para o Brasil copyright © 2016 pela Novatec Editora. Todos os direitos reservados.

© Novatec Editora Ltda. 2016.

Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmoparcial, por qualquer processo, sem prévia autorização, por escrito, do autor e da Editora.

Editor: Rubens Prates PY20160329Tradução: Henrique Cesar UlbrichRevisão gramatical: Smirna CavalheiroAssistente editorial: Priscila A. YoshimatsuEditoração eletrônica: Carolina Kuwabata

ISBN: 978-85-7522-491-5

Histórico de impressões:

Abril/2016 Primeira edição

Novatec Editora Ltda.Rua Luís Antônio dos Santos 11002460-000 – São Paulo, SP – BrasilTel.: +55 11 2959-6529Email: [email protected]: www.novatec.com.brTwitter: twitter.com/novateceditoraFacebook: facebook.com/novatecLinkedIn: linkedin.com/in/novatec



19

CAPÍTULO 1

Introdução ao desenvolvimento em full-stack

Este capítulo descreve:

• Os benefícios do desenvolvimento em full-stack.• Uma visão geral sobre os componentes do MEAN.

• O que torna o MEAN tão especial.

• Uma descrição de como será a aplicação que construiremos ao longo dolivro.

Se você é como eu, deve estar impaciente para mergulhar de cabeça no códigoe criar alguma coisa que já saia funcionando. Mas vamos relaxar um pouco e

“perder” algum tempo para esclarecer o que seria o desenvolvimento em full-stack,bem como conhecer as partes componentes do stack para que todos entendamoscada uma delas.

Quando eu falo em desenvolvimento full-stack, me refiro ao desenvolvimentode todas as partes de um site ou aplicação web1. A “pilha” de tecnologias come-ça com um banco de dados e um servidor web no back-end, contém a lógicada aplicação e os controles nas camadas do meio, e termina com a interface dousuário no front-end.

O MEAN é composto por quatro tecnologias principais, com um “elenco de apoio”formado por algumas tecnologias auxiliares:

• MongoDB – o banco de dados.

1 N. do T.: Stack é uma palavra inglesa que significa “pilha”, “empilhamento”, “amontoado de coisas”.Em tecnologia, costuma-se usar a palavra stack para descrever um grupo de tecnologias diferentesque trabalham em conjunto, como os músicos de uma orquestra. Em alguns casos, cada “camada”da pilha não se comunica com todas as outras camadas, mas apenas com a que está imediatamenteacima ou abaixo dela – é o caso da “pilha de rede” TCP/IP, por exemplo. Neste livro não traduzimosa palavra stack, mas é importante que o leitor tenha em mente a noção de empilhamento paraentender como um stack funciona.



MEAN Definitivo20

• Express – o framework para web.

• AngularJS – o framework para a interface com o usuário.

• Node.js – o servidor web.

O MongoDB existe desde 2007, e é ativamente mantido pela empresa MongoDB Inc.,anteriormente conhecida como 10gen.

O Express foi lançado em 2009 por T. J. Holowaychuk e, desde então, tornou-seo framework mais popular para o Node.js. Ele tem código aberto e mais de cemprogramadores estão envolvidos em seu desenvolvimento, além de ter amplosuporte dos desenvolvedores que o usam em seus projetos e da comunidade dosoftware livre em geral.

O AngularJS também é open source e é mantido pela Google. Já existe desde2010 e está em constante desenvolvimento, com novas funcionalidades sendoadicionadas todos os meses.

O Node.js foi criado em 2009, e seu desenvolvimento e manutenção são financia-dos pela empresa Joyent. O Node.js usa como base um interpretador JavaScriptde alto desempenho chamado V8, desenvolvido pela Google e de código com-pletamente aberto.

1.1 Mas por que eu deveria aprender a desenvolver em full-stack?É, por quê? Para quem olha de fora, parece uma quantidade monstruosa de tra-balho para uma pessoa só! Bem, sim,é bastante trabalho, mas todo o esforço com-pensa no final. Ademais, com o MEAN o trabalho não é tão grande como parece.

1.1.1 Pequena história do desenvolvimento web

Naqueles dias longínquos em que a web foi concebida, as pessoas não tinham tantaexpectativa a respeito dos sites. Quase nenhuma ênfase era dada à apresentação,o que mais importava era o que estava por trás. Tipicamente, se você conheciaPerl ou algo parecido e sabia “alguma coisinha” de HTML, já era considerado umdesenvolvedor web de fato.

Com a disseminação do uso da internet, as empresas começaram a se interessarem como eram retratadas nos seus cartões de visita online. Os navegadores supor-tavam com cada vez mais consistência tecnologias como Cascading Style Sheets

(CSS) e JavaScript, e, portanto, esse interesse das empresas levou a implementações



21Capítulo 1 ■ Introdução ao desenvolvimento em full-stack

de front-end cada vez mais complexas. Aquela “alguma coisinha” de HTML jánão era mais suficiente; era preciso gastar bastante tempo “penteando” arquivosCSS e JavaScript para ter certeza de que tudo funcionaria como esperado, e emtodos os navegadores – algo bem complicado na época, quando eles eram bem

menos aderentes às normas do que hoje.É aí que entra a distinção entre um desenvolvedor de front-end e um de back-end.A figura 1.1 ilustra essa separação ao longo do tempo.

Complexidade

do front-end

Desenvolvedores

de front-end

e back-end

Desenvolvedores

de front-end

Desenvolvedores

de back-end

Tempo

Complexidade

do back-end

Figura 1.1 – O grande abismo entre os desenvolvedores de front-end e back-end aolongo do tempo.

Enquanto os desenvolvedores de back-end sempre se concentraram na mecânicado site, nos bastidores, os desenvolvedores de front-end ocupavam-se de construiruma boa experiência para o usuário. No decorrer dos anos, ambos os profissionaisforam sendo pressionados com expectativas cada vez mais altas, encorajando

essa divisão a continuar e até a aumentar a distância entre as especialidades. Umdesenvolvedor em início de carreira era praticamente obrigado a escolher um doscampos e se especializar nele.

AUXILIANDO OS DESENVOLVEDORES COM BIBLIOTECAS E FRAMEWORKS

Durante a década de 2000, as bibliotecas de funções e os frameworks começaram ase tornar populares e predominantes a muitas linguagens de programação, tanto nofront-end como no back-end. Exemplos não faltam: Dojo e jQuery no JavaScript

como front-end, ou o CodeIgniter no PHP e o famoso Ruby on Rails no back-end.



MEAN Definitivo22

Esses frameworks foram projetados para tornar a vida do desenvolvedor maisfácil, derrubando as barreiras para ingressar na profissão. Uma boa biblioteca ouframework abstrai algumas das complexidades de programação, permitindo quese desenvolva mais rapidamente com menos necessidade de conhecimento sobre

como o sistema subjacente funciona. Essa tendência de simplificação resultouem um renascimento dos desenvolvedores em full-stack, ou seja, desenvolvedoresque atuam no front-end da aplicação e, ao mesmo tempo, na lógica por trás dele,como mostra a figura 1.2.

Desenvolvedores

de full-stack

Introdução

dos frameworks

Complexidade

do front-end

Desenvolvedores

de front-end

e back-end

Desenvolvedores

de front-end

Desenvolvedores

de back-end

Tempo

Complexidadedo back-end

Figura 1.2 – Impacto dos frameworks nas facções separadas de desenvolvimento web.

A figura 1.2 ilustra uma tendência, mas não tem a intenção de afirmar categorica-mente que “todos os desenvolvedores web têm que se tornar full-stack”. Existiram,é claro, desenvolvedores full-stack durante toda a história da web, e é bem possível

que muitos desejem se especializar numa ou noutra área, front-end ou back-end – e não há nada de errado com isso! A intenção do gráfico é apenas mostrar quecom o uso de frameworks e ferramentas modernas não é mais necessário escolherum dos lados da moeda para ser um bom desenvolvedor web.

Uma enorme vantagem de abraçar os frameworks é que podemos ser incrivel-mente produtivos, e temos uma visão bastante global da aplicação e de como elafoi construída.




DESLOCANDO A APLICAÇÃO PARA AS CAMADAS SUPERIORES DO STACK

Com adoção em massa dos frameworks, nos últimos anos vimos uma tendênciacrescente de deslocar a lógica da aplicação “mais para a frente”, retirando-a doservidor e a implementando no próprio front-end. Podemos pensar na coisacomo sendo “programar o back-end no front-end”. Alguns dos mais popularesframeworks para JavaScript que fazem isso são o AngularJS, o Backbone e o Ember.

O fato de que grande parte do código da aplicação está, agora, no navegador dousuário e não no servidor começou a borrar a tradicional linha divisória entrefront-end e back-end. Uma das razões pelas quais as pessoas gostam de usar essaabordagem é a óbvia redução na carga de trabalho dos servidores e, portanto,redução de custos. O que se está, de fato, fazendo é distribuir as tarefas de com-putação requeridas pela aplicação para os navegadores, fazendo com que cadaum deles processe um pouco do que seria o trabalho do servidor, numa espéciede computação distribuída.

Discutiremos os prós e os contras dessa abordagem, e quando é ou não é apro-priado usar uma dessas tecnologias mais adiante no livro.

1.1.2 A tendência de se tornar um desenvolvedor full-stack

Como discutido, os caminhos dos desenvolvedores de front-end e back-end estãose encontrando, e é inteiramente possível ser proficiente em ambas as disciplinas.Se você é um freelancer, consultor ou membro de uma pequena equipe, ter essaexperiência multidisciplinar é extremamente útil, aumentando o valor que podeentregar para seus clientes. Ser capaz de desenvolver todos os aspectos de um siteou aplicação web dá ao profissional um controle mais abrangente sobre o pro-duto finalizado e pode fazer com que as diferentes partes do sistema trabalhemmuito melhor juntas, uma vez que foram construídas pela mesma pessoa e nãopor equipes trabalhando isoladamente.

Se trabalha com uma equipe maior, é bastante provável que tenha que se especiali-zar (ou, no mínimo, se concentrar) em uma das áreas. Mas sempre é recomendávelentender como os seus componentes se ajustam e se comunicam com os outros,proporcionando ao profissional uma visão maior sobre as necessidades e objetivosdas outras equipes e do projeto como um todo.

No frigir dos ovos, construir uma aplicação do começo ao fim, em full-stack, émuito gratificante. Cada uma das partes componentes da “pilha” tem seus pró-

prios desafios e problemas a resolver, o que deixa as coisas bastante interessantes.



MEAN Definitivo24

A tecnologia e as ferramentas disponíveis hoje tornam a experiência bem maisagradável, e permitem construir aplicações web realmente bacanas de forma fácile rápida.

1.1.3 Vantagens do desenvolvimento full-stack

Vantagens há, e inúmeras. Para começar, sempre é gostoso aprender coisas novas ebrincar com novas tecnologias. Há também a satisfação de dominar algo diferentee a emoção de ser capaz de construir e ativar uma aplicação completa, que incluibanco de dados, sozinho.

As vantagens, quando se trabalha em equipe, são várias:

• Uma visão geral muito melhor do sistema, das diferentes áreas e como elasse encaixam.

• Compreensão do que os outros membros da equipe estão fazendo e do queeles precisam para conseguir fazê-lo.

• Os membros da equipe podem se deslocar dentro de cada área mais livremente.

Existem ainda vantagens de se trabalhar sozinho:

• É possível criar aplicações “de cabo a rabo” sozinho, sem ajuda e sem de-

pender de ninguém.• Mais competências, serviços e capacidades para oferecer a seus clientes.

Existe muito ainda a dizer sobre o desenvolvimento em full-stack. Os desenvol-vedores mais capazes que já conheci eram todos full-stack. Sua compreensãoabrangente e sua habilidade para ver o problema como um todo são tremenda-mente bem-vindos.

1.1.4 Mas e por que, especificamente, o MEAN?O MEAN é um stack que agrupa algumas das melhores “raças” de tecnologiasweb e as transforma num conjunto bastante poderoso e flexível. Um dos grandeslances do MEAN é o fato de que ele não usa o JavaScript apenas no navegador,mas em todas as camadas da pilha. Usando o MEAN, é possível usar JavaScripttanto no front-end como no back-end.

A tecnologia de base que torna tudo isso possível é o Node.js, que traz o JavaScriptao back-end.




1.2 Uma introdução ao Node.js: um servidor/plataforma webO Node.js é o N do MEAN. Estar por último no acrônimo não significa ser omenos importante – pelo contrário, o Node.js é a parte fundamental do stack!

Resumidamente, o Node.js é uma plataforma de software que permite criar seupróprio servidor web e construir aplicações em cima dele. O Node.js não é, em si,um servidor web, e também não é uma linguagem de programação. Ele contémum servidor HTTP embutido, o que significa que não é necessário rodar umservidor HTTP à parte, como o Apache ou o Internet Information Services (IIS)da Microsoft. Isso proporciona ao programador um grande controle sobre comoo servidor trabalha, mas também aumenta a complexidade para colocá-lo noar, particularmente em um ambiente que já esteja funcionando e em produção.

Com o PHP, por exemplo, podemos facilmente encontrar um provedor de hospeda-gem rodando Apache (há até gratuitos), enviar alguns arquivos por FTP e – se tudocorrer bem – ter um site funcionando em pouquíssimo tempo. Tudo isso funcionaporque o provedor de hospedagem já configurou o Apache e o PHP para todos osusuários. Com o Node.js isso não ocorre, pois o servidor web embutido nele é con-figurado na própria aplicação. Muitos dos provedores tradicionais de hospedagemestão defasados em relação ao Node.js, mas estão surgindo alguns provedores dePlataforma como Serviço (PaaS – Plattform as a Service) para suprir essa demanda,

como, por exemplo, Heroku, Nodejitsu e OpenShift. A forma como os sites são en-viados para esses provedores PaaS (o que se costuma chamar de deploy) é bastantediferente do antigo modelo FTP, mas não é difícil depois que se aprende. Ao longodo livro, faremos o deploy de um site em produção para o provedor Heroku.

Uma alternativa para hospedar uma aplicação Node.js é fazer tudo você mesmoem um servidor dedicado, instalando nele tudo o que precisa. Mas a administraçãode um servidor de produção merece todo um outro livro! Além disso, emborase possa substituir qualquer um dos outros componentes por tecnologias alter-

nativas, se retirarmos o Node.js da equação, todo o resto da pilha precisaria sersubstituído também!

1.2.1 JavaScript: a única linguagem em todo o stack

Uma das razões mais importantes para escolher o Node.js é que 100% do códigoda aplicação será escrito em uma linguagem familiar a todos os desenvolvedoresweb: o JavaScript. Até agora, se alguém quisesse se tornar um desenvolvedor

full-stack, deveria ser proficiente em, pelo menos, duas linguagens: JavaScript nofront-end e alguma outra coisa no back-end, como PHP ou Ruby.



MEAN Definitivo26

A tentativa da Microsoft de colocar JavaScript no back-end

No final da década de 1990 a Microsoft lançou a tecnologia Active Server Pages(conhecida hoje como Classic ASP). O código em ASP poderia ser escrito tantoem VBScript como em JavaScript, mas a versão JavaScript nunca decolou. Issose deveu grandemente ao fato de que, à época, muitas pessoas programavam emVisual Basic, cuja sintaxe era muito parecida. A maioria dos livros e tutoriais nainternet concentrava-se em VBScript, o que levou a um efeito “bola de neve” quea tornaria a linguagem padrão do Classic ASP.

Com o lançamento do Node.js é possível alavancar o conhecimento que o progra-mador já possui em JavaScript para usar no servidor. Uma das coisas mais difíceisao se aprender uma nova tecnologia como essa é aprender a linguagem – mas se

já souber um pouco de JavaScript, já está um passo à frente!

É claro: há uma curva de aprendizado para se lidar com o Node.js, mesmo que já tenhamos experiência em JavaScript no front-end. Os desafios e obstáculos daprogramação do back-end são diferentes daqueles encontrados no front-end, maso desenvolvedor iria encontrá-los independentemente da tecnologia usada. No

front-end, o grande problema é fazer tudo funcionar do mesmo jeito em diferentesnavegadores em diferentes plataformas e em diferentes dispositivos. No servidor, oenfoque maior recai no fluxo de código para assegurar que nada fique congeladoe que os recursos do servidor sejam usados com eficiência, sem desperdícios.

1.2.2 Rápido, eficiente e escalável

Outra razão da popularidade do Node.js é que, quando programado de formacorreta, é extremamente rápido e usa com bastante eficiência os recursos do siste-ma. Isso permite que a aplicação em Node.js possa atender mais usuários usandomenos recursos do servidor. Os empresários adoram essa parte, pois podem usaro Node.js para reduzir seus custos mesmo em larga escala.

Mas como ele faz isso? O Node.js é econômico nos recursos de sistema porque ésinglethread, enquanto os web servers tradicionais são multithread. Vamos ver oque isso significa, começando com o método tradicional multithread.




SERVIDOR WEB TRADICIONAL MULTITHREAD

Muitos dos servidores web atuais, especialmente os mais usados, são multithread,incluindo o Apache e o IIS. Isso significa que para cada novo visitante (ou sessão)é criada uma nova “thread” em separado. Normalmente, cada thread pega para sideterminada quantidade de RAM, por volta de 8 MB.

Façamos uma analogia. Imagine duas pessoas entrando num banco. Cada umaquer resolver o seu problema bancário. Em um modelo multithread cada umdeles vai para um caixa diferente, que, por sua vez, vai resolver o problema ime-diatamente (veja a figura 1.3).

Simon

Deposite $500 na poupança.Qual é o meu saldo? Saque $100.

Seu saldoé $5.000.

Aqui estãoseus $100.

Caixa 1

Sally

Caixa 2

Vai atéo cofre.

Depositadinheiro.

Verificadados da

conta-corrente.

Retiradinheiro da gaveta

do caixa.

Verificao saldo.

Figura 1.3 – Exemplo de uma abordagem multithread: os correntistas usam recursosseparados. Os correntistas e seus recursos dedicados não têm ciência ou contato com

os outros correntistas e recursos.

Como podemos ver na figura 1.3, Simon vai ao caixa 1 e Sally ao caixa 2. Nenhumdos dois sabe o que o outro está fazendo, nem suas ações têm impacto na operaçãodo outro. O caixa 1 lida com Simon durante toda a transação, e mais ninguém.

Da mesma forma, Sally é atendida exclusivamente pelo caixa 2.



MEAN Definitivo28

Esse modelo funciona muito bem desde que existam caixas suficientes paraatender todo mundo. Quando o banco está cheio e os clientes são em númeromaior que os caixas disponíveis, o serviço fica mais lento, filas se formam e ocliente tem que esperar. Talvez os bancos não se importem muito com isso, pois

parecem felizes em fazê-lo esperar em uma fila. Mas o mesmo não se pode dizerde website. Se um site estiver demorando muito para carregar, o mais provável éque o visitante vá embora e não volte nunca mais.

Essa é uma das razões porque as máquinas que hospedam servidores web são tãopotentes e têm tanta RAM, mesmo que não precisem disso tudo 90% do tempo.O hardware é configurado de tal forma a estar preparado para os picos de tráfego,não a média. De volta à analogia do banco, é como se os banqueiros contratassemum exército de atendentes de caixa e colocassem a agência num prédio enorme

só porque dois dias por mês na hora do almoço o banco fica cheio.Obviamente, existe uma maneira melhor. Uma que, por certo, será mais escalável.É aqui que o modelo singlethread vem ao nosso auxílio.

SERVIDOR WEB SINGLETHREAD

Um servidor com o Node.js é singlethread e trabalha de forma diferente. Em vezde dar a cada visitante uma thread única e um contêiner separado de recursos,

todos os visitantes interagem com a mesma thread. Um visitante só interage coma thread (ou vice-versa) quando necessário – ou seja, quando o visitante estásolicitando alguma coisa ou a thread está atendendo ao pedido.

Mais uma vez voltando à analogia do banco, existiria apenas um caixa para aten-der a todos os correntistas. Porém, em vez de atender ao pedido de cada clientedo início ao fim, o caixa delega qualquer tarefa que consuma muito tempo parao pessoal do “escritório no primeiro andar” e já começa a trabalhar no pedidodo próximo cliente. A figura 1.4 ilustra como isso funcionaria, usando as mesmas

duas solicitações de nosso exemplo multithread.No modelo singlethread mostrado na figura 1.4, Sally e Simon pediram ao mesmoatendente para fazer suas transações. Entretanto, em vez de executar cada transaçãocompletamente, do começo ao fim, o atendente pega a primeira solicitação e a de-lega à pessoa que cuida desse tipo de transação, depois pega a segunda solicitaçãoe faz a mesma coisa. Quando o atendente é informado de que alguma transaçãofoi finalizada, repassa o resultado diretamente ao cliente que a requisitou.




Simon

Gerente de saques

Gerente de depósitos Sally

Caixa

Retira$100.Vai até o cofre.

Deposita $500.Verifica o saldo.

Deposite $500 na poupança.Qual é o meu saldo?

Saque $100.

Seu saldoé $5.000.

Aqui estãoseus $100.

Figura 1.4 – Exemplo do modelo singlethread: os clientes usam o mesmo recursocentral. Este precisa ser muito disciplinado para evitar que as transações de um

correntista afetem as dos demais.

Código blocante e código não blocante

Com o modelo singlethread, é importante lembrar que todos os usuários fazemuso do mesmo processo central. Para manter constante o fluxo de funcionamento,é preciso certificar-se de que nada no código causará atrasos, bloqueando outra

operação. Um exemplo: se o atendente tiver que ir até o cofre para depositar odinheiro de Simon, a Sally terá que esperar até que ele volte para atender aopedido dela.

Do mesmo modo, se o processo central for responsável por ler cada arquivoestático (como um arquivo CSS, JavaScript ou imagens) ele não será capaz deatender ao próximo pedido, bloqueando o fluxo. Outra tarefa que comumentebloqueia o fluxo são as interações com o banco de dados. Se o processo centraltiver que chamar o banco de dados a cada transação, não será capaz de fazer mais

nada durante um longo tempo.



MEAN Definitivo30

Portanto, para que o modelo singlethread funcione é necessário que o códigoseja não blocante (ou sem bloqueio). Conseguimos isso facilmente programandoas ações blocantes para rodarem de forma assíncrona, evitando que bloqueiemo fluxo do processo principal.

Embora haja apenas um atendente de caixa, nenhum dos visitantes sabe da exis-tência do outro, e a transação de nenhum deles sofre impacto pelas transações dosdemais. Esse modelo assegura que o banco não precisa de um número monstruosode atendentes de caixa. Esse modelo não é infinitamente escalonável, obviamente,mas é muito mais eficiente. É possível fazer mais com menos recursos. Isso nãosignifica que o administrador nunca tenha que adicionar novos recursos.

Esse modelo em particular é possível no Node.js devido à capacidade assíncronado JavaScript – e o veremos em ação fazendo isso ao longo do livro. Recomenda-mos estudar com atenção o apêndice D para saber do que o JavaScript é capaz,especialmente a seção sobre callbacks.

1.2.3 Usando pacotes prontos com o npm

O npm é um gerenciador de pacotes de software que é instalado junto com o

Node.js. O npm permite baixar e instalar módulos do Node.js para estender afuncionalidade da aplicação. No momento em que escrevo estas linhas, existemmais de 46 mil pacotes disponíveis pelo npm, o que mostra a quantidade absurdade conhecimento e experiência que se pode trazer para dentro da aplicação.

Os pacotes no npm são bastante variados no que entregam. Usaremos algunsdeles por todo o livro para fazer com que o framework e o banco de dados usadosna aplicação suportem schemas. Outros exemplos: bibliotecas auxiliares como oUnderscore, frameworks de teste como o Mocha e outros utilitários como o Colors,

que permite aqueles arquivos de log bem coloridos no Node.js.

Estudaremos o npm mais a fundo no capítulo 3, quando começaremos a construirnossa aplicação.

O Node.js é extremamente poderoso e flexível – você já deve ter percebido – masisso não significa que ele vai facilitar a criação de um site ou aplicação web. Paraisso foi criado o Express, que “dá uma mão” para navegar pela complexidade doNode.js. O Express é instalado pelo npm.




1.3 Express: o FrameworkO Express é o E do MEAN. Como o Node.js é uma plataforma, não determinacomo ele mesmo deve ser configurado ou usado. Essa, aliás, é uma das suas gran-

des vantagens. Porém, ao criar sites e aplicações web, há algumas tarefas comunsque são necessárias o tempo todo. O Express é um framework para aplicaçõesweb que funciona em cima do Node.js e foi projetado para se desincumbir dessastarefas de uma forma reproduzível e muito bem testada.

1.3.1 Facilitando a configuração do servidor

Como já descobrimos, o Node.js é uma plataforma, não um servidor. Isso permiteque o programador faça bom uso de sua criatividade e configure o servidor parafazer coisas que outros servidores não conseguem. Por outro lado, colocar um sitebásico no ar não é nada fácil.

O Express abstrai essa dificuldade ao configurar um servidor web que fique es-perando solicitações dos navegadores e retorne respostas relevantes. Além disso, oExpress também define uma estrutura de diretórios. Uma das pastas é usada paraservir páginas estáticas de forma não blocante – a última coisa que queremos é quea aplicação tenha que esperar porque alguém solicitou um arquivo CSS! É possívelconfigurar isso manualmente no Node.js, mas o Express já faz isso por você.

1.3.2 Conectando URLs e respostas

Um dos grandes recursos do Express é oferecer uma interface simples para enca-minhar determinado URL entrante a um trecho específico de código. Se esse trechovai retornar uma página HTML estática, ler de um banco de dados ou escrevernesse mesmo banco não interessa muito. A interface é simples e consistente.

O que o Express faz é abstrair uma parte da complexidade de fazer essas coisasdiretamente no Node.js, para que o programador possa deixar de se preocuparcom isso e produzir um código em menos tempo e mais fácil de manter.

1.3.3 Views: respostas em HTML

Com toda certeza, a maioria das respostas a requisições dos navegadores deve serrespondida com algum tipo de HTML. Já não deve ser surpresa para ninguémque o Express torna isso muito mais fácil que implementar essas respostas dire-tamente no Node.js.



MEAN Definitivo32

O Express oferece suporte a uma grande quantidade de engines de template,o que torna fácil construir páginas HTML de forma inteligente e empregandocomponentes reutilizáveis bem como dados dinâmicos na aplicação. O Expresscompila tudo isso em HTML e devolve ao navegador.

1.3.4 Lembrando dos visitantes: controle de sessão

Sendo singlethread, o Node.js não consegue se lembrar do visitante quando passade uma requisição para a próxima na fila. Ele não tem uma área na RAM separadapara cada sessão. Pelo contrário, a única coisa que o Node.js vê é uma série de re-quisições HTTP. O HTTP é um protocolo que não tem controle de estado, portantonão existe nele o conceito de armazenar o estado de uma sessão. Assim, é difícil

criar uma experiência personalizada no Node.js, ou mesmo providenciar uma áreasegura na qual o usuário possa “logar-se” – fazer login não faz muito sentido se osite vai esquecer de você no próximo clique. O Node.js não faz, mas é óbvio que vocêpode arregaçar as mangas e desenvolver isso você mesmo, com seu próprio código.

Ou então (adivinha!) o Express pode fazer isso por você! Ele já tem suporte nativoa sessões, possibilitando a identificação de cada usuário ao longo das páginas emque ele navega. Obrigado, Express!

Uma camada acima do Node.js em nossa pilha MEAN, o Express é realmente

uma “mão na roda” e um belo ponto de partida para se construir aplicações web.Ele abstrai um sem-número de complexidades e tarefas repetitivas com as quaisa maioria de nós não precisa – nem quer! – ficar se preocupando. Nós queremosconstruir aplicações web!

1.4 MongoDB: o Banco de Dados

A possibilidade de reter e usar dados é vital para a maioria das aplicações. NoMEAN, o banco de dados é o MongoDB, o M de nossa pilha. O MongoDBaninha-se confortavelmente na pilha. Assim como o Node.js, ele é conhecido porser rápido e escalonável.

1.4.1 Bancos de dados: relacionais versus documentais

Quem já usou um banco de dados relacional, ou mesmo uma planilha, estáacostumado com o conceito de linhas e colunas em uma tabela. Tipicamente,uma coluna define o nome do campo e o tipo de dados que vai nesse campo, e a




linha define um registro, ou seja, a coleção de campos que forma uma entidadede dados no banco. A tabela 1.1 mostra um exemplo.

Tabela 1.1 – Como as linhas e colunas se parecem em uma tabela de um banco dedados relacional

firstName middleName lastName maidenName nickname

Simon David Holmes Si

Sally June Panayiotou

Rebecca Norman Holmes Bec

O MongoDB não é assim! O MongoDB é um banco de dados orientado a documen-tos, ou documental. O conceito de linhas (ou seja, de registros) ainda existe, mas

as colunas sumiram do mapa. Em vez de uma coluna definir o que deve existir emuma linha, cada linha (ou seja, cada registro) é um documento separado, e essedocumento não só armazena os dados como também define cada campo. Veja natabela 1.2 como uma coleção de documentos poderia ser listada. Observe que olayout indentado que mostramos aqui serve apenas para melhorar a legibilidadepara nós, humanos limitados, não sendo, portanto, uma visualização em colunas.

Tabela 1.2 – Cada documento em um banco de dados documental define e armazenaos dados, sem qualquer ordenação particular

firstName: “Simon” middleName: “David” lastName: “Holmes” nickname: “Si”

lastName: “Panayiotou” middleName: “June” firstName: “Sally”

maidenName: “Holmes” firstName: “Rebecca” lastName: “Norman” nickname: “Bec”

Essa forma bem menos estruturada de armazenar dados significa que nossacoleção de documentos pode ter uma variedade grande de dados dentro deles.Vejamos um exemplo de documento do MongoDB para ter uma ideia melhor do

que estamos falando.

1.4.2 Documentos do MongoDB: o armazém de dados do JavaScript

O MongoDB armazena documentos em um formato chamado BSON, que é umaversão binária do JSON (JavaScript Serialized Object Notation, ou Notação Seria-lizada de Objetos do JavaScript). Não se preocupe, por enquanto, se não souberabsolutamente nada de JSON há uma seção só sobre ele no já famoso apêndice D.Resumidamente, o JSON é o jeito de o JavaScript armazenar dados – e é por issomesmo que o MongoDB se encaixa tão bem no MEAN, que é 100% JavaScript!



MEAN Definitivo34

O trecho de código a seguir mostra um exemplo de documento bem simples doMongoDB:

{

"rstName" : "Simon",

"lastName" : "Holmes",

_id : ObjectId("52279effc62ca8b0c1000007")

}

Mesmo quem não conhece nada de JSON provavelmente vai entender que estedocumento armazena meu nome e sobrenome, Simon Holmes! Portanto, em vezdo documento guardar uma coleção de dados que corresponde a um conjuntode colunas, o que o documento guarda é um par conhecido como chave:valor(key:value). Isso torna o documento útil por si só, já que não só guarda os dadoscomo também os define.

Uma palavrinha sobre o _id, que você deve ter percebido no exemplo anterior.A entidade _id é um identificador único que o MongoDB associará a cada novodocumento que for criado.

Olharemos com mais cuidado os documentos do MongoDB no capítulo 5, quandocomeçaremos a popular nosso banco de dados para a nossa aplicação.

1.4.3 Mais que simplesmente um banco de dados documental

O MongoDB se destaca de outros bancos de dados orientados a documento porseu suporte à indexação secundária e solicitações de dados (queries) muito maisricas. Isso significa que é possível criar índices levando em conta não só o campoúnico de indexação, mas qualquer campo. Além disso, a velocidade de indexaçãoé muito maior, se comparada à de outros bancos. Podemos criar queries realmentecomplexas contra um banco de dados MongoDB – não no nível dos monstruosos

comandos SQL cheios de Joins, mas mais que poderoso para a maioria dos casos.Ao construir uma aplicação ao longo do livro, nos divertiremos um bocado comisso, e começaremos a entender tudo o que o MongoDB pode fazer.

1.4.4 Mas então, para quais usos o MongoDB não é bom?

O MongoDB não é um banco de dados transacional, e não deve ser usado comotal. Um banco de dados transacional pode efetuar um grande número de opera-

ções separadas em uma única transação. Se qualquer uma das operações em uma




transação falhar, a transação toda falha, e nenhuma das operações é completada. OMongoDB não trabalha assim! O MongoDB executará todas as operações de formaindependente. Se uma falhar, falhará sozinha, e as outras operações continuarão.

Isso é importante quando precisamos atualizar múltiplas coleções de documen-

tos de uma vez só. Se estivermos construindo uma loja eletrônica, por exemplo,é preciso certificar-se de que o pagamento foi efetuado e registrado, e que o pe-dido foi marcado como confirmado para ser processado. Nenhum proprietáriode loja online gostaria de descobrir que um cliente já pagou pelo pedido, mas osistema pensa que não e não dispara o processamento da compra e o envio doproduto. Portanto, essas operações precisam, necessariamente, ser amarradas emuma única transação. Claro, a estrutura do banco de dados no MongoDB podeser especialmente criada para permitir que essa checagem de integridade seja

feita para uma coleção de dados, ou então o programador pode incluir centenasde verificações e cópias de segurança no próprio código da aplicação – ou, então,você pode simplesmente escolher um banco de dados transacional e não se pre-ocupar com nada disso.

1.4.5 Mongoose: modelação de dados e muito mais

A flexibilidade do MongoDB sobre o que armazenar nos documentos é um de

seus pontos fortes. Mas a maioria das aplicações precisa de alguma estrutura maisrígida para seus dados. Observe que é a aplicação que precisa da estrutura maisrígida, e não o banco de dados. Portanto, onde é que faz mais sentido definir aestrutura dos dados da aplicação? Claro, na própria aplicação!

Para isso, a empresa por trás do MongoDB criou o Mongoose. Em suas própriaspalavras, o Mongoose oferece uma “modelação de dados elegante ao MongoDBpara uso no Node.js” (http://mongoosejs.com/ ).

O QUE É MODELAGEM DE DADOS?Modelagem de dados, no contexto do Mongoose e do MongoDB, significa definiro que os dados podem representar em um documento, e o que os dados obriga-

toriamente devem representar em um documento. Quando informações sobre ousuário são armazenadas, podemos definir que queremos a possibilidade degravar o primeiro nome, o sobrenome, o email e o telefone. Mas o que a aplica-ção necessariamente precisa é apenas do nome e email, e o email precisa ser único.Todo o resto é opcional. Esse tipo de definição é configurado no que chamamos

de schema, que é usado como base para o modelo de dados.



MEAN Definitivo36

O QUE MAIS O MONGOOSE OFERECE?

Além de modelagem de dados, o Mongoose adiciona uma camada extra de recur-sos ao MongoDB que são bastante úteis para criar aplicações web. O Mongoosetorna fácil gerenciar as conexões ao banco de dados no MongoDB, bem comopara gravar e ler dados. Mais adiante veremos como isso funciona e sujaremos asmãos na prática com o Mongoose. Também veremos como ele permite adicionarrecursos de validação de dados ao schema, fazendo com que apenas dados válidossejam salvos no banco.

O MongoDB é a melhor escolha de banco de dados para a maioria das aplicaçõesweb porque está no ponto de equilíbrio entre a velocidade dos bancos de dadospuramente documentais e o poder dos bancos de dados relacionais. O fato de osdados serem armazenados em JSON torna-o perfeito para ser o armazém do MEAN.

1.5 AngularJS: o framework para o front-endO AngularJS é o A do MEAN. Em termos simples, o AngularJS é um framework

JavaScript para trabalhar com dados diretamente no front-end.

É possível usar apenas os componentes que já vimos – Node.js, Express eMongoDB – para criar uma aplicação web com suporte a banco de dados per-

feitamente funcional e completa. Faremos isso, aliás, neste livro. No entanto, épossível colocar glacê no bolo quando adicionamos o AngularJS ao nosso stack.

A maneira tradicional de fazer as coisas é processar todos os dados e a lógica daaplicação no servidor, que então repassa o resultado formatado em HTML para onavegador. O AngularJS permite mover parte (ou mesmo todo) do processamentoe da lógica do sistema para o navegador, às vezes deixando o servidor apenas paraacessar o banco de dados. Veremos algo parecido no momento em que discutir-mos o que é uma “vinculação de dados de mão dupla”, mas primeiro precisamos

resolver a questão do porquê escolhemos o AngularJS em vez do jQuery, que ésem sombra de dúvida a biblioteca de front-end para JavaScript mais famosa,mais usada e mais festejada.

1.5.1 No ringue: jQuery versus AngularJS

Se o leitor estiver familiarizado com o jQuery, deve estar se perguntando se oAngularJS trabalha da mesma maneira. A resposta curta é: não, não mesmo!

O jQuery normalmente é usado no código de uma página web para adicionar




interatividade, depois que o HTML foi enviado ao navegador e o DocumentObject Model (DOM) estiver completamente carregado. O AngularJS já começaa atuar alguns passos antes disso, ajudando a montar o próprio código HTMLbaseado nos dados obtidos.

Além disso, o jQuery é uma biblioteca e, como tal, oferece um conjunto de recursosque você pode (ou não) usar da maneira que bem entender. Já o AngularJS é oque se conhece como um framework dogmático (do inglês opinionated , que tam-bém pode ser traduzido como teimoso, obstinado ou cheio de razão). É dogmáticono sentido de forçar o programador a aceitar sua opinião e usá-lo estritamenteda forma como ele acha que deve ser usado.

Como já dissemos, o AngularJS ajuda a montar o HTML que será enviado aonavegador, baseando-se nos dados fornecidos, mas faz muito mais que isso. Eletambém atualiza o HTML automaticamente se os dados mudam, e também atu-aliza os dados, caso o HTML mude. Isso é conhecido como vinculação de dadosde mão dupla, conceito que veremos agora.

1.5.2 Vinculação de dados de mão dupla: trabalhando com os dados na página

Para entender a vinculação de dados de mão dupla (two-way data binding)começaremos examinando o método tradicional: a vinculação de dados de mão

única. O one-way data binding é o que temos quando usamos apenas Node.js,Express e MongoDB. O Node.js recupera os dados armazenados no MongoDB, eo Express usa um template para compilar os dados em uma página HTML queserá enviada ao servidor, e este, por sua vez, a enviará ao navegador. O processoé ilustrado na figura 1.5.

Esse método de mão única é a base para a maioria dos sites que usam bancos dedados. Por esse método, grande parte do trabalho pesado é feito pelo servidor,enquanto ao navegador é relegado apenas o trabalho de renderizar o HTML e

promover qualquer tipo de interatividade programada no JavaScript.

O método two-way data binding é diferente. Primeiro, o template e os dados sãomandados separadamente ao navegador. O próprio navegador compila o templateem uma visão e os dados em um modelo de dados. A diferença marcante é o fatode que a visão é “ao vivo”. A visão é intrinsecamente ligada ao modelo de dados,portanto, se o modelo mudar, a visão muda instantaneamente. De modo inverso,se a visão for alterada, o modelo também muda. O método two-way binding estáilustrado na figura 1.6.



MEAN Definitivo38

Modelo

de dados

Visão

Compilação

Template

Navegador Servidor

Figura 1.5 – No método one-way data binding, o modelo e o template são compiladosno servidor antes de serem enviados ao navegador.

Template

DadosModelo

de dados

Modelo

atualiza

visão

Visão

atualiza

modelo

Visão

Compilação

Processamento

Navegador Servidor

Figura 1.6 – Two-way data binding – o modelo de dados e a visão são processados nonavegador e entrelaçados de tal forma que um consegue instantaneamente atualizar

o outro.

Como seu armazém de dados em geral será exposto em uma API, em vez de seracoplado diretamente à aplicação, normalmente há algum processamento envol-vido antes de adicioná-lo ao modelo. É preciso certificar-se, portanto, que se estáligando os dados corretos e mais relevantes à visão.

Na parte III do livro, experimentaremos essa ação. Nesse caso, é preciso ver paracrer – e, posso garantir, você não se decepcionará.




1.5.3 Usando o AngularJS para carregar novas páginas

Uma das coisas para as quais o AngularJS foi especialmente projetado é o que sechama de single- page application (SPA), ou aplicação de uma única página. Em termospráticos, um SPA roda tudo dentro do navegador, e nunca faz uma recarga completada página. O que isso significa é que toda a lógica da aplicação, processamento dedados, fluxo do usuário e engine de template é administrado no próprio navegador.

Pense no Gmail – o exemplo clássico de SPA. Diferentes visões e conteúdo (ouseja, dados) são mostrados na página, mas a página mesmo jamais é recarregada.

Essa técnica pode reduzir drasticamente a quantidade de recursos utilizados noservidor – o que o Gmail faz é colocar nas costas do usuário (ou melhor, do na-vegador do usuário) todo o trabalho pesado. O que o servidor faz é, basicamente,

enviar páginas estáticas e dados quando solicitado.A experiência do usuário também será bem melhor ao usar esse expediente. Umavez que a aplicação já foi completamente carregada no navegador do cliente noprimeiro acesso, as chamadas ao servidor diminuirão muito em número e volumede dados, reduzindo a latência.

Ok, tudo isso soa maravilhoso, quase celestial. Onde está a pegadinha? Certa-mente, há um preço a pagar por tudo isso. Se não fosse assim, tudo seria feito emAngularJS hoje em dia, não acha?

1.5.4 O AngularJS e suas pegadinhas...

Apesar de seus inúmeros benefícios, o AngularJS pode não ser indicado para todoe qualquer site. Às vezes, bibliotecas de front-end como o jQuery são melhorespara aprimoramentos progressivos no site. A ideia é que seu site deva funcionarperfeitamente sem o JavaScript, e este só será usado para tornar a experiênciado usuário melhor. Esse não é o caso do AngularJS e, na verdade, de nenhum

framework SPA. O AngularJS usa o JavaScript para renderizar o HTML a partirdos templates e dos dados, portanto, se seu navegador não suporta JavaScript, ouse existir um bug no código, o site simplesmente não rodará.

A dependência do JavaScript para montar uma página HTML também causa pro-blemas com mecanismos de busca. Quando um mecanismo de busca rastreia seusite, ele não vai rodar nenhum código JavaScript, apenas conteúdo em HTML. Sóque, com o AngularJS, a única coisa que existe antes do JavaScript fazer o que foiprogramado para fazer é um template vazio enviado pelo servidor. Se você quer



MEAN Definitivo40

que seu conteúdo e dados sejam indexados pelos mecanismos de busca, talvez oAngularJS não seja o componente mais apropriado para seu projeto.

Existem maneiras de combater esse problema em SPAs – resumidamente, é pre-ciso que o servidor compile uma parte do HTML da página, deixando apenas o

estritamente necessário para o AngularJS montar – mas se você não tem nenhuma

necessidade de entrar nessa briga, eu recomendo com veemência evitá-la.

Uma das coisas que se pode fazer é usar o AngularJS para algumas páginas e nãopara outras. Não há nada errado em usar o AngularJS seletivamente no projeto. Épossível ter uma aplicação interativa e rica em dados em apenas uma seção de seusite – e usar o AngularJS só nela. Por exemplo, é possível ter um blog ou algumaspáginas de marketing em volta da sua aplicação. Essas páginas não precisam serconstruídas em AngularJS, já que serão mais bem servidas pelo jeito tradicionalde fazer as coisas – ou seja, tudo pelo servidor, no back-end. Portanto, parte dosite é servido pelo trio Node.js, Express e MongoDB, enquanto outra parte temos três e mais o AngularJS fazendo seu papel.

Essa abordagem flexível é um dos aspectos mais poderosos do MEAN. Com umsó stack podemos atingir uma variedade fabulosa de objetivos.

1.6 Elenco de apoioO MEAN proporciona tudo o que se precisa para criar aplicações web interativase ricas em dados, mas nada impede de se usar outras tecnologias para melhoraro cenário. Por exemplo, podemos empregar o Bootstrap do Twitter para criar umabela interface com o usuário. O famoso Git facilita e muito a administração docódigo, e o Heroku pode ajudar ao hospedar a aplicação em um URL válido. Noscapítulos finais, veremos como incorporá-los ao MEAN. Mas, por uma questãode completude, os descreveremos brevemente nas linhas a seguir.

1.6.1 Bootstrap: interfaces de usuário bonitas, graças ao Twitter

Neste livro usaremos o Bootstrap, um projeto do Twitter para criar designs res-ponsivos com um mínimo de esforço. Ele não é de forma alguma essencial aostack, e se sua aplicação estiver sendo montada sobre um design específico ouum HTML estático já existente, é provável que nem vá precisar do Bootstrap. Mascomo nós criaremos a nossa no estilo “prototipagem rápida”, queremos passar da

ideia à aplicação pronta sem influências externas.




O Bootstrap é um framework de CSS para o front-end que oferece um verdadeirotesouro de recursos para criar uma interface de usuário impressionante. Dentreesses recursos, o Bootstrap fornece um grid responsivo, estilos-padrão para amaioria dos componentes da interface e a possibilidade de alterar a aparência

do site com temas.

GRID RESPONSIVO

Em um layout responsivo, uma única página HTML redimensiona-se sozinhaem diferentes dispositivos. Isso é feito pela detecção da resolução de tela em vezde tentar descobrir qual é o dispositivo. O Bootstrap rastreia quatro diferentespixels no layout, que correspondem aos formatos de tela de smartphones, tablets,laptops e monitores externos. Se o programador planejar com antecedência como

organizar as classes no CSS e HTML, é possível usar a mesma página HTML paramostrar o mesmo conteúdo em diferentes layouts que são escolhidos de acordocom o tamanho da tela.

CLASSES CSS E COMPONENTES HTML

O Bootstrap vem com um conjunto de classes CSS predefinidas que podem criarcomponentes visuais úteis. Dentre eles, cabeçalhos de página, contêineres de men-sagens, rótulos e medalhas, listas estilizadas… a lista é grande! O framework foimuito bem projetado e realmente ajuda a construir uma aplicação rapidamente,sem ter que perder muito tempo com o layout HTML e os estilos CSS.

Neste livro não veremos o Bootstrap a fundo, mas para cada recurso que utilizar-mos teremos uma breve explicação.

TEMAS

O Bootstrap tem uma aparência-padrão muito agradável e realmente bonita.

Só que é tão comumente utilizado que seu site pode acabar se parecendo commilhares de outros. Por isso mesmo, é possível baixar temas para o Bootstrapque dão um gostinho diferente para a aplicação. Baixar um tema normalmenteé tão simples quanto substituir o arquivo CSS do Bootstrap. Usaremos um temagratuito neste livro para construir nossa aplicação, mas é possível comprar temaspremium para garantir que seu site seja único.



MEAN Definitivo42

1.6.2 Controle de código-fonte com o Git

Salvar o código-fonte em seu próprio computador ou em um drive de rede é óti-mo e funciona muito bem, mas essa prática só salva a última versão do código.Ela também só permite que você, ou quem estiver pendurado na sua rede, acesseesses arquivos.

O Git é um sistema distribuído de controle de versão combinado com um sistemade administração de código. Isso significa que muitas pessoas podem trabalharno mesmo código ao mesmo tempo em diferentes computadores e redes. As alte-rações e novas versões de cada um podem ser combinadas, e todas as alteraçõesficam registradas para posterior análise e auditoria. Caso algo dê errado, é possívelretornar a uma versão anterior que funcione bem.

MODO DE USAR

O Git é usado tipicamente na linha de comando, embora existam algumas in-terfaces gráficas para facilitar a operação em Windows e no Mac. Ao longo destelivro usaremos a linha de comando, unicamente. O Git é muito poderoso dessamaneira, e nós vamos apenas arranhar a superfície no desenrolar de nossa apli-cação exemplo – mas tudo o que fizermos será comentado e explicado.

Tipicamente, o Git tem um repositório local na máquina do programador e um

repositório remoto, chamado de repositório-mestre, que centraliza o código. Orepositório-mestre pode ser hospedado em serviços especializados como o GitHubou o BitBucket. É possível baixar o conteúdo do repositório central para o local,ou vice-versa, do local para o remoto. Todas essas operações são realmente fáceisde se fazer pela linha de comando e tanto o GitHub como o BitBucket ofereceminterfaces web para que se possa ter um controle visual de tudo o que é enviado.

E PARA QUE USAREMOS O GIT EM NOSSO PROJETO?

Neste livro, usaremos o Git por duas razões.

Primeiro, o código-fonte exemplo do livro está armazenado no GitHub, comdiferentes branches para os vários milestones (marcos que indicam objetivosatingidos) dos diferentes capítulos. Há a possibilidade de clonar tanto o masterquanto qualquer um dos branches para usar o código correspondente.




Em segundo lugar, usaremos o Git como o método de deploy, ou seja, de envio daaplicação pronta para um ambiente de produção, de forma que o mundo possausá-lo. Para a hospedagem, usaremos o serviço Heroku.

1.6.3 Hospedando aplicações no Heroku

Hospedar uma aplicação Node.js pode ser complicado, mas não precisa ser. Muitosdos provedores de hospedagem tradicionais não deram muita atenção ao interessegerado pelo Node.js. Alguns deles instalarão o Node.js para você, de forma que suasaplicações possam rodar, mas os servidores não foram configurados para garantiros requisitos mínimos exigidos pelo Node.js. Para rodar uma aplicação em Node.jscom sucesso é preciso ou um servidor que tenha sido montado com isso em mente,

ou um provedor PaaS, cujo propósito central é justamente hospedar o Node.js.Neste livro usaremos a segunda opção. Nosso provedor será o Heroku(www.heroku.com), escolhido por seus bons atributos. O Heroku é um dos maioresprovedores de aplicações Node.js do mundo, e oferece um excelente plano gratuitodo qual faremos bom uso.

As aplicações hospedadas no Heroku são, essencialmente, repositórios Git – o quetorna o processo de publicação e deploy extremamente simples. Depois de tudoconfigurado, basta um único (e bem simples) comando para que sua aplicação

seja imediatamente publicada e já saia funcionando:

$ git push heroku master

Eu não disse que isso não precisava ser complicado?

1.7 Juntando tudo em um exemplo práticoComo já mencionamos algumas vezes, no decorrer do livro construiremos umaaplicação funcional em MEAN. Isso nos dará uma bela base em cada uma dastecnologias que compõem o stack e um entendimento abrangente de como elasse encaixam entre si.



MEAN Definitivo44

1.7.1 O que nossa aplicação exemplo faz?

A esta altura, você deve estar curioso para saber o que é essa aplicação exemplo deque tanto falamos nas páginas anteriores. Chega de suspense: nossa aplicação seráchamada de Loc8r (lê-se “locater” ou, em português, “localizador”). O Loc8r listaráos lugares próximos com WiFi público para que as pessoas possam visitar e usar.Chamaremos esses locais de “estabelecimentos comerciais com WiFi” no decorrerdo livro, para poder usar a palavra “locais” em outros contextos. A aplicação tambémmostrará os serviços e estrutura disponíveis (banheiro, lanches etc.), horário defuncionamento, um sistema de classificação por nota e um mapa para cada um doslocais. Os usuários serão capazes de criar uma conta para envio de notas e resenhas.

Essa aplicação tem um pé no mundo real. Aplicações baseadas em localização

não são nenhuma novidade, e vêm em diferentes formatos e cores. Dois exemplosextremamente populares são o Facebook e o Foursquare, que listam tudo o quepodem em suas páginas de Check In e usam dados dos próprios usuários (o cha-mado crowdsourcing) para atualizar o banco de dados com novos locais e maisinformação. O UrbanSpoon ajuda as pessoas a encontrar lugares para comer, combusca refinada por tipo de culinária ou faixa de preço. Mesmo empresas como oStarbucks e o McDonald’s apresentam seções em seus aplicativos que permitemaos clientes encontrar a loja mais próxima.

DADOS REAIS OU FALSOS?

Para o Locat8r usaremos um conjunto de dados falsos, mas sempre será possívelobter dados verdadeiros depois, seja de um provedor de dados, ou via crowdsource,ou qualquer outra fonte externa. Para prototipação rápida, normalmente usardados falsos (e conhecidos) para a primeira versão privada acelera o processo.

PRODUTO FINAL

Usaremos todas as camadas do MEAN para criar o Loc8r, incluindo o Bootstrapdo Twitter para criar um layout responsivo. A figura 1.7 mostra algumas capturasde tela do que construiremos ao longo do livro.




Figura 1.7 – O Loc8r é a aplicação que construiremos ao longo deste livro. Ele seráapresentado de forma diferente em dispositivos diversos, mostrando uma lista de

locais e detalhes sobre cada um e permitindo que o visitante dê uma nota e escrevaresenhas a seu respeito.

1.7.2 Como os componentes do MEAN trabalham em conjunto

Ao final do livro, o leitor terá uma aplicação rodando no stack MEAN e usandoo JavaScript do começo ao fim. O MongoDB grava dados em um formato binárioderivado do JSON que, através do Mongoose, pode ser consultado como JSONpuro. O framework Express fica logo acima do Node.js, no qual o código é todoescrito em JavaScript. No front-end temos o AngularJS, que também é JavaScript.A figura 1.8 ilustra o fluxo e as conexões entre eles.

Exploraremos as várias maneiras de se arquitetar aplicações no MEAN e descre-

veremos a forma como construiremos o Locat8r no capítulo 2.



MEAN Definitivo46

Banco

de dados

Formato de dados:

BSON

MongoDB

Formato de

dados exposto:

JSON

Mongoose

Servidor da aplicação

Linguagem:

JavaScript

Node.js e Express

Formato de dados:

JSON

Front-end

Linguagem:

JavaScript

AngularJS

Formato de dados:

JSON

Figura 1.8 – O JavaScript é a linguagem comum a todos os componentes do MEAN, eo JSON o formato de dados.

1.8 ResumoNeste capítulo vimos:

• as diferentes tecnologias que compõem o stack MEAN;

• MongoDB, a camada de banco de dados;

• Node.js e Express, trabalhando juntos em uma camada como um servidorde aplicações;

• AngularJS, a camada de front-end e vinculação de dados;

• como os componentes do MEAN trabalham juntos;

• algumas maneiras de se estender o MEAN com tecnologias adicionais.

Como o JavaScript é o ator principal em toda a pilha, mais uma vez recomenda-mos que estude antes de mais nada o apêndice D. O apêndice é importante pararefrescar a memória sobre as armadilhas e melhores práticas do JavaScript. Nãodeixe de lê-lo antes de passar para o próximo capítulo!

No capítulo 2, veremos quão flexível é o MEAN e como podemos arquitetar

diferentes soluções para diferentes cenários

mean - exemplo

Documents