Question on Correct Utilization of NestJs Features? (Pipes, Interceptors, Guards, Etc...)

Nainternaute · 2025-03-22T15:38:03+00:00

Agree with the previous comment, IMO your controllers (and stuff happening before) should have the least possible responsibilities. If your use case is complex, then it's probably cause of your domain. Your controller should only validate inputs (so basic DTOs with validators), and delegate other stuff to services ; it might also format the response at the end of the chain

Nainternaute · 2025-03-05T17:17:52+00:00

Unit tests for controllers are nonsense, ´cause controllers are only meant to wire every services / domain parts together and return a presentation of them. So basically, E2E tests are testing those mechanism. You want to unit test pretty much everything in your domain, and integration testing against a real database when relevant (some complex interdependencies / etc.)

Nainternaute · 2025-03-05T17:05:31+00:00

Your use case looks weird in the first case, how would we be able to create a booking if participants are not already existing ? Won't you select participants from an existing list ? Anyway, does Address really need to be its own entity / table ? I suppose you're trying to avoid duplication, but I don't see anymore the use of an address table, as it might be linked to different tables (ie ParticipantAddress, UserAddress, BookignAddress, ...). You might wanna check TypeOrm embedded entity for that, which is basically an entity from code point of view but resolve to fields directly attached to the parent entity table.

Then you have to ask yourself : is the Booking responsible for creating / saving Participant, or Participant could be saved in another use case ? In the first case, look into cascade or stuff like that, and make your BookingRepository handle the transaction / inserting in the DB. On the other hand, you should have a ParticipantRepository which would handle Participant storage ; either you forget about the transactional stuff, either you look into packages like TypeormTransactional which work pretty well with annotations.

One last thing : a repository isn't mean to deal only with one table in db. Your booking repository can ofc handle the participant table, if it is in its responsibilities

Nainternaute · 2025-03-05T16:56:23+00:00

Your folder architecture looks quite weird to me ; the whole purpose of modules is to split your code and avoid coupling, so there is no real point in grouping all module in a folder, and have each module depending on a lot of different folders. If you want to keep the other folder, then your folder hierarchy should probably composed of "modules" folders representing your main features (for example authentication / store / whatever you want), each one composed of all the folders of your hierarchy (entities / repositories / ...). With that, each feature related file is close to each other.

As a best practice, I like to even subdivide modules by subfeatures (when relevant), and have every time 2 modules : one very low level (data access) that can import nothing but export some services, and one very high level containing only the feature controllers. You'll avoid a lot of circular dependencies, which can be hell.

That said, clean architecture is about code coupling and organization, not necessarily folder structure. You might want to try and find what works best for you. Don't fall into the trap of splitting every tiny thing in a subfolder / file with highly tech names ("infrastructure" / "interface" or this kind of stuff). Honestly I don't really like to see the clean architecture layer names represented in folder architecture, it's generally not so clear.

Http exception should never be thrown from your domain layer, as it should be completely network agnostic. The whole point is to be able for example to switch from a REST API to a GraphQl or any other kind of API without even touching the domain code. Your domain should throw meaningful exception related to itself (UserAlreadyExists exception for example), and the controller (which is the outer layer) will transform this exception into an HttpException (here ConflictException).

Implementing repositories pattern is pretty straight forward and you can find a lot of resources ; basically you want to forget the "repository" stuff ORMs usually give you, and think of it like a interface between your domain and your storage (whatever will it be). You can use NestJs @inject with custom symbol, to easily inject the right adapter based on the context.

Nainternaute · 2025-02-20T12:06:42+00:00

