quinta-feira, 23 de março de 2017

Hospedagem com o Firebase

O Firebase é uma opção bastante simples de se utilizar, especialmente se você estiver montando MVP ou quer disponibilizar um teste rápido na Web. Com a ideia de ser serverless (facilitar a vida do desenvolvedor em não criar um backend), simplifica-se o desenvolvimento de cenários sem necessidades de recursos além de armazenamento por exemplo.

Toda as funcionalidades da hospedagem estão listadas em Firebase Hosting:

  • Atendimento em uma conexão segura (SSL configurado por padrão, o que já atende em protótipos de Progressive Web Apps)
  • Entrega rápida de conteúdo (por usar SSD e CDN parar entrega ao usuário)
  • Implementação rápida com o uso de  Linha de comando
  • Reversões com um clique, mantendo históricos de atualizações
  • Versão de entrada gratuita, independente de tempo. Para ver mais detalhes veja em Firebase Princing.
  • Importante: Hospedagem limitada a conteúdo estático. Ou seja, nada de rodar sua aplicação web com Node.Js por exemplo

Linha de comando

Os comando do Firebase CLI podem ser conhecidos em Referência da Firebase CLI

Instalando o Firebase CLI:

  1. É necessário ter o Node.Js instalado
  2. Instalar o módulo : npm install -g firebase-tools

Um resumo para colocar um site em produção seria:

  1. firebase init (Cria a aplicação, com perguntas em passo a passa)
    1. Por padrão, a aplicação acessa o um subdiretório public
  2. firebase serve (Inicia um servidor local web, para testar a aplicação)
  3. firebase deploy (Para publicar a aplicação)
    1. É possível utilizar o argumento –only para orientar a configuração direcionada a hosting, database e storage

O Firebase ainda oferece serviços para Armazenamento e Base de Dados.

É simples e não é bala de prata! Se sua aplicação precisa de escalar conheça quem começou com o MVP no Firebase e teve dificuldades depois. Veja o post Reasons Not To Use Firebase e uma boa resposta da pergunta When is Firebase not a good choice? no Quora para entender até quando utilizar o Firebase.

domingo, 19 de março de 2017

Introdução ao Progressive Web Apps

Há uma forte corrente questionando que a utilização de apps em mais cenários que deveria, e uma página web seria mais produtiva. Um bom exemplo é ter que baixar um app para pagar um estacionamento de um shopping que você pode não mais voltar a usar.

A web tem amadurecido no conceito de Progressive Web Apps (PWA), que tem por ideia adicionar funcionalidades de app a uma página web, progressivamente, a medida que o usuário usa o aplicativo. A Udacity disponibilizou o curso Intro to Progressive Web Apps (Web Apps for the Next Billion Users) que ajudou nas informações deste post. A apresentação Progressive web apps with polymer tem números interessantes sobre as característas em criar o PWA.

Por que pensar no Progressive Web Apps?

No caso de estudo o Flipkart(maior e-commerce da Índia), ao combinar o app nativo com sua versão Flipkart Lite, versão em Progressive Web Apps, eles tiveram os seguintes benefícios (Conforme estudo de caso “Flipkart triples time-on-site with Progressive Web App” publicado neste link):

  1. aumento de 70% nas conversões
  2. tempo do usuário no flipkar lite x experiência anterior do Mobile, 3,5 minutos x 70 segundos
  3. 3x mais tempo no site
  4. aumento de 40% no reengajamento
  5. 3x menos uso de dados

Mas o que permite o Web Progressive Web trazer tanto benefício?

Os navegadores estão evoluindo para permitir o uso das funcionalidades abaixo.

Service Worker

  1. Age como um proxy no lado cliente, o que permite fazer cache de arquivos localmente;
  2. Tem uma série de eventos para poder, por exemplo, atualizar o cache;
  3. Pode receber Push Messages, mesmo com o site fechado pelo usuário;

Web App Manifest File

  1. Permite definir como seu Web App aparece para o usuário, podendo fazer um ícone ser instalado pelo usuário no Mobile. Quando isso acontece o site abre em full screen, como um app nativo

Repensar a arquitetura do Site

