[Backend] Add feature: manage subscriptions

[rasouza]

⚠️ Builds are green even though it shows ❌. We need to connect to Nx Cloud once again or move to Turborepo

Description

• Implement /subscriptions RESTful resources
• Improve unit testing by implementing automock
• Add global error handler
• Add Zod serializer
• Update package.json to ensure volta can fetch the correct tools from monorepo

Motivation and Context

Unit testing with automock

We no longer need to recreate the app module during unit tests anymore (see here). Easier to mock and write tests. You can still retrieve any dependency with unit and unitRef (official doc)

Zod serializer

You can think of this as the Presenter layer of the Clean Architecture. In short, neither controller nor services should be in charge of presenting the response payload to clients. Instead, we introduce tools to make it easier to present the response the way we need, hence the Serializers.

NestJS has a builtin for that as well (doc), but since we are using Zod and it has support for serializing, we can stick to that lib

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[mathiasberggren]

Is there a reason why we name these with camelCase and map them to a snakeCase? Similar to how we do with DTO's in Klarna to validate when data is confirmed to be type safe?

[rasouza]

Oof nice catch! This is because databases usually has a different naming convention (plural and snake_case) from JS naming convention (singular and camelCase) and we want both to coexist.

This is described in more details in this Prisma doc. Schema file gets a little bit more verbose but code and database is standardized in a nice way

In short, in the left you read as field names while coding (client generated by Prisma) and on the right (the @Map field) is how you will see in the database tables

[mathiasberggren]

So what we're doing here is basically addding a validation middleware of the incoming payload? Or?

[rasouza]

incoming payload validation would be the block above (APP_PIPE and ZodValidationPipe), this one is about how you want response payload to be shown

[mathiasberggren]

So if I understood correctly this is an error handling middleware?

[rasouza]

Precisely! The framework has a nice built-in global error handler already, but it was omitting errors from Zod schemas. I had no idea what was failing so I wrote another one myself, just to console.log the error

In the end, it helped me to identify that I was typing .optional() instead of .nullable()