StephanieJoly4
183d034716
Reorganizing by Feature sections Capabilities folders to give an overview of each feature How-Tos folders to give guidance for advanced customizations Reorganized the Developers section as well, moving the API sub section there added some new visuals and videos to illustrate the How-Tos articles checked the typos, the links and added a section at the end of the doc.json file to redirect existing links to the new ones (SEO purpose + continuity of the user experience) What I have not updated is the "l" folder that, per my understanding, contains the translation of the User Guide - that I only edited in English <!-- CURSOR_SUMMARY --> --- > [!NOTE] > <sup>[Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) is generating a summary for commit 5301502a32856e5b45d7ef30253fa7db6dc55233. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com> Co-authored-by: github-actions <github-actions@twenty.com> Co-authored-by: Abdul Rahman <ar5438376@gmail.com> Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
25 lines
1.7 KiB
Plaintext
25 lines
1.7 KiB
Plaintext
---
|
|
title: Best Practices
|
|
---
|
|
|
|
|
|
This document outlines the best practices you should follow when working on the backend.
|
|
|
|
## Follow a modular approach
|
|
|
|
The backend follows a modular approach, which is a fundamental principle when working with NestJS. Make sure you break down your code into reusable modules to maintain a clean and organized codebase.
|
|
Each module should encapsulate a particular feature or functionality and have a well-defined scope. This modular approach enables clear separation of concerns and removes unnecessary complexities.
|
|
|
|
## Expose services to use in modules
|
|
|
|
Always create services that have a clear and single responsibility, which enhances code readability and maintainability. Name the services descriptively and consistently.
|
|
|
|
You should also expose services that you want to use in other modules. Exposing services to other modules is possible through NestJS's powerful dependency injection system, and promotes loose coupling between components.
|
|
|
|
## Avoid using `any` type
|
|
|
|
When you declare a variable as `any`, TypeScript's type checker doesn't perform any type checking, making it possible to assign any type of values to the variable. TypeScript uses type inference to determine the type of variable based on the value. By declaring it as `any`, TypeScript can no longer infer the type. This makes it hard to catch type-related errors during development, leading to runtime errors and makes the code less maintainable, less reliable, and harder to understand for others.
|
|
|
|
This is why everything should have a type. So if you create a new object with a first name and last name, you should create an interface or type that contains a first name and last name that defines the shape of the object you are manipulating.
|
|
|