Não basta utilizar o novo browser, mas deve desenvolver o site de maneira diferente.

  1. Desenvolver como arquitetura de app, com o application shell – que é parecido com o código que se gera para um app nativo. Separa-se o que são os componentes essenciais para o seu app executar offline (Html, Javascript e CSS) do que é dado e muda frequentemente e ainda assim pode ser salvo localmente para acesso offline. Com isso se tem características que há no aplicativo nativo (sem a necessidade de uma loja):
    1. Carregamento instantâneo
    2. Atualizações regulares
  2. Armazenamento offline, que é possível ser feito de três maneiras
    1. Local Storage (Não indicada a utilização)
      1. Vantagens : amplamente implementado em navegadores
      2. Desvantagens: sua api é síncrona e bloqueia a execução do programa, não é transacional (duas escritas no mesmo momento pode perder algo importante)
    2. Cache Storage
      1. Vantagens: fácil de usar, assíncrono e rápido
      2. Desvantagens: não transacional, não utilizado em vários navegadores atualmente
    3. IndexedDB
      1. Vantagens:  rápido, permite armazenar dados complexos, assíncrono e transacional e implementado em vários navegadores
      2. Desvantagem: api feia, que requer muita configuração (Há bibliotecas para amenizar desta forma como o Mozilla localForage e o lovefield do google)

Com a separação de app shell dos dados, a ideia é fazer um http request para os dados, o que faz a primeira leitura ficar um pouco mais lenta. Para amenizar este problema a ideia é injetar os dados, não no html, mas num arquivo separado, que é o app.js. Dessa forma é garantido que haverá a montagem do app e depois é possível de atualizar pelo http request.

É importante lembrar que navegadores não prometem guardar os dados para sempre e por isso é importante enviar os dados críticos para a nuvem assim que possível (se houver dados do usuário que você não deseja perder). Outra vantagem de utilizar o sincronismo com a nuvem é que o usuário logar de outro dispositivo, os dados estarão disponíveis.

Para ver um exemplo de um aplicativo utilizando esta arquitetura, veja o Weather PWA. Não esqueça de abrir o console e ver os logs definidos pelo aplicativo, depois de carregar a primeira vez, adicionar outras cidades para ver a previsão do tempo e finalmente trabalhar offline e ainda assim ver as últimas informações

image

 

Outras referências

Introdução aos Progressive web Apps por Matheus Lima no imasters

Progressive web apps with polymer no SlideShare

Progressive web apps presentation using Reveal.js

domingo, 5 de março de 2017

Padrão de Repositório no C#

O artigo .NET - Apresentando o padrão de projeto Repository do Macoratti faz uma breve explicação do padrão de repositório e apresenta exemplos de códigos c# para implementá-lo.

O vídeo abaixo  Repository Pattern with C# and Entity Framework, Done Right do canal Programming with Mosh faz um detalhamento maior, confrontando ideias encontradas na internet e também foi utilizado como fonte para este post.


Repositório, de acordo com de Martin Fowler, tem por definição:
Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.
Media entre as camadas de domínio e mapeamento de dados usando uma interface tipo coleções para acessar objetos de domínio (Tradução livre do autor do post)

Os benefícios ao usar este padrão são:
  1. Minimiza duplicações de lógicas de consultas(query)
  2. Desacopla sua aplicação de frameworks de persistência. Dessa forma você pode começar com o acesso a dados com o Entity Framework e depois mudar para o Dapper em caso de necessidade de melhor performance (como dito no post  Acesso a Dados e Desempenho)
  3. Deixar o código mais testável

Alguns erros comuns de desenvolvedores

1 - Repositório não deve repetir métodos do banco de dados

Um repositório não deve espelhar métodos de um banco de dados. Por exemplo, a atualização de um objeto deve ser feita apenas atualizando o objeto consultado. A persistência no banco de dados deve ser feita com o Unit Of Work.

O Martin Fowler define o Unit of Work como:
Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.
Mantém uma lista de objetos afetados por uma transação de negócio e coordena a escrita de mudanças e resoluções de problemas de concorrência (Tradução livre do autor do post)
O autor do vídeo defende que se devee evitar o retorno de IQuery no repositório, para forçar a criação de métodos específicos para a busca de dados e ter o benefício número 1 - este padrão não é respeitado no código do Aspnet Boilerplate.  Ele também defende que a definição do Lazy ou Eager Loading também deve ser feita internamente no repositório e exposto a camada de negócio em métodos específicos.

2 - Nem toda aplicação deve usar este padrão

Deve-se tomar o cuidado para não fazer o over engineering (usar mais detalhes de arquitetura que o problema precisa). Se estiver prototipando ou um código que provavelmente não irá para a produção, talvez não precise desse investimento neste padrão.

 Código

O código utilizado no vídeo está disponível neste link para download.
Neste link está documentada a implementação de repositório do Aspnet Boilerplate.


No vídeo também é indicado o livro

Clean Code: A Handbook of Agile Software Craftsmanship do autor Robert C. Martin

quarta-feira, 1 de março de 2017

Configurando o TypeScript com o Angular

