Hi James! Well done! I feel like more tools and clients will appear this year :-)
The great thing about having a public API is to witness what the community will come up with! I remember Ben saying they will likely open up the API in 2019 so hold tight :D
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.
It isn't yet up on Nuget - it might be better under a Dev.to managed Nuget account. Maybe even have the repo on Github under Dev.to's account? Happy to help maintain it as an "official" repo. 🙂
Usually the things go in the other direction in open source. A third party library pops up, it gets used by many people and form a community around it and then possibly it gets "officially" adopted by the mother project, or at least endorsed on their GitHub page.
A couple of examples: Python's json and multiprocessing were added way back in 2008 to the standard library because the respective third party projects (simplejson and multiprocessing) were used by everyone and it made sense to make them part of the language. Ruby's arel was heavily used by Rails and a ton of other projects for many years before Rails officially decided to adopt it and move it under its umbrella.
This is mainly because "adopting" third party code is always a gamble. You have to have intimate knowledge of the project, a few successful use cases, a very active maintainer and a developed community. It's not your case because you just started but when you adopt a third party library you also adopt its issues and technical debt. Playing devil's advocate: what happens if a maintainer gets bored after six months? The core team implicitly takes a vow to be on top of the library no matter what. We all know how hard it is to be on top of open source projects :-) Another helpful thing is usually competition, there are a ton of JSON libraries for Python :D
In the meantime my suggestion is: work on it, publish it, document it, add the missing endpoints little by little and attract a community around it, so it becomes the .NET library to interact with dev.to, you don't need an official sigil ;-)
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.
Hi James! Well done! I feel like more tools and clients will appear this year :-)
The great thing about having a public API is to witness what the community will come up with! I remember Ben saying they will likely open up the API in 2019 so hold tight :D
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.
Usually the things go in the other direction in open source. A third party library pops up, it gets used by many people and form a community around it and then possibly it gets "officially" adopted by the mother project, or at least endorsed on their GitHub page.
A couple of examples: Python's json and multiprocessing were added way back in 2008 to the standard library because the respective third party projects (simplejson and multiprocessing) were used by everyone and it made sense to make them part of the language. Ruby's arel was heavily used by Rails and a ton of other projects for many years before Rails officially decided to adopt it and move it under its umbrella.
This is mainly because "adopting" third party code is always a gamble. You have to have intimate knowledge of the project, a few successful use cases, a very active maintainer and a developed community. It's not your case because you just started but when you adopt a third party library you also adopt its issues and technical debt. Playing devil's advocate: what happens if a maintainer gets bored after six months? The core team implicitly takes a vow to be on top of the library no matter what. We all know how hard it is to be on top of open source projects :-) Another helpful thing is usually competition, there are a ton of JSON libraries for Python :D
In the meantime my suggestion is: work on it, publish it, document it, add the missing endpoints little by little and attract a community around it, so it becomes the .NET library to interact with dev.to, you don't need an official sigil ;-)
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!