15 sats \ 2 replies \ @WeAreAllSatoshi 9 Feb 2023 freebie \ on: Need feedback on product - Speed ( www.tryspeed.com ) bitcoin
Why is this the case? And why publish the package to npm if you require everyone to load it from your hosted CDN instead of self-hosting?
Is this the case so you can publish updates to the package and automatically have consumers use it? Treating it more like a SaaS module could be useful, but that doesn’t really follow the established paradigm of allowing consumers to pin to a version of the library.
This also means you can’t ever have breaking changes in the library since every consumer will always pull the latest published version. As an engineer integrating this library into an e-commerce application, this would concern me.
@038bb3c3cb
We put it on our CDN so we can keep it updated with new releases and provide the latest versions. Most of the updates we make to Speed.js don't change are backward compatible, so even if you're using an old version, your application won't break. The same is true for our APIs.
I'm sorry if I couldn't fully answer your question, but I'll have my engineering team take a look and provide more information.
Are you thinking of using it for an eCommerce store? If so, we'd love to invite you to our Slack channel to chat with our engineering team.
Every customer is important to us!
reply
Thanks for the response.
We put it on our CDN so we can keep it updated with new releases and provide the latest versions.
Making it available on a CDN makes perfect sense. I think what’s missing is a way to request an exact version of the library from the CDN.
For example, right now I can load the library from https://js.tryspeed.com/, which presumably will always provide the latest version.
What if I want to affix myself to a certain version for stability reasons? I should be able to load from something like https://js.tryspeed.com/v1.0.1.
Forcing your consumers to always load the latest version means they’re at your mercy for when updates are deployed.
It’s very common for engineering teams to update their dependencies in a controlled manner so they can verify functionality remains intact before making it available to their customers. What’s described above doesn’t allow that to happen.
Most of the updates we make to Speed.js don't change are backward compatible, so even if you're using an old version, your application won't break. The same is true for our APIs.
I know you said most of your updates don’t break backwards compatibility, but that most needs to be all in this situation.
Also, how would anyone be using an old version if you only supply the latest?
I’m not trying to grill you too hard here, I’m just sharing my thoughts on this so you can provide the best developer experience.
I'm sorry if I couldn't fully answer your question, but I'll have my engineering team take a look and provide more information.
Sounds good!
Are you thinking of using it for an eCommerce store? If so, we'd love to invite you to our Slack channel to chat with our engineering team.
I’m not, I’m just an engineer who reads SN :)
reply