Closed Badabum closed 1 year ago
@Badabum, thank you for your insights!
I will have to agree, moving to a feature based approach would be better. I was thinking about doing this anyways, so it's good to see I wasn't going down the wrong path. Feel free to make a PR showcasing your idea and I'll review it 🚀
Yet another task I was going to do and another point I agree with you on. Feel free to make this a PR as well :)
I'll be reviewing Refit and taking a look at #25 thank you for the PR!
@wh1337 thx for taking the time to review and reply :) Seem that we found common ground here, closing the issue
Hi, thanks for creating this project!
I'd like discuss the following things about how it's being built:
Project structure. Atm, the main sdk project is structured per item type -
Exceptions
,Models
etc. While it one of the ways to go I believe it's more future-proof to structure it per feature. Example: Imo, this improves cohesion in the code - related pieces live together.Naming and conventions Since this is an SDK I don't think the need to name things with
DTO
suffix. As that is mainly used to separatedomain
entities and public contracts when building services. For example:User
->UserDto
. In case of this sdk types likeSubscriber
are part of the domain of SDK. Also, imo, removingDTO
suffix makes it more readable.RestSharp vs Refit There is a tool called Refit that can be used to do http calls to novu instead of RestSharp. As shown here https://www.reddit.com/r/dotnet/comments/11fcxdx/dotnetbenchmark_refit_vs_restsharp/ it has slightly better performance. Also it uses source generators underneath so removes quite a lot boilerplate code which will reduce the overall size of this sdk.
I'll happily contribute to addressing these 3 topics if they make sense for the team. Cheers