Um dos principais desafios do desenvolvedor mobile no Delphi é utilizar servidores de aplicação para integrar com seus bancos de dados de modo fácil. Isso porque sabemos que conectar o app diretamente a um banco de dados é uma má prática.

Além disso, sempre surge a dúvida sobre a leitura e envio de dados em formato JSON, parece que ainda é um bicho de sete cabeças para muito desenvolvedor.

Por que é tão “difícil” ler JSON?

Não é mais segredo pra ninguém que o formato mais utilizado para troca de dados/informações entre sistemas é o JSON que, me arrisco a dizer, “substituiu” o XML muito falado no passado.

Sim, claro, são formatos diferentes, com propósitos e propostas diferentes e vai demorar muito para o XML ser completamente abandonado, talvez nunca inclusive. Mas precisamos admitir, diversos serviços usam o padrão para troca de dados e essa é a questão.

Não acho difícil a leitura de JSON, muito pelo contrário. Sua simplicidade é um tremendo aliado para construirmos nossos próprios serviços e API’s. Não é atoa que muitos serviços, como bem mencionei, usam o formato para expor/retornar informações. Veja um exemplo disso:

Experimente digitar no browser:

http://ip-api.com/json/

{
status: "success",
country: "Brazil",
countryCode: "BR",
region: "SP",
regionName: "Sao Paulo",
city: "São Paulo",
zip: "01000",
lat: -23.627,
lon: -46.635,
timezone: "America/Sao_Paulo",
isp: "Vivo",
org: "TELEFÔNICA BRASIL S.A",
as: "AS27699 TELEFÔNICA BRASIL S.A",
query: "189.46.227.25"
}

O JSON acima é o retorno da API na URL indicada. Ela devolve o IP do usuário. Na verdade o IP do provedor mais próximo a região de quem está requisitando a API. Veja que temos ainda cidade, estado, região, timezone, latitude e longitude e muitas outras informações. É muito simples não?

JSON (JavaScript Object Notation) é um modelo para armazenamento e transmissão de informações no formato texto. Apesar de muito simples, tem sido bastante utilizado por aplicações Web devido a sua capacidade de estruturar informações de uma forma bem mais compacta do que a conseguida pelo modelo XML, tornando mais rápido o parsing dessas informações. Isto explica o fato de o JSON ter sido adotado por empresas como Google e Yahoo, cujas aplicações precisam transmitir grandes volumes de dados.

Fonte: https://www.devmedia.com.br/json-tutorial/25275

Sacou? Como falei anteriormente, o JSON tem sido usado com muita frequência e para as mais diversas finalidades. Uma delas é a integração entre sistemas. Imagine o cenário:

Seu software controla a complexa entrada e saída de mercadorias em uma distribuidora de bebidas do país, logo estoque, financeiro, compras e contabilidade fazem parte do seu sistema, mas….a parte contábil é gerida por uma empresa especializada em contabilidade.

Como prover os dados necessários e SOMENTE os dados necessários para o “terceiro” consumir sem interferir no restante dos banco de dados ou pior, vazar informações não desejadas?

Existem dezenas, senão centenas, de formas diferentes para se fazer isso. Um banco de dados bem estruturado e políticas severas de privacidade podem ser adotadas em conjunto com a equipe de desenvolvimento, analistas, engenheiros de software, DBAs, enfim, envolvimento total.

Separar a aplicação em camadas também é uma excelente opção.

Não se enquadrou no exemplo acima? Muito bem, imagine então se seu software precisa ser consumido [utilizado] de diferentes plataformas, Web, Mobile e Desktop. Agora sim, agora ficou mais fácil. E se eu colocar mais um complicador ai?

Poderemos ter mais de uma tecnologia e/ou linguagem de programação que poderão ler os dados do nosso Database.

Como prover os dados de forma transparente?
Como permitir o CRUD (Create, Read, Update e Delete – Inserção, Leitura, Atualização e Exclusão de dados) desse banco?

Tudo isso pode ser resolvido ou ao menos pesado utilizando uma arquitetura, um framework acessível e de baixa curva de aprendizado a um custo relativamente baixo.

Arquitetura Multi-Camadas

Há muito tempo venho defendendo e mostrando como podemos separar nossos projetos desktop em múltiplas camadas, ou simplesmente n-tier. Desde as primeiras versões do DataSnap dentro do Delphi venho acompanhando o movimento. Não, a arquitetura multicamadas não foi criada nem estabelecida pelo DataSnap, vem de muito antes no mundo da programação. E nem sobre DS é esse artigo.