Os benefícios de se utilizar o TypeScript foram falados nos posts Introdução ao TypeScript  e Configuração Gulp para trabalhar com TypeScript. Mas configurar o TypeScript com o Angular 1 demanda uma sequência correta de etapas.

O ambiente javascript evoluiu muito nos últimos anos, tanto em relação ao poder quanto à complexidade. Há um discussão sobre o tema muito interessante no podcast  .NET Rocks #1387 JavaScript Development Environments with Cory House. A ideia de ter o ambiente Javascript bastante aberto à diferentes pacotes dá margem para aparecer pacotes oferecendo serviços melhores que os já existentes, mas ao mesmo tempo pode paralisar o desenvolvedor que está se iniciando no ambiente novo – que pode preferir num primeiro momento repetir a escolha de um especialista.

O repositório “Browserify-TypeScript-Angular-Gulp—Boilerplate” do Git fez um excelente Boilerplate (entenda como facilitador para você iniciar seus projetos neste contexto) que além de merecer estrelas, merece um post só sobre ele.

Neste repositório foi configurado vários pacotes, à se destacar:

  • Browserify
  • TypeScript
  • Angular (1)
  • Gulp

Depois do repositório clonado, basta executar os comandos abaixo, conforme readme.md, para baixar as dependências:

npm install 
bower install 
 

O repositório tem dois branches

  1. master com um exemplo de CRUD
  2. no-demo-app” com o bolierplate apenas.

Para executar o CRUD de exemplo, com o Node.js como backend, basta executar:

gulp serve

Configuração Gulp para trabalhar com TypeScript


Este passo a passo irá configurar o Gulp para automatizar suas tarefas relacionadas ao typescript. Todo o fonte utilizado está disponível no projeto introducao-typescript do github. Nesse exemplo será separado diretórios de fontes (neste exemplo, '/src') do de distribuição ('/dist').
  • [raiz]
    • dist
    • src
   
Para iniciar o projeto, no diretório raiz, basta executar o comando abaixo na linha de comando:
npm init

Selecione todas as opções padrões e para o entry point digite './dist/main.js'

Ao terminar será criado o arquivo packages.json na raiz da aplicação, que facilita atualização e restauração dos pacotes NPM no projeto.

Instalando dependências e configuração básica

Será necessário instalar o Gulp CLI (de forma global), o que pode ser feito com o comando abaixo:
npm install -g gulp-cli

Depois instale typescript, gulp e gulp-typescript nas dependências de projeto:
npm install --save-dev typescript gulp gulp-typescript

Defina as configurações do typescript no arquivo tsconfig.json na raiz da aplicação (Para ver mais informações de todas as opções consulte a documentação).
Para ver um exemplo de configuração, veja este exemplo no github:
Crie o gulpfile.js também na raiz da aplicação. Ele será responsável pela tarefa de executar o typescript
Tudo pronto! Depois basta executar o comando abaixo que irá transpilar o typescript para javascript no "target" definido do tsconfig.json.
gulp TypescriptTranscript
Veja o exemplo de um arquivo TS:
E o arquivo JS gerado:

Configurando o Browserify

O browserify permitirá você definir um arquivo de entrada e baseado em suas referências será feita a transpilação automaticamente de toda árvore que se referencia.

Instale o plugin browserify, tesify e vinyl-source-strem, para juntar todos os modulos em um único arquivo.
npm install --save-dev browserify tsify vinyl-source-stream

Com a configuração abaixo do gulpfile.js o arquivo de entrada é utilizado para buscar todas as dependências e gerar um novo arquivo .js. Ao executar o comando abaixo é utilizado o arquivo 03BrowserUsage.ts, visto a dependência 01Basic.ts e gerado o arquivo bundle.js
gulp browserify

Já ficou interessante, mas ainda é preciso executar o comando para transpilar. Vamos agora configurar para a compilação acontecer automaticamente quando os arquivos tiverem alteração com o watchify.
Instale os plugins watchify e gulp-util:
npm install --save-dev watchify gulp-util

Para entender o Browserify veja este link:
https://benclinkinbeard.com/posts/how-browserify-works/
O browserify utiliza um arquivo de entrada, para descobrir todas as dependências e gerar um empacotamento de javascript. Ele também resolve o uso de recursos produtivos do Node.js que não existem para o browser – que é o uso de módulo por exemplo. O uso do require tão comum no Node.js não existe para o javascript no browser. O Browserify implementa um tipo de require interpretando este javascript. O mesmo é feito para o exports.
Desta forma você pode criar seu javascript modularizado, até mesmo usando o typescript, e ainda assim conseguir transformar em um javascript entendível pelo navegador.
Referência
https://www.typescriptlang.org/docs/handbook/gulp.html