Autenticações com Firebase - 21/04/2017

De acordo com a orientação geral do projeto St. Locator de criar soluções a partir de frameworks e APIs já estabelecidas como forma de agilizar o desenvolvimento, utilizaremos o Firebase para gerenciar as autenticações de usuários. Essa API do Google reúne diversas soluções para o desenvolvimento de aplicações mobile e web, como banco de dados, telemetria, hosting de aplicações, testes automatizados, notificações push, publicidade, e claro, a autenticação. 

Essa solução possui interessantes atrativos como a utilização de redes sociais para realizar o login de usuários, entre as quais temos as opções de contas do Google, Facebook, Twitter e Github, no entanto para nossa aplicação optamos por por não utilizar os dois últimos. Além disso, há a opção de usar e-mail e senha não relacionados à redes sociais, esse processo é plenamente suportado pelo Firebase que disponibiliza cadastro, verificação e alteração de senha, mas caso seja utilizado um e-mail cujo provedor seja conhecido ele passa à associar ambas ao mesmo UID conforme a imagem abaixo:

A integração é muito fácil de ser feita e não exige conhecimento avançado em infraestrutura e programação, pois além de excelentes tutoriais, a forma de configuração em console torna tudo muito simples e intuitivo. Sendo o único ponto que exige mais atenção a interação com o Facebook, que se trata de outro contexto onde é preciso criar um conta de desenvolvedor e configurar permissões para permitir a integração de suas API de login, mas nada muito complexo.

As URL's - 02/04/2017

A correta utilização de uma API REST do lado do cliente está em grande parte em entender o mecanismo da URL do servidor. Podemos começar com um simples exemplo:

 

O example_api é como mostrado acima um controlador (MVC) , podendo ser user, products, customers, etc. O users se trata de um recurso de uma base de dados, por exemplo, esse recurso interage com os verbos HTTP: GET, PUT, DELETE, POST, etc., para realizar as operações de CRUD: create, read, update e delete. Na atual versão do REST server utilizado o JSON é o padrão, dado sua popularidade e mais notável diferença para o xml que é sua menor verbosidade, mas permite como dito em uma postagem anterior, XML, HTML e CSV, para tanto é necessário requisitar um formato através da URL, como o exemplo a seguir:

Onde format aceita xml, json, html, csv, conforme mostra a página de exemplos codeigniter-restserver:

Ao permitir essa variada forma de se interagir com a API estamos aumentando as possibilidades para eventuais usos de aplicações lado do cliente independentemente da linguagem de programação utilizada, estes poderão escolher a melhor forma de se tratar as informações consumidas.

fonte: https://code.tutsplus.com/tutorials/working-with-restful-services-in-codeigniter--net-8814

REST API - 31/03/2017

O sistema StLocator tem a proposta de oferecer seus serviços em forma  de API, supondo um eventual crescimento da aplicação e ou integração com outros sistemas que estendam e ou agreguem de alguma forma à solução para restituição de bens perdidos, portanto o nosso servidor utilizará o modelo de arquitetura REST.

Transferência de Estado Representacional, em inglês, Representation State Transfer, ou REST, é um termo datado de 2000 na tese de doutorado de Roy Fielding, um dos principais autores das especificações do protocolo HTTP e co-fundador do projeto Apache Web Server. A própria rede mundial de computadores é um exemplo de aplicação funcionando em REST. Essa tecnologia aproveita o protocolo mais utilizado e seus métodos para realizar transações stateless. Também conhecidos como HTTP verbs, pode-se citar entre os mais comuns: GET, POST, PUT, DELETE.  O paradigma “sem estado” dessas transações de requisição entre cliente e  servidor torna cada um delas únicas, poupando o lado do cliente de tratar comunicação com banco de dados, logs, cache, etc., e da mesma forma o lado servidor não lida com interface, experiência de usuário, logo tal divisão permite liberdade de evolução distinta para os ambientes. A partir desse princípio o modelo de serviço converge com o estrutural da aplicação, que a princípio considerou-se tratar de um MVC, quando na prática acaba se tornando um MVW, Model View Whatever,  o tanto faz é uma bem humorada definição sugerida pela equipe do Angular JS que significa utilizar  o que for mais adequado para aplicação, seja MVC, MVVM ou o MVP. Neste momento utilizaremos o MVC, contudo outras abordagens poderão ser analisadas durante o desenvolvimento.