A grande verdade é que separar o software em mais de uma camada é muito mais antigo do que pensamos, nós [programadores Delphi ouso dizer] apenas adiamos um pouco seu uso em nossos softwares. É certo, inclusive, que muitos programadores iniciaram seu uso bem antes do DS e simplesmente ignoraram ele.

Bem, mas vamos lá. Como disse, o artigo não é sobre DataSnap, é sobre Arquitetura Multi-Camadas. Comumente o que mais estamos acostumados a ver no mercado são sistemas Cliente/Servidor, ou seja, 02 camadas. Sistemas duas camadas são dotados de:

• 01 software cliente onde todas ou quase todas as regras de negócios estão concentradas/codificadas;
• 01 banco de dados onde as entidades [tabelas, etc] estão concentras e podem ou não conter regras de negócios.

Nesse modelo de arquitetura nosso software cliente (à esquerda) conecta-se diretamente ao banco de dados (à direita). Podemos ter regras de negócios dos dois lados, ou seja, a aplicação cliente possui diretivas para tomadas de decisões de acordo com as escolhas do usuário ou processamento de cálculos complexos. E no servidor de dados também podemos ter nossas regras codificadas através de Stored Procedures, Triggers, Functions, etc, de acordo com o que o banco de dados escolhido nos possibilita.

Não há nenhum problema nisso, grandes softwares de mercado funcionam dessa forma e a adoção de multicamadas pode significar uma mudança bastante custosa. Em termos monetários e/ou tempo, desgaste, formação de equipes, tc.

A pergunta que fica é: Como prover facilmente dados de um Database que está inserido em uma arquitetura como essa. E pior, como fazer isso NA WEB e PARA WEB.

Podemos precisar prover dados para outro canto do planeta, Japão por exemplo.

Para essa, e muitas outras perguntas, a resposta pode ser n-tier ou multicamdas. Não que a arquitetura anterior não seja capaz de prover uma solução como essa, mas o complicador é maior.

O modelo proposto na imagem anterior visa separar nosso sistema em três camadas, ou seja, aplicação cliente, servidor de aplicações e servidor de dados (Banco de Dados, verde). Nessa arquitetura não teremos mais regras de negócios do lado server restringindo apenas ao Servidor de Aplicações e/ou Servidor de Banco de Dados.

Agora fica muito mais simples e muito mais fácil de fazermos nossa “portabilidade” e exposição dos dados ao mundo externo. Nossa aplicação Mobile, Desktop ou Web funcionará apenas como canada VISUALIZADORA, ou View.

Por onde começar?

O mundo está rodeado de tecnologias, metodologias, processos e modelos que podem ser adotados na composição do nosso sistema multicamadas. Só em Delphi podemos citar facilmente DMVC, DataSnap, RAD Server, RESTDataware, xData, MVCBr e Horse, entre outros frameworks para simplificar [ou não] esse processo de separação.

Dentre as tecnologias citadas, há uma que me chamou à atenção há pouco tempo e que já vem tomando espaço e se destacando pelo sua tremenda simplicidade e poder. O Horse.

Quer criar seu micro-serviço rapidamente, sem complicação, compatível com Windows e Linux, capaz de ser distribuído através de serviço, ISAPI, standalone, de fácil compreensão, baseado em padrões de projeto e de mercado? O Horse.

Tá bom, tá bom, muita propaganda. Mas é verdade! Tudo que citei anteriormente é a mais pura verdade.

O que é o Horse?

O Horse é um framework onde podemos facilmente desenvolver nossas APIs Web e prover informações para serem consumidas por apps, Desktop, Web ou Mobile. Não vou entrar em detalhes, a equipe HashLoad, desenvolvedora do Horse, já se encarregou disso, mas posso [devo] dizer: sim, você pode criar seu servidor de aplicações no Horse, bem “facim” como dizem meus amigos mineiros.

Acesse o GitHub da equipe HashLoad, baixe e instale o Boss (gerenciador de dependências, muito legal inclusive), crie seu projeto Console Application no Delphi, instale o Horse e voilá!

Calma, vou explicar um pouco mais.

Download, Install e criação do primeiro servidor Horse

A primeira coisa que você precisa para iniciar seus estudos em Horse é conhecer o projeto e acessar o grupo da galera no Telegram. No link http://github.com/hashload/horse você já tem acesso a toda a documentação a respeito do projeto e os exemplos para o primeiro servidor.

Repare também que é importante a instalação do Boss, usado para gerenciar as dependências do projeto. A instalação dele é extremamente simples, bastando baixar o Boss, executar e pronto. Instalado.

