A technical question: the fact that it's async means that the whole app has to be async? I'm not familiar with modern .NET.
Any code that calls the library should be async though it is technically possible to avoid it (but it isn't recommended). Any other code that doesn't call the API doesn't need to be async though.
With everything else you mentioned, I do understand where you are coming from. In my experience, I have seen libraries written and published then repository names change, package names change, links broken etc from this type of action changing in the future. I want to avoid all that future mess and have where I would consider the final location etc.
If it was an "official" package, probably would be able to work a bit closer with the API devs to make sure I have the current and future functionality covered in a timely manner.
As I imagine this will be one of several libraries across several languages that will be written for dev.to, I want to make sure I work with whomever to make sure that the experience is consistent.
That said, you're right, I should keep documenting and publish what I have now so people can consume it regardless. 🙂
Any code that calls the library should be async though it is technically possible to avoid it (but it isn't recommended). Any other code that doesn't call the API doesn't need to be async though.
Thanks Rhymes!
Any code that calls the library should be async though it is technically possible to avoid it (but it isn't recommended). Any other code that doesn't call the API doesn't need to be async though.
With everything else you mentioned, I do understand where you are coming from. In my experience, I have seen libraries written and published then repository names change, package names change, links broken etc from this type of action changing in the future. I want to avoid all that future mess and have where I would consider the final location etc.
If it was an "official" package, probably would be able to work a bit closer with the API devs to make sure I have the current and future functionality covered in a timely manner.
As I imagine this will be one of several libraries across several languages that will be written for dev.to, I want to make sure I work with whomever to make sure that the experience is consistent.
That said, you're right, I should keep documenting and publish what I have now so people can consume it regardless. 🙂
Got it, it works like everywhere else :D
BTW, I've put it on NuGet like you suggested 🙂
nuget.org/packages/DevTo.Api/
Well done!