Nosso servidor REST terá diversos tipos de respostas de acordo com as  requisições clientes, pois disponibilizaremos respostas em JSON, XML, HTML e CSV, o que permite uma integração com aplicações Web e Mobile.

Framework PHP - 29/03/2017

O desenvolvimento de um sistema de forma “from scratch”, ou seja do zero, é custosa e requer muita experiência do desenvolvedor e domínio da tecnologia empregada para uma conclusão bem sucedida. Esse é o motivo para a popularidade do uso de frameworks, toolkits, engines, etc., que tornam o processo de construção de um sistema drasticamente mais fácil, por exemplo, em desenvolvimento de jogos, onde há uma enorme gama de ferramentas facilitadoras utilizadas tanto por amadores quanto pela indústria digital. A partir dessa premissa a equipe São Longuinho, optou por utilizar uma framework para a criação do lado servidor da aplicação, à tal escolha pesou dois pontos fundamentais que são a facilidade de uso e ou aprendizado e poder da ferramenta, para tanto foram avaliados diversas frameworks e chegou-se ao Cakephp e CodeIgniter, ambas as duas mais populares e gratuitas. Tal popularidade é resultado do poder de ambas, que são muito bem documentadas, contêm bibliotecas repletas de funcionalidades e facilidades, mas o ponto de desempate foi a facilidade de manipulação e adaptação aos interesses do nosso servidor como descrito no escopo do projeto, uma API Rest. 

A framework escolhida foi o CodeIgniter cuja arquitetura é a MVC (Utilizaremos o MVW, mas trataremos desse tema na próxima postagem), que será utilizado junto com o CRUDgniter para uma implementação do tipo database first e uma extensão para o REST server. Essa decisão nos exonera da árdua tarefa de construir funcionalidades complexas, como as relacionadas à segurança de acesso à diretórios, roteamento, arquivos de configurações, etc., portanto permite que a equipe tenha foco principal em desenvolver o negócio da aplicação.

PHP - POO - 21/03/2017

A linguagem escolhida para o back-end da aplicação é o PHP (PHP Hypertext Preprocessor), uma linguagem de programação interpretada escolhida pelos seguintes atrativos: ser a mais utilizada no lado servidor, por ser de código aberto, de fácil aprendizado, multi-plataforma, de baixo custo de manutenção e consumo, e principalmente por suportar o paradigma de orientação à objetos. A arquitetura do sistema seguirá o MVC (model, view, controller), implementando classes de ORM (Object Relational Model) na camada mais importante a Model, através de desgin patterns como Factory, Composite e Repository e técnicas de programação PDO (PHP data object) para acesso padrão aos diversos bancos de dados relacionais suportados por essa linguagem, de forma a tornar a aplicação o mais flexível possível, por exemplo, usaremos o banco PostgreSQL, mas através de um arquivos .ini é possível mudar para qualquer outro, como o sqlite, mysql, oracle, etc. A versão utilizada será a 7.0, tomando como material principal de referência o livro php Programando Orientado a Objetos do graduado analista e mestre em engenharia de software Pablo Dall’Oglio.

    O servidor funcionará como uma API, permitindo que seja usada por fontes externas através de REST, portanto em comandos de HTTP semântico, como GET, PUT, DELETE, UPDATE, etc, retornando objetos JSON (JavaScript Object Notation) menos verbosos que o XML, seguindo uma tendência tecnológica para aplicações em microservices, o que facilita a integração com outros sistemas.

Preparação do ambiente Amazon AWS - 03/03/2017

A fim de entender e estudar a arquitetura dos serviços da Amazon, esse fim de semana corremos atrás de estudar as configurações necessárias para que o sistema funcione perfeitamente. 

Conseguimos configurar uma máquina virtual Linux com o EC2, conectar via SSH utilizando o cliente PuTTY no Windows e realizar a instalação dos pacotes que iremos precisar para a utilização do sistema (Servidor web, PHP e PostgreSQL+Postgis). Com bastante leitura da documentação da Amazon AWS (disponível em https://aws.amazon.com/documentation/), conseguimos utilizar o Amazon Route 53 (serviço de DNS da Amazon) e direcionar nosso domínio (http://stlocator.com.br). 

Optamos por entender a infraestrutura do nosso ambiente para evitar problemas ao final do projeto (dica dada por alunos de semestres anteriores da disciplina), tendo assim, uma experiência fluída e tranquila ao disponibilizar nossa aplicação. 

Boa semana a todos, e não esqueça de acompanhar também a equipe São Longuinho no YouTube (o primeiro vídeo já foi enviado!).