Gerencie posts para seu blog
- 📔 Descrição
- 👷 Instalação
- 🔧 Iniciando aplicação
- 🚀 Tecnologias utilizadas
- ☑️ Checklist de funcionalidades
- 📁 Estrutura de Pastas
Esta API permite realizar cadastro de usuários e também o gerenciamento de posts para blogs (criar, editar, buscar e excluir).
Diagrama do Banco de Dados
Diagrama de Caso de Uso
Primeiramente você precisa instalar os seguintes programas para poder utilizar a aplicação:
Após isso você pode clonar o repositório via HTTP com o comando:
git clone https://github.com/llucasreis/blog-api.git
Esta aplicação trabalha com diferentes variáveis de ambiente, na raiz do projeto temos o arquivo
.env.example
com configurações básicas, assim incialmente precisa-se executar os comandos:
# Para executar totalmente local:
cp .env.example .env
# Para executar no ambiente Docker:
cp .env.example .env.dev
Para o segundo caso é preciso alterar a variável DATABASE_HOST
para database
.
Após preparar a variável de ambiente, pra executar a aplicação e o banco de dados, você precisa executar o seguinte comando:
docker-compose -f docker-compose-dev.yml up --build
Este comando irá preparar seu ambiente e aplicação estará ouvindo na porta 3333.
Para executar manualmente a aplicação, você precisa primeiramente ter o PostgreSQL instalado em sua máquina, caso prefira ele pode ser instalado através do Docker:
docker volume create pgdata
docker run -d --name blog-db -e POSTGRES_USER=postgres POSTGRES_PASSWORD=p0stgr3s -e POSTGRES_DB=blog -v pgdata:/data/postgres
Caso você altere alguma variável de ambiente, é necessário também alterar no seu .env
.
Após isso, execute os seguintes comandos para inicializar a aplicação:
yarn install
yarn dev
Por fim, é necessário executar as migrações do sistema para ele criar as tabelas no banco de dados, abra um novo terminal dentro da pasta e digite:
yarn typeorm migration:run
Se o banco e as variáveis de ambiente estiverem configuradas corretamente, as migrações serão executadas com sucesso.
Caso você não queira executar na sua máquina, a aplicação também está disponível online no Heroku no link: https://lprs-blog-api.herokuapp.com/
- Node.js + Typescript
- Express
- PostgreSQL
- TypeORM
- Celebrate (validação de erros nas requisições)
- Jest
- Eslint + Prettier
- Usuários
- Autenticar Usuário
- Criar Usuário
- Buscar Usuário
- Listar Usuários
- Deletar Usuário
- Posts
- Criar Post
- Deletar Post
- Buscar Post
- Listar Posts
- Pesquisar Posts
- Atualizar Post
- Ambiente Docker para desenvolvimento
- Ambiente Docker para produção
- Testes unitários
- Github Action para Integração Contínua
- Deploy automático para o Heroku (com Github Action)
@types
Específico para sobrescrever tipagens de bibliotecas de terceiros
adapters
Adaptadores de bibliotecas externas. Cada pasta apresenta uma funcionalidades, com contracts
informando que funções o adaptador possui e as implementações em implementations
das bibliotecas de fato. Caso for utilizado
outra biblioteca para a mesma funcionalidade, basta apenas implementar e alterar na factory
correspondente.
infra
Implementações relacionadas à infraestrutura da aplicação, atualmente possui apenas as migrações do TypeORM.
main
Implementações e configurações gerais da aplicação, na pasta config
temos as configurações da aplicação,
variáveis de ambiente serão carregadas neste pasta. Em factories
é gerado instâncias de classes que podem ser utilizadas pelos módulos.
modules
Nesta pasta se concentra toda a principal implementação da aplicação dividida em dois módulos: accounts
e posts
, cada um segue uma estrutura interna semelhante.
├── entities: Armazena as entidades do módulo
|
├── mappers: modifica a entidade para ser apresentada ao usuário se necessário
|
├── repositories
│ ├── contracts: contratos (interfaces) para abstrair
|implementações
| |
│ └── typeorm: implementação de fato dos repositórios do TypeORM
|
├── routes: rotas do módulo (que são chamadas em presentation)
|
└── useCases: implementação dos casos de uso da aplicação, cada um pode possuir os seguintes arquivos
|
├── boundary: "fronteiras" do caso de uso, especificamente quais são os parâmetros de entrada e saída
|
├── controller: o controlador que irá receber a requisição
|
├── useCase: o caso de uso de fato, concentrando as regras de negócio
|
├── validation: validação dos parâmetros passados para a rota
presentation
Toda implementação que será apresentada para o usuário é chamada nesta pasta, assim temos as routes
,
middlewares
e errors
.
tests
Todos os testes estão centralizados nesta pasta. Os adapters
e repositories
estão "mockados" para
os testes unitários, e nas pastas useCases
temos de fato as implementações dos testes.