|
|
|
## BACK-END [Pontos importantes]
|
|
|
|
|
|
|
|
* Arquivos para mudar ao atualizar o back-end;
|
|
|
|
* Como colocar no ar;
|
|
|
|
* Como criar uma rota;
|
|
|
|
* Sobre as VMs;
|
|
|
|
* Como fazer uma task;
|
|
|
|
* Como trabalhar com envio de e-mails;
|
|
|
|
|
|
|
|
### ARQUIVOS PARA MUDAR AO ATUALIZAR O BACK-END
|
|
|
|
|
|
|
|
Para atualizar o back-end é necessário atualizar alguns arquivos, no geral tais arquivos são referentes a variáveis ambientes ou configuração com o banco de dados. É importante lembrar que as variáveis ambiente mudam para cada VM e para cada objetivo, isto é, na teste não se faz necessário fazer uso do banco de dados da produção por exemplo, e aconselha-se a não usar as mesmas variáveis de configuração do dspace, elasticsearch para evitar o envio de informações desnecessárias.
|
|
|
|
|
|
|
|
Os principais arquivos para se alterar são:
|
|
|
|
|
|
|
|
```
|
|
|
|
config/database.yml
|
|
|
|
config/dspace.yml #para homologa/producao
|
|
|
|
config/secrets.yml #para homologa/producao
|
|
|
|
config/env_vars.sh #para homologa/producao
|
|
|
|
config/initializers/elasticsearch #para homologa/producao esta configuracao faz a pesquisa funcionar
|
|
|
|
```
|
|
|
|
|
|
|
|
### COMO COLOCAR NO AR
|
|
|
|
|
|
|
|
Normalmente a única modificação para colocar a nova versão do back-end no ar é em relação a instalação das gemas, as quais podem ser instaladas através do seguinte comando:
|
|
|
|
|
|
|
|
```
|
|
|
|
bundle install #esse comando ira instalar as gemas na propria maquina
|
|
|
|
bundle install --path vendor/bundle #esse comando ira instalar as gemas na pasta do codigo
|
|
|
|
```
|
|
|
|
|
|
|
|
Após isso, caso as variáveis já estejam configuradas, basta reiniciar o back-end através dos seguinte comando:
|
|
|
|
|
|
|
|
```
|
|
|
|
systemctl restart portalmec portalmec-sidekiq nginx
|
|
|
|
```
|
|
|
|
|
|
|
|
Caso seja a primeira vez que o back-end esteja sendo configurado em uma VM, faz-se necessário configurar o nginx, o arquivo de configuração encontra-se no seguinte diretório:
|
|
|
|
|
|
|
|
```
|
|
|
|
/etc/nginx/sites-enabled/api.conf
|
|
|
|
```
|
|
|
|
|
|
|
|
É importante manter-se atento para as seguintes configurações:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### COMO CRIAR UMA ROTA
|
|
|
|
|
|
|
|
Para criar uma rota normalmente é usado o padrão MVC, para o código do PortalMEC leva-se em consideração principalmente o "MC", M: Model, C: Controller. O Model é responsável pela modelagem dos dados, lá é possível explicitar relações de cardinalidade e ações para eventos em específicos, por exemplo o "before_create" para ações que devem-ser realizadas antes da criação de um registro.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Parte do model de user.
|
|
|
|
|
|
|
|
Já para o C:Controller, é o local no qual se encontra o CRUD, e que é possível renderizar informações no formato de JSON para acesso externo.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Parte do controller de user.
|
|
|
|
|
|
|
|
Portanto, para se criar uma rota, basta criar os arquivos controller e model da funcionalidade que você deseja, ou apenas criar um controller, após isso, configurar um método para o comportamento que você deseja, no geral, os comportamentos principais são:
|
|
|
|
|
|
|
|
```
|
|
|
|
index: renderizar todas informações de um model;
|
|
|
|
show: renderizar informações de um registro em específico;
|
|
|
|
create: processo relacionado ao post para criar um novo registro;
|
|
|
|
update: processo relacionado ao put para atualizar um registro ja existente;
|
|
|
|
delete: remoção de um registro ja existente;
|
|
|
|
```
|
|
|
|
|
|
|
|
Para finalizar a rota, é *extremamente fundamental* referenciar ela no arquivo:
|
|
|
|
|
|
|
|
```
|
|
|
|
config/routes.rb
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Nesse arquivo você relaciona a rota ao método do controller, a exemplo do *submissions/user_submissions/:user_id* que referencia o seguinte método da classe SubmissionsController:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### SOBRE AS VMs
|
|
|
|
|
|
|
|
Cada VM possui um objetivo principal, no geral são três: portalmectest, portalmechomologa e portalmecprod. A teste [portalmectest] possui como função principal o teste de funcionalidades. Já para a homologa [portalmechomologa] o objetivo principal é a validação das funcionalidades propostas na test simulando um ambiente de produção. Por fim, a produção [portalmecprod] é o local onde as funcionalidades são por fim oferecidas aos usuários.
|
|
|
|
|
|
|
|
Existe ainda uma VM relacionado ao elasticsearch, chamada *elasticsearchprod* na qual o elastic search da aplicação é hospedado.
|
|
|
|
|
|
|
|
### COMO FAZER UMA TASK
|
|
|
|
|
|
|
|
Tasks são ferramentas importantes para propor modificações rápidas no andamento da aplicação. As tasks do PortalMec se encontram no seguinte diretório:
|
|
|
|
|
|
|
|
```
|
|
|
|
lib/tasks
|
|
|
|
```
|
|
|
|
|
|
|
|
A definição de uma task normalmente segue o seguinte padrão:
|
|
|
|
|
|
|
|
```
|
|
|
|
namespace :nomenamespace do
|
|
|
|
desc 'descricao da task'
|
|
|
|
|
|
|
|
task :nomedatask => :enviroment do
|
|
|
|
# corpo da task
|
|
|
|
end
|
|
|
|
|
|
|
|
end
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
Abaixo um exemplo de uma task para confirmar email de usuários antigos:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Por fim, para rodar uma task, faz-se uso do seguinte comando:
|
|
|
|
|
|
|
|
```
|
|
|
|
rake nomenamespace:nometask
|
|
|
|
|
|
|
|
exemplo:
|
|
|
|
rake access:confirm_old_emails
|
|
|
|
```
|
|
|
|
|
|
|
|
### COMO TRABALHAR COM O ENVIO DE EMAILS
|
|
|
|
|
|
|
|
Trabalhar com e-mails é extremamente importante, com essa funcionalidade você pode enviar e-mails com os mais diversos objetivos. Para se usar essa funcionalidade deve-se configurar um arquivo na pasta mailers que possui o seguinte caminho:
|
|
|
|
|
|
|
|
```
|
|
|
|
app/maillers
|
|
|
|
```
|
|
|
|
|
|
|
|
Uma vez criado seu arquivo.rb nessa pasta, você deve criar um método para estruturar o e-mail a ser enviado. Ainda, é importante configurar o que será enviado no corpo do e-mail (a formatação propriamente), para isso, deve-se criar no diretorio views dentro de mailers uma pasta com o nome da classe disposta no mailer, e ainda, criar um arquivo .html.erb referenciando ao método da classe.
|
|
|
|
|
|
|
|
Abaixo, exemplos da funcionalidade de envio de e-mail para usuários.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Há emails que não permitem o uso de html, então para contornar tal situação normalmente se cria arquivos com a extensão .text.erb também! |
|
|
|
\ No newline at end of file |
