NestJS - Admin API and Customer API structure

[misty folio]

Hi everyone,
I'm currently working on a larger application using NestJS for now everything was going fine but since the project is getting larger and larger and I'm a the only developer working on it I'm at a decision point where I need to find the best way to structure my application modules and etc.

To give you a bit of a background, since I inherited the project which was initially set that it has the following structure:

- /admin -> contains APIs for managing different resources and is behind a AWS Cognito JWT
- /client -> contains API that is accessible to client applications 
- /shared -> contains types and interfaces

Now, a problem I'm currently having is that both admin/client do indeed share some services and as an example I can give is that we can have a post.service.ts.

The admin will have the following capabilities:

• List posts
• Approve posts
• Reject posts

The client will have the following capabilities:

• Create posts
• Delete posts
• Edit posts
• Delete posts

Now, if both APIs would have the same response DTO it would be an easy decision where I would have a guard where I would limit actions based on some property on a user which is making the request.

But, both admin and client have different DTOs, as an example
the Admin API would have fields like:

• approvement status (accepted/rejected)
• additional information about the user (e.g. isSuspended)

The client API would return:

• number of comments
• reactions
• etc.

How would be the best way to structure the folders, mappers and etc?

[midnight lion]

Single module is ok. Don't bother with that too much. Best structure comes with some real needs. If you don't have any and you are working on it alone it's better to postpone such decisions

[royal marlin]

Think of the work being done as processes to change state or processes to request data. If the process is different, it requires a different service and route to that service. So, you noted approvals and rejections of a post. That is a process for changing state. It needs its own route and service(s). Once you have that understanding, then it is a matter of allowing admins in that route and no one else. As for to modularize that feature or not, it is usually better to keep related features in the same module. But, if the module itself is getting too unwieldy, you could break out sub-features into their own sub-modules. Or, if you see a set of features getting their own "world" of work that needs separation, you might create a brand new module.

[misty folio]

Thanks for the advice both of you 🙏
I thought I would get a notification if someone commented but it seems I have them disabled so that's why I'm replying late 😄