Arquitetura software é o “processo de definição de uma solução estruturada que atende a todos os requisitos técnicos e operacionais, além de otimizar a qualidade de atributos comuns como desempenho, segurança e capacidade de gerenciamento” (MICROSOFT..., C, 2016). Nesse sentido, buscou-se desenvolver a arquitetura do sistema de forma mais flexível e com baixo acoplamento, para aumentar a manutenibilidade do sistema.
Com o advento da tecnologia e barateamentos dos componentes de computadores (CPU – Central Processing Unit - e Memória), os dispositivos utilizados em cliente tiveram seu poder de processamento elevado. Isso os habilitou a executarem softwares mais complexos e que demandam mais processamento. Assim, devido ao aumento da capacidade de processamento dos dispositivos no cliente, podemos delegar parte do processamento do sistema para eles, conforme o conceito fat-client.
Fat-client (cliente gordo – em português) é “a designação que se dá a um computador inserido numa rede de arquitetura de cliente/servidor que tem recursos suficientes para realizar boa parte das operações por si próprio de forma a depender o mínimo possível de um servidor” (JAMES, 2009). Desse modo, colocamos grande parte da carga de processamento na máquina do cliente, dando a ele um melhor desempenho local no sentido de velocidade da Internet, pois reduzimos as chamadas necessárias para o servidor.
4.3.1.1. Pastas server, client e imports
No framework do Meteor todo o código escrito por padrão executa tanto em servidor como em cliente. Desse modo, escrevemos apenas uma classe, um arquivo, que o mesmo executará tanto no cliente (browser ou mobile) quanto no servidor. Contudo, muitas vezes é necessário restringir parte do nosso código para ser executado em apenas um ambiente, seja ele cliente ou servidor.
Para realizar essa divisão de código, o Meteor reserva os nomes de pastas client e server. A pasta client (cliente) indica que todo o seu conteúdo será apenas executado em cliente. Portanto, todos os arquivos dentro dessa pasta não serão carregados no servidor, sendo envidados somente para o cliente. Já a pasta server (servidor) faz justamente o contrário. Todo o seu conteúdo é apenas carregado em servidor, não sendo enviado para o cliente.
Com esse recurso de divisão de conteúdo, podemos restringir arquivos e códigos sensíveis, como por exemplo chaves de APIs (Application Programming Interface) e manipulação do banco de dados, para serem executados apenas no servidor (ambiente confiável). Em contrapartida, podemos restringir controladores e serviços de comunicação com servidor para serem executados apenas no cliente. Demais nomes de pastas são carregados em ambos os ambientes de execução.
Outra pasta com nome reservado no Meteor é a pasta imports. Esta é uma pasta que contém arquivos e módulos carregados pela cláusula JavaScript ES6 import. Nessa pasta todo e qualquer conteúdo, seja código (TypyScript, JavaScript, etc.) ou templates (HTML e CSS), apenas é carregado em servidor ou enviado para o cliente se algum arquivo, que esteja fora dessa pasta, efetuar sua importação pela clausula import ou pelo serviço carregador de módulos requireJS8. Desse modo,
dizemos que os arquivos contidos em pastas com nome imports são lazy-loaded.
4.3.1.2. Componentes, serviços e persistência
O sistema conta com uma arquitetura um pouco peculiar quando comparado a frameworks mais tradicionais como o Zend, JSF e Spring. Porém, isso se deve aos frameworks utilizados que quando combinados, conforme apresentado na seção 3.1, geram o modelo de arquitetura descrito na Figura 16.
Figura 16 Diagrama de arquitetura do sistema.
Conforme visto na Figura 16, inserimos os conceitos de componentes, serviços, métodos e publicações. Esses conceitos são explicados a seguir.
Um componente, segundo o framework Angular, é uma combinação de controlador e visão (HTML), ou seja, é uma parte da interface gráfica. Sua responsabilidade é efetuar tratar os eventos do usuário, apresentar dados e chamar serviços que realizam a persistência.
No sistema podem existir dois tipos de componentes: componentes WEB e componentes mobile. Um componente WEB é um componente normal, otimizado para desktops. Já o componente mobile foi otimizado para dispositivos móveis. Em ambos os componentes existe um controlador básico que contém as funcionalidades básicas
para aquele componente, o qual é estendido por meio de herança para ser otimizado para a plataforma em que este será utilizados, representado na Figura 17, garantido a manutenibilidade dos componentes gráficos.
Figura 17 - Diagrama de classes da arquitetura de componentes proposta.
Os serviços são objetos que provém uma funcionalidade ou um conjunto de funcionalidades que pode ser reutilizado por diferentes clientes para diferentes finalidades. Na aplicação desenvolvida existem três tipos de serviços:
Serviço de roteamento. Provido pelo framework do angular 2, este serviço é responsável por armazenar todas as rotas do sistema (sua assinatura – URL e parâmetros), com seus devidos componentes raízes (componentes que deverão ser apresentados quando essa rota for ativada). O serviço de roteamento é o responsável por efetuar a transição de páginas na aplicação.
Serviço de controle de acesso. Esse é composto de duas partes: contas, o qual é implementado pelo framework do Meteor, e autorização, criado pelo autor do trabalho. O primeiro tem a função de criar contas de usuário e efetuar sua autenticação no sistema. Já o segundo tem por finalidade atribuir permissões para os usuários e autorizá-los a realizar determinada operação com base nelas.
Serviços de comunicação com o servidor. Esses serviços são responsáveis por efetuarem a comunicação com o servidor, provendo uma interface com
os métodos disponíveis no servidor, para efetuar persistência de dados ou buscas de dados de forma não reativa9. Cada módulo do sistema possui
apenas um serviço de comunicação com o servidor, sendo eles instanciados apenas uma vez pelo framework Angular e injetado sua referência em cada componente que o requisita, assim denominamos o serviço como singleton10. Com esse tipo de serviço retiramos a
comunicação com o servidor de dentro dos componentes, garantindo melhor manutenibilidade, e permitimos uma possível troca de servidor. Esse serviço em especial é uma implementação do padrão de projeto proxy.
Métodos são um conceito do framework Meteor, com a seguinte definição: “são chamadas de procedimento remoto (do inglês RPC – Remote Procedure Call), usado para salvar eventos de entrada do usuário e dados vêm do cliente” (METEOR GUIDE, M, 2016). Ou seja, é um ponto de acesso no servidor que o cliente pode se conectar, se assemelhando a chamadas HTTP (Hypertext Transfer Protocol). Os métodos são definidos em servidor e possuem total acesso as coleções em servidor para realizarem sua manipulação. O código cliente usa esses métodos por meio dos serviços de comunicação com servidor, conforme explicados anteriormente.
Publicações também são específicas do framework Meteor e possuem a seguinte definição: “é uma API nomeada no servidor que constrói um conjunto de dados para enviar para um cliente”. (METEOR GUIDE, P, 2016). As publicações enviam dados para o cliente de forma contínua (reativa), com o objetivo de garantir que o cliente possua os dados mais atualizados. Para que um cliente receba os dados (registros) dessa publicação é necessário que ele efetue uma inscrição nessa publicação, passando a receber seus dados de forma constante conforme as atualizações. Devido a uma limitação atual na utilização dos frameworks Angular 2 com Meteor, não foi possível abstrair essas inscrições para serem realizadas apenas por meio de serviços. Assim, os componentes as efetuam de forma direta, o que não é o ideal pois adiciona um ou mais pontos de manutenção em cada componente.
9 Reatividade significa que a cada atualização do dado, esse é imediatamente enviado
novamente para o cliente, também chamado de “tempo real” (veja a nota de rodapé na página 23).
10 Para mais detalhes sobre o padrão de projeto proxy e singleton, recomendo a leitura do livro
Design Patterns - Elements of Reusable Object-Oriented Software (Erich Gamma, et al.), no capítulo Singleton.