Nestjs application structure for developing phase

Question

Some context

I am working on my first nestjs project for school. I work on the backend part of the project. To sum it up it's an online game on which users can play and chat, set informations about their account, add friends in a list, see a leaderboard etc...

The only way to log on it is though out school's OAuth. User can't log with email/password.

Issue

So right at the beginning while developing the first routes for: authentification, account information retrieval, logging out, friends list etc... I face an issue to test features. I only have one account in the school's OAuth, so I can't test many things like adding a friend, since it required other account to exist in the database.

My naive approach

• I made "debug routes" to add/remove/update user batches, so I can make request to populate and modify my database with (many) fake accounts.

• I made a "debug Guard" which forbid access to these routes outside of development mode (as everything runs inside a docker container, it relies on environnement variable)

Of course the database for development phase is not the same as for production: sqlite for dev/test and postgresql for production.

My question

How would you structure your app for these kind of features ?

I might need to manage these fake accounts during the whole development phase, in real life application I would probably not get rid of these routes even after deployment since future developments would require them.

• Would you separate these development feature/routes in their own controller ? module ? service ?
• or keep them with their related feature (add_user_batch in the user service for example)
• security wise, is the guard enough ? These routes are really dangerous since accessing them would put at risk all accounts, yet they are useful in the whole life cycle of the application's development.

Thanks a lot for you views on that.

Answer 1

I would have implemented my own authentication guard for new users, keeping the the school's OAuth account just for administration actions (so this user could basically access all the application routes), while providing a public route allowing new users to sign up to the application. This endpoint will register the user to the database along with provided credentials for the access (remember to hash the password before saving on DB). Then I would have two login endpoints:

• one for the OAuth login
• one for the user login that signs a JWT and returns it to the caller

(or you can also have one and find a way to understand if the user requesting access is the admin or not, you decide)

Then I would have developed two guards:

• one for the OAuth access
• one for the JWT one

and putting the JWT guard only to non-administration routes.

Here you can find documentation about JWT authentication on Nestjs server.