Skip to content

Commit

Permalink
Mais atualizações do README principal
Browse files Browse the repository at this point in the history
  • Loading branch information
huogerac committed Oct 12, 2022
1 parent 5b48afc commit 202a7ca
Showing 1 changed file with 65 additions and 26 deletions.
91 changes: 65 additions & 26 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,14 +6,27 @@ Um template de projeto completo **full-stack**, **pronto para produção**, com

Com mais de 20 anos trabalhando como web-developer, eu [Tony Lâmpada](https://github.com/tonylampada) descobri que fazendo do jeito certo, podemos ter muito mais chances de:

- Todos do time e eu conseguir ser mais produtivos com entregas mais rápidas focando no negócio
- Todos do time conseguirem ser mais produtivos com entregas mais rápidas focando no negócio
- Clientes mais felizes
- Produto final com mais qualidade e fácil de mudar

## O que está incluso?

- Ambiente baseado em containers (docker) e docker compose, início com mínimo de esforço
- Integração entre FRONTEND e BACKEND prontos para produção
- Autenticação configurada para funcionar com o Django (cookies)
- Estrutura de pastas para facilitar escalar e organizar o projeto
- Estilo de código configurados para o BACKEND (flake8) e FRONTEND (eslint)
- Exemplo funcional de um todo-list com listar/incluir
- BACKEND: [Django](https://www.djangoproject.com/) e Postgres
- BACKEND: Teste configurado com exemplos (usando [Pytest](https://docs.pytest.org/)) para promover TDD
- FRONTEND: [Vue 2](https://v2.vuejs.org/), [Vuetify](https://vuetifyjs.com/en/getting-started/quick-start) e [Nuxt](https://nuxtjs.org/) (usando vue cli) separado do backend
- FRONTEND: Modo sem backend usando [mock-apis](https://medium.com/@tonylampada/javascript-mock-api-why-you-might-want-to-have-one-232b3ba46b12) para promover a validação rápida de ideias

## Requisitos

- Node 14 instalado (digite `node -v` para ver a versão) e conseguir rodar o [vue-cli](https://cli.vuejs.org/)
- Docker & Docker compose instalados para subir tudo muito rápido e não precisar mudar infinitas configurações diretamente na sua máquina
- Docker & Docker compose instalados para subir tudo muito rápido e não precisar instalar/configurar infinitas libs/ferramentas diretamente na sua máquina

## Começando

Expand Down Expand Up @@ -53,15 +66,15 @@ E estes containers estão organizados como no diagrama abaixo:

![djavue-containers](./images/djavue-containers.png)


🚀 Para acessar os serviços, utilize as URLs abaixo:

- `http://localhost` para acessar o frontend
- `http://localhost/api` para acessar diretamente alguma rota da API
- `http://localhost/admin` para acessar o Django admin

📝 NOTA: Embora o frontend está em `http://localhost:3000`, não faz muito sentido acessar esta URL diretamente. Utilize `http://localhost` para acessar o front, desta forma o NGINX vai intermediar e saber redirecionar requisições feitas pelo frontend para `http://localhost/api`, ou seja, acessando com a porta 3000, as requisições /api não funcionam.

Para conseguir logar, vamos precisar criar um usuário no Django. Podemos fazer isto entrando no container backend e rodar o comando do Django `./manage.py createsuperuser` para criar um usuário:
Para conseguir logar, vamos precisar criar um usuário no Django. Podemos fazer isto entrando no container backend e rodar o comando do Django `./manage.py createsuperuser`:

```
$ docker-compose exec backend ./manage.py createsuperuser
Expand Down Expand Up @@ -109,15 +122,14 @@ $ docker-compose down

📝 NOTA: Utilize o comando `docker ps` e garanta que nenhum container está rodando


Para mais informações, siga o [README.md](template/README.md) que foi gerado dentro do seu projeto `mytodolist`

## Subindo apenas o frontend (Backendless)
## Subindo apenas o frontend (backend-less)

Para algumas demandas de trabalho, faz sentido alterar primeiro o frontend, e assim não faz sentido subir
o backend com banco de dados. No Djàvue temos o conceito de API MOCK. ou seja, subir apenas o front com um imitador de backend (mock). Em ouras palavras, subir apenas código JavaScript e nada de Python ou qualquer outra tecnologia.

Para isto, ao invés de utilizar o docker-compose up apresentado no início, vamos utilizar uma variação:
Para isto, ao invés de utilizar o `docker-compose up` apresentado no início, vamos utilizar uma pequena variação:

```bash

Expand All @@ -130,37 +142,64 @@ $ docker-compose -f docker-compose.yml -f docker-compose.apimock.yml up frontend
- `http://localhost` para acessar o frontend
- `http://localhost/api` para acessar diretamente alguma rota da API MOCK

📝 NOTA: Rode um `docker ps` e veja que temos rodando um imitador de backend (que está na pasta `apimock`) em código NodeJS.
📝 NOTA: Rode um `docker ps` e veja que temos rodando um imitador de backend (que está na pasta `apimock`) em código NodeJS com [Express](https://expressjs.com/).

## Para mais informações sobre Djávue & API Mock

- [Djà vue: Uma jornada pelo desenvolvimento web com Django e Vue.js](https://evolutio.io/curso/djavue) - Curso gratuito
- [Javascript mock api — why you might want to have one](https://medium.com/@tonylampada/javascript-mock-api-why-you-might-want-to-have-one-232b3ba46b12)
- [Tutorial Djavue Python Brasil 2021 - Parte 1](https://www.youtube.com/watch?v=E8yTa7_IBu0&t) - Fazendo o setup sem Docker e no Windows
- [Tutorial Djavue Python Brasil 2021 - Parte 2](https://www.youtube.com/watch?v=U_1qHi8OdeI&t) - Fazendo o setup sem Docker e no Windows
- [Repositório do Djá vue na Python Brasil](https://github.com/buserbrasil/djavue-python-brasil) - Repo dos vídeos acima
- [Três formas de fazer mock da sua API com JavaScript | Entenda onde isto te ajuda](https://huogerac.hashnode.dev/tres-formas-de-fazer-mock-da-sua-api-com-javascript-or-entenda-onde-isto-te-ajuda)

## Contribuindo

Este é template de projeto que vem evoluindo desde do início de 2018, aceitamos sugestões e ficaremos muito felizes em saber a sua!
A melhor forma para promover uma mudança é criando uma [Issue aqui](https://github.com/evolutio/djavue/issues).

## CHANGELOG

### 2022-10-12 - v.2.0.0 - Atualizado para versões mais recentes do Django e Djavue

- Atualizado de Django 1.11 para 4.0
- Atualizado de Vuejs, vuetity e nuxt 1.0 para 2.6, Node 9 para 14
- Remove o dev.sh e passa a utilizar Docker Compose
- Muda API Mock para ao invés de utilizar a pasta apimock ou api (conforme variável API_MOCK), utiliza um simulador de Backend com NodeJS/Express
- Muda para subir modo com Backend Django ou modo com API MOCK conforme comando docker compose ao invés de subir tudo sempre
- Muda para utilizar vue-router implícito (padrão do Nuxt) ao invés da pasta router (\*\* sujeto a mudança)
- Adiciona Pytest nos testes do backend
- Ajustes nas configurações do Django conforme as políticas mais novas de segurança
- Adiciona Flake8 para linter do backend
- Adiciona mais regras para linter no frontend com Eslint

### 2019-11-28 - v.1.0.1 - Pequenos ajustes

### What's Included
- bugfixes
- fix de segurança
- habilitado PWA
- ajuste no show do snack

- docker-based development environment. Get started with minimum effort
- Executable help. `dev.sh` remembers all the important commands, so you don't have to.
- Django + Postgres in the backend.
- Vue + Nuxt based frontend (detached from the backend)
- [Vuetify.js](https://vuetifyjs.com/en/getting-started/quick-start) components
- Authentication works
- A working TODO-list that saves TODO items to a database
- Backend-less development mode, using [mock-apis](https://medium.com/@tonylampada/javascript-mock-api-why-you-might-want-to-have-one-232b3ba46b12)
### 2018-06-05 - v.1.0.0 - Versão mais funcional

![screenshot](http://image.ibb.co/f0ekjc/image.png)
- Melhor documentação
- Melhor configurações para deploy
- Diversos bufixes

### Contributing
### 2018-03-18 - v.0.0.1 - Versão inicial

This template is very new in early stage and there is much room for improvement.
If you'd like to improve it somehow, I'd love to hear about it :-)
- Primeira versão lançada

### What are the good practices (or, how I like to do things):
## What are the good practices (or, how I like to do things):

#### 1. Start by building a backend-less frontend
### 1. Start by building a backend-less frontend

Software building is tricky, because it's too easy to end up creating the wrong software. To avoid that we need constant feedback about our partial progress. By using [mock-apis](https://medium.com/@tonylampada/javascript-mock-api-why-you-might-want-to-have-one-232b3ba46b12), we can deliver a "fake" piece of our application into the clients hands that looks and feels like the real thing. We know we'll make mistakes. Let us make them cheaply.

Mock apis go into `frontend/components/api/apimock.js` - just follow the patterns in there.
This is also a good time to write the equivalent AJAX calls inside `api.js` (to URLs that don't exist in the backend yet)

#### 2. Start with the output
### 2. Start with the output

It's likely that the software you need to build will require input from the user, and give output to the user.
When we act in the world, we see **tools** and **obstacles**.
Expand All @@ -171,7 +210,7 @@ Input is cost. Output is value.

You should start by creating the fake screens (mockapi-based) for the output (value) part of your software. Validate that with the client. The result of that process will give you useful information that will orient the design of the next parts of your software, the input (cost).

#### 3. Deploy early, deploy often
### 3. Deploy early, deploy often

I like to setup my projects with two online live test-environments that will be deployed with every commit

Expand All @@ -182,7 +221,7 @@ During the early stages of development, having the client validate things in the

This project will come with a `.gitlab-ci.yml` file. If you host your code in a private Gitlab instance, this should make it easier for you to deploy to "fronttest" and "test" to AWS by using [Gitlab continuous integration and deploy](https://about.gitlab.com/features/gitlab-ci-cd/)

#### 4. TDD is the fastest way
### 4. TDD is the fastest way

When you have a mockapi, that code is not just junk that you don't need. On the contrary. It contains a **valuable, unambiguous specification of how your backend must behave**. At that point, the fastest way to build your backend is to look at your mock apis as an orienting guide for test cases.

Expand Down

0 comments on commit 202a7ca

Please sign in to comment.