You can find the deployed app here.
This is a sandbox to evaluate nestjs and dig how fun it is to implement typical requirements for a backend, with an enphasis on testing, given how dearly missed this requirement can be in 'real world' examples found here and there.
So let's talk about the stack (pushing on an open door here, but hey):
| Package / techno | Description | Documentation |
|---|---|---|
| 💗 typescript | JS superset | https://www.typescriptlang.org/docs/ |
| 😸 Nestjs | Our cats fetishists backend framework | https://docs.nestjs.com/ |
| 🔺 Prisma2 | The ORM | https://www.prisma.io/docs/ |
| 🐘 postgresql | Relational database engine | https://www.postgresql.org/docs/ |
| 🐛 Jest | Tests library | https://jestjs.io/fr/docs/getting-started |
| 🧪 supertest | End to end testing helpers | https://github.com/visionmedia/supertest |
| ✏️ eslint | Linter | https://eslint.org/docs/user-guide/getting-started |
| 📏 prettier | Formatter | https://prettier.io/docs/en/index.html |
We do not want a huge prisma schema. We want to isolate each model (table or set of tables) in its own file.
Let's have a swagger documenting properly exposed routes, that is mainly for each route:
- a description.
- the list of possible responses.
- a definition of the inputs and outputs.
We want to test everything to learn how to properly test, and to face every single difficulty that comes with testing. We will at very least do end to end using superagent, controllers testing, service testing.
All tests should run without any interaction with a database.
👇 Since our prisma schemas are split within modules, we will have to merge them all in one file prisma can understand. Let's do just that:
yarn prisma:merge👇 Now, we need to tell prisma to generate in node_modules the code actually allowing us to interact with the database:
yarn prisma:gen👇 You will need docker and docker-compose to get the postgres database up and running. You can use this command to launch the database container:
yarn dockeryarn prisma:seedyarn devyarn dev:db🔶 We can run all the tests and get a coverage report using the following:
yarn test:devLet's use passport to setup jwt based authentication.
Two routes were defined to demonstrate the use case:
| Route | Description | Documentation |
|---|---|---|
| POST /users/login | The login route | Link |
| GET /users/profile | Logged user profile retrieval | Link |
We have two users in database to play with the routes:
- [email protected] / alice
- [email protected] / bob
- ✅ e2e
- ✅ controllers
- ✅ services
- ✅ local passport strategy
Let's create CRUD routes to manage a list of books. We want to make sure to give a proper feedback when foreign keys violations do occur (when we try to delete an entry whose key is referenced in another table or when we try to update an entry with a foreign key that does not exist). Let's use filters for that!
| Route | Description | Documentation |
|---|---|---|
| GET /books | Retrieves all books | Link |
| GET /authors | Retrieves all authors | Link |
| GET /authors/{id}/books | Retrieves the book written by an author | Link |
| POST /books | Creates a book | Link |
| POST /authors | Creates an author | Link |
| PUT /books/{id} | Updates a book | Link |
| PUT /authors/{id} | Updates an author | Link |
| DELETE /books/{id} | Deletes a book | Link |
| DELETE /authors/{id} | Deletes an author | Link |
- ✅ e2e
- ✅ controllers (turns out these are pretty much useless since we mock the service)
- ✅ services
- ✅ validation pipe
- ✅ filters
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent