diff --git a/backend/docs/guide/create-feature-x.md b/backend/docs/guide/create-feature-x.md index e6994557f..91206ebc9 100644 --- a/backend/docs/guide/create-feature-x.md +++ b/backend/docs/guide/create-feature-x.md @@ -33,7 +33,7 @@ With the database changes generated. Now let's create the APIs for `feature-x`. This will create a folder inside `/src/services` with `feature-x` and 3 files 1. `feature-x-dal`: The Database Access Layer function -2. `feature-x-service`: The service layer where all bussiness logic happens +2. `feature-x-service`: The service layer where all business logic happens 3. `feature-x-type`: Types used by feature-x There are more layers like for reusable shared function u can setup a file called `feature-x-fns` @@ -46,7 +46,7 @@ All the server related logic happens inside `/src/server`. To connect the servic 1. Add the service type inside `fastify.d.ts` file below `service` namespace of a FastifyServerInstance type 2. Now go to `/src/server/routes/index.ts`, instantiate the `feature-x` required dependencies like DAL layer and service layer and then pass it to `fastify.register("service,{...dependencies})` -3. With this the service layer will be accessibile inside all routes under fastify service instance. It can be accessed with `server.services..` +3. With this the service layer will be accessible inside all routes under fastify service instance. It can be accessed with `server.services..` ## Writing the routes @@ -70,36 +70,36 @@ The above contains the backend folder structure. All the contribution towards ba - **@types**: The type definition of some libraries like fastify, knex - **db**: Knexjs configuration required for database. Includes migration, seed files and sql type schemas -- **lib**: Stateless reusable functions used throught code base +- **lib**: Stateless reusable functions used through code base - **queue**: Infisical queue system based on bullmq ### Server - Anything related to fastify/service should be scoped inside here. - It contains the routes, fastify plugins, server configurations -- Routes folder contains various version of routes seperated into v1,v2 +- Routes folder contains various version of routes separate into v1,v2 ### Services -- Core bussiness logic for all operations +- Core business logic for all operations - Each service component follows co-location principle that is related things should be kept together - Each service component contains 1. **dal**: The Database Access Layer function that contains all the db operations -2. **service**: The service layer containing all the bussiness logic +2. **service**: The service layer containing all the business logic 3. **type**: The type definition used inside the service component 4. **fns**: Optional component to share reusable functions from a service related to another 5. **queue**: Optional component to put queue specific logic for a component like `secret-queue.ts` ## EE -- Follows same pattern as above with an exception of licensn change from MIT -> Infisical Properitary License +- Follows same pattern as above with an exception of license change from MIT -> Infisical Proprietary License ### Notes - All the services are interconnected at `/src/server/routes/index.ts`. We follow simple dependency injection principle - All files should be in dashcases. - Classes should not be used in codebase. Use simple functions to keep it simple -- All commited code must be linted properly by running `npm run lint:fix` and type checked using `npm run type:check` +- All committed code must be linted properly by running `npm run lint:fix` and type checked using `npm run type:check` - Try to avoid inter service shared logic as much as possible - A controller inside a router component should try to keep it calling only one service layer. This rule could have exception when another service like `audit-log` needs access to request object data. Then controller will call both the functions diff --git a/backend/docs/guide/folder-structure.md b/backend/docs/guide/folder-structure.md index a86700106..6b2af0487 100644 --- a/backend/docs/guide/folder-structure.md +++ b/backend/docs/guide/folder-structure.md @@ -45,37 +45,37 @@ The above contains the backend folder structure. All the contribution towards ba - **@types**: The type definition of some libraries like fastify, knex - **db**: Knexjs configuration required for database. Includes migration, seed files and sql type schemas -- **lib**: Stateless reusable functions used throught code base +- **lib**: Stateless reusable functions used through code base - **queue**: Infisical queue system based on bullmq ### Server - Anything related to fastify/service should be scoped inside here. - It contains the routes, fastify plugins, server configurations -- Routes folder contains various version of routes seperated into v1,v2 +- Routes folder contains various version of routes separate into v1,v2 ### Services -- Core bussiness logic for all operations +- Core business logic for all operations - Each service component follows co-location principle that is related things should be kept together - Each service component contains 1. **dal**: The Database Access Layer function that contains all the db operations -2. **service**: The service layer containing all the bussiness logic +2. **service**: The service layer containing all the business logic 3. **type**: The type definition used inside the service component 4. **fns**: Optional component to share reusable functions from a service related to another 5. **queue**: Optional component to put queue specific logic for a component like `secret-queue.ts` ## EE -- Follows same pattern as above with an exception of licensn change from MIT -> Infisical Properitary License +- Follows same pattern as above with an exception of license change from MIT -> Infisical Proprietary License ### Notes - All the services are interconnected at `/src/server/routes/index.ts`. We follow simple dependency injection principle - All files should be in dashcases. - Classes should not be used in codebase. Use simple functions to keep it simple -- All commited code must be linted properly by running `npm run lint:fix` and type checked using `npm run type:check` +- All committed code must be linted properly by running `npm run lint:fix` and type checked using `npm run type:check` - Try to avoid inter service shared logic as much as possible - A controller inside a router component should try to keep it calling only one service layer. This rule could have exception when another service like `audit-log` needs access to request object data. Then controller will call both the functions