search

proudmonkey / ApiBoilerPlate

A simple yet organized project template for building ASP.NET Core APIs in .NET Core 3.1
MIT License
362 stars 76 forks source link

Suggestion for new version #17

Open improwise opened 3 years ago

improwise commented 3 years ago

Some personal opinions after having used this template for a new API.

For the new version of this BoilerPlate I would suggest not including so much "extras", at least not extras that are enabled by default. While it might be useful, it has the side effect of turning this boilerplate template more into a code sample/tutorial than something you can use to get a quick start. This as you would have to spend about as much time trying to understand how those extras work as well as removing them if you don't use it, as it would take to configure a new API from scratch and configure health checks etc.

I think this might turn away potential users of this excellent template, that really offers a lot of value. Well, that's my personal opinions, others might disagree :)

proudmonkey commented 3 years ago

Thank you for the feedback! Could you please list the features that you think not necessary? The core features in the template are something that an API should have but you could customize it to however you like. I included them because others might find it useful. I also included a sample documentation how this template works for reference so users won't get lost.

improwise commented 3 years ago

Well, always opinionated of course but I would probably remove the OAuth/SampleAPI altogether, or perhaps make it an option when running the template. While it is useful to have for some, I think that most users of the template probably would not be calling any additional APIs with OAuth credentials and instead end up with an API that might be a bit more complex than needed. I'm also guessing that as more complex the needs are, chances are probably greater that you might start from scratch anyway.

Now, I do appreciate that there is sample code for this provided, so its more if it should be included and enabled by default.

Well, those are my thoughts :) Thanks!

proudmonkey commented 3 years ago

Thank you for your inputs. I appreaciate it. What interests me is that when I initially released the template - it just contain the basic stuff, but alot of people were requesting to include stuff like Auth, Healthchecks etc.. - main reason why v2 was created.

or perhaps make it an option when running the template

I'll see what I can do. :)

workcontrolgit commented 3 years ago

@proudmonkey - your template is packed with all the enterprise features. It saves time when scaffolding a robust WebAPI project. Many thanks.

Please consider integration with Ocelot to support API gateway. Ocelot will communicate with IdentityServer instead of the individual API project. For project code structure, it would make it easier to find source code using the structure of CleanArchitecture where source code is organized into Application, Domain, Infrastructure, and WebAPI projects.

Again thank you for your awesome template.

proudmonkey commented 3 years ago

@workcontrolgit Thank you for your interest on this project. I appreciate it. This template is another opinionated implementation for someone who want to spin up an API without using clean architechture. It's on my to-do list to create a separate API template that follows Clean Arch. Definitely, ocelot is a great feature to add.

Thanks!

biapar commented 3 years ago

I think that is better to not introduce other stuff. The Ocelot can be added by people if needed.

improwise commented 3 years ago

I think that is better to not introduce other stuff. The Ocelot can be added by people if needed.

I agree for the same reasons I created this ticket.

biapar commented 3 years ago

I started a project with a template but there was a lot of stuff that complicated the things and overload all. I found this one and it's near CleanArch...and it's clean. I like to have the control.

workcontrolgit commented 3 years ago

Use case: suppose you have 5 API Resources and 10 client apps. You can run one instant of Id4 and one instant of Ocelot to manage and control access to 5 API Resources and 10 client apps. It will be great to have a template for rapid prototype Api Resources. Ideally, there is an interface design to allow Api Resource to be quickly integrated with a token service such as Id4 and a web API gateway such as Ocelot. It is not desirable to wire in additional code into the template to implement the token service or gateway functionalities.

@proudmonkey - I put together a skeleton Api Resource project where source code is organized into four projects core, application, infrastructure, and web API (following clean architecture Onion view). I would love to hear your thought on the architecture approach. The template does not have all the enterprise extensions that your template generated. I have evaluated several templates and found a clean architecture template that has a good source code structure. I adopted the structure, however, instead of using EF and CQRS, I implemented the project with Dapper, SqlKata, and Repository/UnitofWork.