-
Notifications
You must be signed in to change notification settings - Fork 65
Why does the variation api have to be async? #125
Comments
The reason is that calling |
And the reason that that's not the case in the client-side JS SDK is that it always stores its flag data in memory, so it never needs to do I/O for |
I see, so it’s easier to make it all async even though the in-memory version could technically be synchronous. Well, it does make it a bit harder in my opinion but it’s really not such a big deal. Looking forward to testing out launchdarkly :). Thanks for your answer. |
Would it make sense to ever split these out into two apis? So you would call
or just
|
Well, we can't change the name of the existing async method without breaking things for existing users, but as far adding another method— what I would worry about is that then the logic that uses the service would be very closely tied to the logic that configures the service, that is, if you started developing with an in-memory store and then wanted to migrate to using a Redis store, you would have to rewrite everything quite a bit. But we'll consider it. |
bump jest version to stop vulnerability warning
Hi, this is more of a question. I noticed that other SDKs are synchronous when calling
.variation()
including the client side javascript library. Is there a functional reason the node version has to be async?I would like to be able to use the node client like this instead.
Having the
variation
API be async and forcing usage of a callback and promise makes it harder to adopt in my opinion.The text was updated successfully, but these errors were encountered: