MarlonLira / sstec-backend

Node js | Typescript

Simple Parking

Esse documento auxiliará no desenvolvimento do Backend da Aplicação -> Web|Mobile

Dados do projeto

Empresa: Simple System Tecnologia SSTEC
Nome do app: Simple Parking
Site: simpleparking.com.br
Site Temp: simpleparking.herokuapp.com/
Endpoint: simplebackend.herokuapp.com/
Tecnologias de desenvolvimento: Node js | (Input - Typescript) -> (Output -- Javascript)

Requisitos

• VS Code - Recomendado
• Node LTS - Obrigatório
• Cmder - Recomendado
• Postman - Recomendado
• Document This - Opcional
• OpenAPI(Swagger) Editor - Opcional

Dependencias

• BCrypt
• Body Parser
• Cookie Parser
• Express
• Express Validator
• Cors
• Jsonwebtoken
• Sequelize
• Nodemon
• Inversify
• cli-color
• swagger

Instalação Requisitos

• Via Executavel.

Instalação Dependencias

• Via NPM ou YARN.

Estrutura dos arquivos do Backend

/ - Arquivos de códigos da aplicação.
main - Arquivos com configuração do server da aplicação.
data/models/ - Arquivos de códigos da aplicação.
data/controllers/ - Arquivos de códigos da aplicação.
data/repositories/ - Arquivos de códigos da aplicação.
data/interfaces/ - Arquivos de códigos da aplicação.
data/types/ - Arquivos de códigos da aplicação.
data/services/ - Arquivos de códigos da aplicação.
commons/ - Arquivos comuns da aplicação. Inclui utilitários.
gitignore - Configura arquivos a serem ignorados pelo git.
app.ts - Arquivo inicial.
inversify.config.ts - Arquivo responsável pela criação do container da injeção de dependencias.
package.json - Arquivo de dependências e detalhes da aplicacação.
config.json - Arquivo com configurações do projeto como configurações de banco de dados.
tsconfig.json - Arquivo com configurações do transpile da aplicação.
swagger.json - Arquivo com configurações do swagger da aplicação.
README.md - Leia-me com instruções.

Nomeação dos arquivos e componentes

• Os componentes são nomeados com o padrão PascalCase independente de ser componente de classe ou funcional.
• Os components e containers tem seus arquivos com o mesmo nome. Caso o component ou container esteja fora do diretório components ou containers respectivamente, o nome do arquivo deve serguir com o identificador Component ou Container.
• Os arquivos que não são componentes devem ser nomeados no formato camelCase.js.
• Os arquivos que contém código ts devem ser nomeados com a extensão .ts.

GitFlow

O GitFlow Workflow é um design de fluxo de trabalho Git que define um modelo de ramificação projetado em torno da versão do projeto. Isso fornece uma estrutura robusta para gerenciar projetos maiores.
Saiba mais sobre o GitFlow.
Explicação da ferramenta git-flow se for usar ela.

Versionamento Semântico

O Versionamento Semântico são regras que formalizam de forma prática e eficiente o incremento de versões de software. O versionamento do Simple Parking deve basedado na versão 2 do Versionament Semântico utilizando as regras 2, 3, 4, 6, 7, 8, 9 e 11 encontradas no site do samver.org.

Commits Semânticos

Para uma melhor navegação pelos commits, possibilitando um entendimento melhor e mais rápido, e consequentemente melhorando a manutenção do sistema, utilizamos um padrão na escrita do commit similar ao proposto por http://karma-runner.github.io/3.0/dev/git-commit-msg.html. As linhas das mensagens de commit não devem exceder 72 caracteres. Essa convenção permite uma boa leitura dos commits na maiorias dos terminais.

Formato da mensagem de commit:
<tipo>(): <assunto>
<linha em branco>
<mensagem>
<linha em branco>
<rodapé>

Exemplo:

chore(eslint): instalar dependência eslint

A dependência eslint é um utilitário de linting para JavaScript.
Auxilia o desenvolvedor a escrever o código em um padrão
preestabelecido.

BREAKING CHANGE:
Quanto ao foo.bar, foo.baz deve ser utilizado ao invés disso.

<tipo>:

• feat - nova funcionalidade/recurso (features)
• fix - correção de bug
• perf - uma mudança de código que melhora a performance
• docs - alterações na documentação
• style - formatação, falta de ponto e vírgula, etc; não afetam o significado do código
• refactor - refatoração do código, não corrige um bug nem adiciona um recurso; por exemplo, renomear variável
• test - adição ou correção de testes
• chore - atualizando tasks do Grunt, Webpack, etc; mudanças que não modificam o src/

<escopo>: Opcional, principalmente se a alteração for global.
Exemplos: init, runner, watcher, config, web-server, proxy, etc.

<assunto>: Deve ser escrito na forma imperativa, ou se preferir, de uma forma que complete a frase "Se aplicado, este commit irá ".

<corpo>: Deve conter descrições mais precisas do que está contido no commit, mostrando as razões ou consequências geradas pela alteração, assim como instruções futuras.

<rodapé>: È dedicado para notas e avisos importantes, como fechamento de issue e se existem mudanças radicais que quebrem funcionalidades. No caso de mudanças de quebras (BREAKING CHANGE) deve ser indicado “BREAKING CHANGE:” seguido com a explicação que leva a inclusão dessa marcação.

Correções de possiveis erros

- Windows Build Tools
 * Rodar no PowerShell como administrador.
  -> npm install --global --production windows-build-tools