O desenvolvimento do servidor partiu da estrutura básica do Node.js, com a definição dos arquivos de origem e extensões. A esses arquivos foram adicionadas as pastas para armaze- namento de modelo, configurações, rotas e outros, como apresentado na Figura 13.
Figura 13 – Construção do servidor em Node.js
Fonte: Autoria própria
A seguir serão abordados os itens definidos na construção do servidor e suas funções. Com exceção das rotas, modelos e configurações específicas a cada parte da implementação, todo o servidor foi implementado no ciclo 1 de desenvolvimento.
5.1.1 package.json
O package.json é considerado o ponto inicial de um projeto em Node. Através deste arquivo é definido o projeto, adicionando nome, licença, autores, versão, e outras informações. Neste arquivo também são informadas todas as dependências que serão usadas pelo servidor.
comandos de acesso, ou mesmo definir o ponto de início do servidor. Uma das vantagens de usar um sistema Node, é o grande número de bibliotecas que podem ser utilizadas para tratar funções comuns.
Para este projeto foram adicionadas várias dependências, como Express. A estrutura dessa biblioteca é simples, e tem o objetivo o desenvolvimento flexível da estrutura da aplica- ção. O Express oferece também recursos como roteamento de Localizador Padrão de Recursos (URL), controle de sessão, gerenciamento de requisições, que são amplamente usados no lado servidor (VLADUTU, 2014).
As bibliotecas adicionais tem funções menos abrangentes, sendo aplicadas para co- municação com banco de dados (MS SQL), para realizar tratamento do corpo das requisições (cookie e body-parser). Para este projeto também foram adicionadas as bibliotecas grunt que são destinadas a proteger o código fonte.
5.1.2 Arquivo origem
O arquivo origem (app.js) representa o ponto inicial do servidor. No app.js são definidas as regras as quais o servidor irá operar, sendo elas as configurações de execução ou conexões com bancos de dados e definição das rotas e outros acessos do sistema.
Para a organização do sistema, foi definido que cada chamada tratada pelo servidor, será tratada por uma rota específica. A rota é definida por qual o estado principal solicitante. A Figura 14 apresenta um exemplo de como a chamada "localhost/usuario", seria tratada pela rota login, definida no arquivo de origem.
Figura 14 – Chamada da rota de usuário no servidor.
Fonte: Autoria própria
Desta forma, pode-se concentrar rotas de inserção, alteração ou exclusão em uma rota única, mas limitada a um propósito específico. Além da facilidade em localizar a rota acionada, pode-se facilmente adicionar ou retirar novas rotas, sem impactar o funcionamento das demais.
5.1.3 Rotas
As rotas, dentro do sistema são responsáveis pelo acionamento da função específica a cada evento. Desta forma, cada rota é única e para cada evento disparado pelo cliente, deve existir uma rota no servidor, a qual é responsável por acionar a função e apresentar um retorno.
A Figura 15 apresenta um exemplo de construção dessas rotas. Na figura é possível observar que a rota é apenas uma declaração de qual função será executada, os parâmetros, e como será realizado o tratamento do retorno. Como as chamadas são essencialmente iguais, a variação entre uma rota e outra é dada apenas pelo tipo Transferência de Estado Representacional (REST) sendo tratado e qual função está sendo requisitada.
Figura 15 – Tratamento das rotas referentes ao usuário.
Fonte: Autoria própria
5.1.4 Modelos
Um modelo para o Node.js é uma representação de uma relação do banco de dados. Nessa representação são definidas as regras de negócio, centralizando validações e ajustes ne- cessários aos dados. Essas regras ficam definidas por funções, que por sua vez, são acionadas pelas rotas.
dados. Embora a maioria dos modelos opere deste modo, como na Figura 16, existem ainda dois modelos especiais, o conectaDB e o modelo.
Figura 16 – Modelo de usuário.
Fonte: Autoria própria
A chamada de envio ao banco de dados, acontece através da chamada da função mon- tarResposta. Serão enviados:
∙ recurso (serviço) - define qual arquivo da pasta conf será acessado ∙ parâmetros - dados enviados ao banco
∙ método - qual operação será realizada
5.1.4.1 conectaDB
O modelo conectaDB tem o objetivo de centralizar todas as ações de conexão com banco de dados. O modelo, gerencia novas conexões e armazena as realizadas em um pool, para que não sejam necessários reconectar a cada operação. O banco de dados pode ser selecionado de acordo com o nome da conexão, passada através dos headers, ou como nome padrão, estabelecido através do arquivo conf.json na pasta conf.
Essa opção permite que o servidor seja capaz de se comunicar com bases diferentes. Com essa característica é possível que um servidor atenda dois clientes distintos, com bases diferentes. Desta forma é possível expandir o uso do projeto, por exemplo em outras localidades onde a Jocum esteja presente, sem que os dados entre os usuários entrem em conflito, ou perca-se a privacidade necessária.
A Figura 17 apresenta o principal ciclo da classe, onde é iniciado a conexão com banco de dados. Para construção da conexão, são necessários os parâmetros (servidor, base, usuário, senha) podem ser definidos de duas formas. A primeira, como já mencionado, através do arquivo de configuração, e a segunda via variáveis de ambiente. As variáveis de ambiente consistem em configurações de execução, que permitem acesso a uma informação comum por todo o servi- dor. Sistemas desenvolvidos em Node.js são executados normalmente em estruturas chamadas
containers, que consistem em instâncias da execução.
Programas, como Docker, possibilitam o gerenciamento do ambiente e suas variáveis de controle. Tais configurações podem ser úteis, uma vez que pode-se realizar alteração de endereço do banco de dados sem a necessidade de alterar o código fonte. Além das variáveis, é usado para a conexão a dependência MS SQL, que é responsável por realizar o intermédio entre o banco de dados e o Node.js.
Uma vez estabelecida a conexão, essa é armazenada em um objeto, que será usada nas chamadas posteriores para realizar a troca de mensagens. A primeira conexão é iniciada junto ao sistema, sendo definida no arquivo app.js.
A parte de conexão foi idealizada para atender a dois princípios. O primeiro sendo manutenção, uma vez que todas as conexões ficam centralizadas, qualquer alteração pode ser realizada de forma ágil em um único ponto do sistema. O segundo princípio e a alteração do banco de dados. Embora o sistema tenha sido desenvolvido para se comunicar com SQL Server, a centralização das conexões permite também que ao mudar o sistema para comunicar-se com outro SGBD, o servidor seja impactado em poucos locais. Esses princípios também se aplicam ao modelo.js.
Figura 17 – Estabelecimento de conexão com banco de dados
Fonte: Autoria própria
5.1.4.2 modelo
Enquanto o conectaDB é responsável pelas conexões com o banco, o modelo é res- ponsável por todas as operações de manipulação de dados. A principal função do modelo.js é a executarAcao, que é responsável por controlar os recursos, que são definidos por aquivos na pasta conf. Embora a função possa ser chamada diretamente, devido a sua complexidade, dentro das classes comuns do modelo, a mesma é executada através de uma função anterior chamada
Figura 18 – Fluxo de execução para operações com banco de dados
Fonte: Autoria própria
O fluxograma apresentado na Figura 18, demonstra a sequência de passos usados na função executarAcao uma ação com banco de dados. O primeiro passo é a requisição, que deve apresentar diversos parâmetros, que serão usados para validar usuário, seleção dos parâmetros, recurso e funções de retorno. Em seguida, o sistema irá verificar se o recurso solicitado está car- regado junto a execução. Todos os recursos são armazenados no momento de início do sistema, sendo que alterações nos recursos demandam de reinicialização do servidor.
Caso o recurso exista, é então verificado se o mesmo exige autenticação. Essa autentica- ção é dada através do código da sessão, estabelecida em cada acesso ao sistema. Essa validação é opcional, sendo definida individualmente para cada recurso. Essa visa permitir que outros sis- temas possam acessar determinados recursos sem a necessidade de cadastro de usuário, assim como deixar recursos protegidos, a escolha do cliente.
Apenas após a verificação do recurso e validação é realizada o envio ao banco. Neste ponto, foram adicionados possíveis ajustes aos parâmetros da requisição. Para casos nos quais seja necessário o envio do nome ou código do usuário, ou código da sessão, esses podem ser declarados através do recurso.
Também é permitido retirar parâmetros, através da definição de campos calculados. Desta forma, não é necessário manipular cada parâmetro da requisição em tela, para cada cha- mada, pois podem ser facilmente controlados através do recurso, no servidor.
5.1.5 Arquivos Conf
A pasta de recursos (conf), é destinada a dois tipos de arquivos. O arquivo de configu- ração do servidor, onde são armazenados os dados de conexão com banco de dados. Além deste, são armazenados os arquivos com a definição dos recursos disponíveis com ao banco de dados. Não são adicionados comandos SQL diretamente no servidor, de modo que cada cha- mada ao banco deve corresponder a uma procedure. Estas são indicadas nestes arquivos de con- figuração, em JSON, como na Figura 19.
Figura 19 – Recursos disponíveis para usuário no servidor
Fonte: Autoria própria
Observa-se que devem ser especificados os campos "recurso"e "acoes". O recurso cor- responde ao nome pela qual será referenciado o recurso dentro do servidor. As ações, serão definidas pelas chamadas REST. Não é obrigatório a definição de todos os recursos para que sejam executados.
5.1.6 Opções Adicionais
A pasta node_modules é construída automaticamente através do download das depen- dências. Caso as dependências não tenha sido baixadas e estejam sendo usadas em algum mo- mento, ocorrerá um erro ao iniciar o servidor. Caso semelhante ao arquivo package-lock.json, que referencia as dependências instaladas com o servidor. pasta public é destinada aos arquivos do cliente, sendo abordado em um seção específica. Os arquivos bower.json e .bowerrc também
são destinados à parte cliente.