Para iniciar um projeto Horse, abra o Delphi e crie um projeto do tipo Console Application usando o menu File > New > Console Application. Salve o projeto e então acesse-o através do prompt do MS-DOS, Terminal, PowerShell, enfim. Ao chegar no diretório do seu projeto, digite:

boss init

Pressione [ENTER] quando necessário ou preencha as informações que o B oss lhe pedir. Isso inicializará o Boss em seu projeto. Em seguida digite:

boss install horse

Pronto, instalação do Horse em seu projeto efetuada. Retorne ao Delphi e perceba que o Delphi informa que alguma alteração foi efetuada no projeto. Clique em “Yes to All” e salve novamente seu projeto. Simples assim.

Agora você pode copiar o trecho exemplo do projeto Horse e rodar seu servidor:

uses Horse;

begin
  THorse.Get('/ping',
    procedure(Req: THorseRequest; Res: THorseResponse; Next: TProc)
    begin
      Res.Send('pong');
    end);

  THorse.Listen(9000);
end.

Vejamos. O projeto inicia com a declaração [importação] da unit do Horse. Logo que o servidor inicializa, estamos registrando um a rota ping, ou seja, sempre que digitarmos no browser a url http://localhost:9000/ping estaremos apontando para nosso primeiro endpoint.

...
  THorse.Get('/ping',
    procedure(Req: THorseRequest; Res: THorseResponse; Next: TProc)
...

Perceba a chamada THorse.Get. O segundo parâmetro preenchemos com uma procedure anônima que contém os parâmetros Req, Res e Next.

Em Req receberemos a requisição e é através dela que faremos os devidos processamentos internos. Também conseguimos dados como QueryParams, UrlParams entre outras informações enviadas na requisição.

O Res é a(s) resposta(s) que daremos ao nosso usuário. Podemos devolver o StatusCode da operação, um JSON, string, stream entre outras coisas.

E por fim o Next que recebe uma procedure anônima para processar algo que precisamos. Não entrarei em detalhes aqui.

Muito bem. Se prestou bem a atenção, notou que mencionei o THorse.Get. Sim, esse é o verbo GET que estamos acostumados na web e faz parte do protocolo HTTP. Sabendo disso, é natural nos perguntarmos:

E o restante: POST, PUT, DELETE e PATCH? Tranquilo, experimente digitar THorse. e pressionar Ctrl + Barra de Espaço, tá tudo lá.

...
  THorse.Get('/ping',
    procedure(Req: THorseRequest; Res: THorseResponse; Next: TProc)

  THorse.Post('/ping',
    procedure(Req: THorseRequest; Res: THorseResponse; Next: TProc)

  THorse.Put('/ping',
    procedure(Req: THorseRequest; Res: THorseResponse; Next: TProc)

  THorse.Delete('/ping',
    procedure(Req: THorseRequest; Res: THorseResponse; Next: TProc)

  THorse.Patch('/ping',
    procedure(Req: THorseRequest; Res: THorseResponse; Next: TProc)
...

Já sacou não? Pois bem, todos os verbos estão ai, simples e fácil de acessar.
Levando em consideração apenas o verbo GET, execute seu servidor Horse e então digite a url no browser para obter o retorno do server.

Receberá então a resposta pong vinda da resposta (Res) no Horse.

Mais fácil que isso, só dois disso, como diz um amigo.

Conclusão

Como pudemos observar, iniciar um projeto em Horse é muito simples e dessa forma podemos facilmente separar nosso sistema em camadas. O Horse pode prover dados do Database que veremos em breve em novos artigos em meu blog.

Por hora deixo aqui algumas dicas importantíssimas, uma delas é assistir ao meetup Mobile com BackEnd Horse realizado no canal do YouTube do DUG-CE (Delphi User Groups Ceará) que tem como organizadores Gleryston Matos e José Araújo. Veja o vídeo:

Treinamento Mobile com BackEnd Horse

Gostou da ideia de melhorar a arquitetura do seu sistema e usar os padrões de mercado para que seu software e/ou aplicativos se encaixem nas melhores práticas?

Foi exatamente pensando nisso que desenvolvi o Treinamento Mobile com BackEnd Horse. Boas práticas, separação em camadas, organização e profissionalismo no código serão abordados.

Valor de Pré-Lançamento**

R$ 597,00

por

12x de R$ 29,70*

ou

R$ 297,00 à vista

*Parcelamento possui juros no cartão de crédito

A primeira aula totalmente ao vivo acontecerá nessa quinta-feira, 12 de Novembro, Garanta sua Vaga!

• Acesso Vitalício;
• Código-Fonte;
• Suporte;
• 1 aula ao vivo + Aulas gravadas

**Dependendo de quando esteja acessando essa url, o valor pode ter sofrido alterações.