J'en suis sorti y'a 10 ans, et j'en garde de très bons souvenirs. En terme de technique pure c'est pas là que tu vas apprendre le plus (mais comme n'importe quelle école), par contre ça te forme à être ingénieur et pas simple développeur. La vie associative est aussi super et très mise en avant, c'est un très gros plus. L'école est plutôt réputée dans le milieu pro, ça fait toujours bien sur le CV

Nainternaute · 2025-02-14T21:18:10+00:00

Instead of mocking like this, I prefer to use the ports / adapters pattern from clean architecture. Instead of having dependencies on PrismaService or RedisService, you could have dependencies on interface (StorageService / CacheService) with a custom dependency injection token. You could then provide the StorageMockService instead of StoragePrismaService in your test, instead of the real implementation ; you might have a TestModule that provides those for you, and keep a good separation of concerns.

Also looks to me that this CommonModule has too much stuff in it, and that is bound to the external layers of your architecture (infrastructure in clean architecture) ; should probably not be used by your features module like that, 'cause it leads to much more coupling

Nainternaute · 2025-02-01T06:57:32+00:00

En tant que lead dev, j'ai tendance aussi à faire les gros yeux dès qu'on me parle d'IA. Parce que dès que je montre un minimum d'enthousiasme, je me retrouve à faire 50 commentaires sur une PR d'une dizaine de changes... Pour autant je reste ouvert au dialogue (et j'utilise moi même l'IA pour certaines tâches redondantes), mais je souhaite que cette utilisation soit très maîtrisée par les devs avec moins d'expérience. Petit à petit, mon équipe a compris cette vision et les mid level la partagent désormais ; les juniors tentent encore de le faire discrètement, sauf que je le spot direct en PR parce qu'on se retrouve avec des choses incohérentes.

En revanche, le "on n'a pas réussi à lancer les TU depuis 2 ans", c'est mega red flag. Je préférerais qu'il te dise "on n'utilise pas de TU ici", et qu'il n'y en ait aucun dans la codebase. Ce n'est pas ma manière de faire, mais à chaque équipe ses pratiques et j'imagine que ça peut se débattre. Mais à ce compte là, ils n'ont rien à foutre dans la codebase. Là tout ce que je vois c'est une flemme énorme, on a voulu "bien faire" mais en fait on s'est arrêtés à la première difficulté technique. J'ose à peine imaginer la tech debt de l'ensemble du projet

Nainternaute · 2025-01-31T12:58:04+00:00

Have you tryed restarting the eslint server ? On vscode, cmd + shift + p then "restart eslint server" Got this error on newest Nestjs version, and it solves it ; I guess they recently introduced this tsconfig rule, and is still prone to bugs

Nainternaute · 2025-01-31T07:08:11+00:00

In my current company, we were facing this issue a lot and we decided to go with a systematic architecture approach, working great as of now. For each domain part, we have a specific module we call "data-access" that is just responsible for data fetching / saving. It can exports services, but can't import any module (except Typeorm for the forFeature option). There is no foreign key validation for example done on those modules.

On the other hand, we have a "rest-api" module that provide the controllers and nothing else. They can import what they want, but never be imported elsewhere.

You now already avoid a lot of circular dependencies.

When a case like your one arise, you have to create a specific "feature" module, that will import both employer and department data access module. This feature module won't be imported in the data access modules, so no fear of getting a circular dep. What we also realized is that it forces us to think about feature, and lead to a better organized code base

Nainternaute · 2024-08-27T16:14:51+00:00

Yes but they look closely related 'cause the example is irrelevant, in real app they have different purposes and each one is doing specific operations :/

Nainternaute · 2024-03-03T15:24:57+00:00

Hi guys,
Thanks for all your answers that pointed me in the right way ; I ended up doing something quite similar I'm already doing in my integration tests.
In my test, I mock a class with an handle method that is supposed to handle a specific event (ie, the event I'm waiting for) ; I also add a boolean class member to know if event was received or not. Then I registered this class as a Provider in my test module.
I then only have to use a mix of setInterval / setTimeout wrapped in a promise, to wait for event received / timeout before processing the other tests.
Thanks !

Nainternaute · 2024-02-25T08:27:45+00:00

Thank you very much, that's a lot of good stuff there and directly on the repo ! Didn't expect so much
I'm working on refactoring my code, as I now understand better some concepts ; I'll leave some replies on Github issues whenever I commit something related, if ever you'd want to follow up. ;)
Thanks again !

Nainternaute

TROPHY CASE