Extend getFeatureToggleDefinitions function in order to support tag filtering about unleash-client-node HOT 4 CLOSED

I'll talk with the team and get back to you soon. Thank you for this clarification. Not having tags on a response that was filtered by tags isn't desirable in REST API convention.

from unleash-client-node.

SDK will fetch definitions and keep it up to date in the background, not when calling instance.getFeatureToggleDefinitions(). You can specify tags on initialization, as explained here: readme#advanced-usage. I hope this covers your use case. We will consider adding tags to the output of feature definitions in the future, so that it's possible to filter it afterwards.

Not closing, because if information is hard to find, we might consider it a documentation bug.
cc @thomasheartman

from unleash-client-node.

Thanks for the answer,

I'm using tags on initialization, this is my case:

I' start the client with this tags: "X", "Y", "Z", then I want to expose a endpoint to retrieve only features for one of them, for example "X", In this scenario I have to get features for "X", "Y", "Z" and after that I'm filtering using a prefix in the name.

What do you recommend do? Should I initialize one client by tag? still filtering by substring in the name? or in this endpoint call the http API?

Thanks again :D

from unleash-client-node.

Hi @Gaspar1234

Yes, you can instantiate different clients with different tag configurations to achieve what you want. If you instantiate them in the same context in your application and use the same refreshInterval they should be able to stay in sync with negligible difference.

If you are using the pro / enterprise version you could group the feature toggles in a project and use the project name to filter the toggles.

It would be interesting to learn more about your use-case and architecture. Would you have time to flesh out your example?

from unleash-client-node.