Why is there only (1) API project, and not (4) API projects with (1) per module?

[jeffward01]

Hello!

I wanted to ask from an architecture perspective, why was this project designed with only (1) API project, which also functions as the 'bootstrap' or 'startup' project.

Wouldn't it be better if the project structure was changed so that each module also had its own set of API endpoints?

I suppose that perhaps authentication could become a concern, but then in that case, wouldn't it make sense to use something like YARP to serve as the API Gateway (similar to Ocelot before it was depreciated), then server API requests to each of the endpoints?

My point is that its a massive dependency having each module API implementation located in essentially the 'bootstrap' / 'startup' project. It would be more modular if each module had its own API implementation.

---

Perhaps I am missing something, or that it over complicates things for little benefit - im just curious to see what other people think about this topic

Thanks all

[philomela]

Hello!
I think there is no point in splitting into several api, this will complicate support, using the api gateway pattern with ocelot or similar things will also complicate development in part, also new difficulties will be added in terms of authentication, as you noticed. Nothing prevents you from using different controllers for each module separately, the application is still a modular monolith and does not use a microservice architecture approach, you can see an example with authentication and several APIs here: https://github.com/philomela/PopMe

[kacey90]

Hi. That would then be a microservice architecture which goes against the purpose of the project. It's a monolith with a modular architecture.

[philomela]

I wrote this)