This post is in response to deprecating the Spark.js library today. I just tried to post this in response to one of the issues, but am unable since the issue tracker was removed for the library.
I get that y’all are deprecating this library so you’re going to close all of the issues for this repo anyway, but this issue wasn’t actually addressed. We don’t know if the proposed action — adding an endpoint where you can validate an access token — is ever going to be addressed since no link was posted.
I also wish y’all had engaged the community while writing the new library. I get that it’s not like this library is deleted and now unobtainable, but it’s really annoying to have a deprecation dropped on you without any warning for one of your dependencies. Additionally, writing a new version of a library without asking for input from the people who use it in production also comes across as arrogant.
Again, I get it — it’s a small library, and I’m sure you discussed it internally and worked hard on it. Doesn’t feel good from my end though.
I’m very frustrated that the issue tracker was taken down as well. Aside from having a transition period to ease the difficulties of discovering and using the new library, there are good reasons why you’d want to reference old issues. Removing old discussions is often never a good idea, especially without advanced warning.
I'm sorry the deprecation was a surprise. Spark.js has received very little attention in the last year, and we thought it better to move forward with a new library because renaming needed to happen anyways. I would love to hear your feedback on how we can handle this better in the future.
Because an access token can expire at any time, the only way to validate a token is to try and use it. If there was an endpoint to validate an access token, it could return "yes, valid", the token could expire immediately after, and then when you try to use the token, it does not work.
We are always open to feedback about design and implementation. Please file issues on particle-api-js if you ideas/concerns.
I can re-instate the issue tracker. It was taken down only to prevent users from filing new issues and wondering why nobody is responding. (GitHub does not let your turn off new issues without turning Issues off completely).
You could add a file ISSUE_TEMPLATE.md to the root of the deprecated repo with a message saying "Please do not file new issues for this repository as it is no longer maintained. Migrate to library xyz". This message will pre-populate the new issues box so people will see it when trying to report new issues.
Advance warning. I get emails from SalesForce 6 months out about when they're deprecating APIs and we barely use them as more than a glorified spreadsheet. We depend on Spark.js day in and day out. Email out, post it on the Community, repeatedly, as the date approaches. Annoyed >>> uninformed.
Upgrading examples. "Here's what your old code probably looks like, and here are the changes you would make". Blog post or even a forum topic would do fine.
Clarity and visibility on the work being done. Some ways to do this are through issue milestones on GitHub, including it in the README.md or Contributing.md files in the new repo itself, or again, forum posts. Pro-actively asking for eyes on the work and being receptive to opinion and feedback.
If the Particle API had an endpoint that not only validated a token but included the token's expiration date in its response, that would be very, very helpful. We could design our systems to warn us when using a token that is close to expiring. And I still assert that checking a token's validity on startup instead of failing on the first call is a much better system behavior.
It's one thing to be open to it, it's another thing to ask for it, proactively want it. I'll certainly open issues and make pull requests on the new library, because it's code that I use every day and therefore I'm responsible for it, but this has been a pattern over the past year and change of being on the Particle platform. My team and I don't feel that our feedback or contributions have been welcomed when brought up.
When you create the access token, the response does include how long the token is valid for (reference). I don't know if that helps solve your issue or not.
I will add your feedback about wanting an endpoint for token information. I need to discuss it with the team about whether there are security implications.
Instead of needing a specific endpoint to do this, you can make any API call on startup that does not change anything (ex. GET /v1/devices).
Awesome.
Can you point me to specific instances (privately if need be)? I'd like to review them to see how the team can improve on soliciting and working with feedback/contributions.
Yup, I'm aware. If a token is being reused though, it's difficult to keep track of the metadata every time it's used.
Instead of needing a specific endpoint to do this, you can make any API call on startup that does not change anything (ex. GET /v1/devices).
Yup, I'm aware, I've been using that endpoint. When there's a few thousand devices though it's inefficient to be fetching all that data. It'd be nice if calling login with the token decrypted it, and sent it back with the expiration data.
As far as improving collaboration between our teams, we had a really productive call with Jon Logan and David Middlecamp a couple weeks ago that resolved several things. Thanks for your offer though. And as always, thanks to you and the rest of the Particle engineers for your hard work.