Featurevisor v2.0 is here!
Featurevisor v2.0 has arrived - now with improved reactivity for supporting instant realtime updates in your applications covering both frontend and backend use cases.
Existing v1 users of Featurevisor need not worry, because there is a very clear guide below for safely migrating to v2.0 incrementally.
What's new?#
A bunch of new features have made it into v2.0, including:
- Attributes as objects
- New operators for conditions:
- exists / notExists: checks if attribute exists in the context
- includes / notIncludes: checks against array values in the context
- matches / notMatches: checks against regular expressions
- Default variable and variation values when feature is disabled: instead of returning
null, you can now choose what variable and variation values to serve when a feature is disabled - Variation weight overrides per rule: run same a/b test experiment with different variation weights for different rules
- Using hash instead of incremental revision number in datafile: optionally allows you to keep individual datafile content same unless there is any real change, which is useful for caching
- Setting context in SDKs: set/update context in one place, instead of having to pass it for every evaluation (which you still can do, but don't have to)
- Hooks in SDKs: intercepting evaluations and tracking events got more streamlined
- Child SDK instances for server-side context isolation: useful when handling multiple users from the same server in backend applications
- Getting all evaluations together: useful for handing things off from backend to frontend with user awareness, in apps using server-side rendering (SSR)
Breaking changes#
I pushed as hard as I could to improve Featurevisor without breaking anything since v1.0 stable was first released, but some improvements were just too big to fit in the previous architecture limited by the choices made in the past around data structures and APIs.
The breaking changes in v2.0 are kept to a minimum to make it easier for you to upgrade your existing projects, but they do require some changes in your codebase. It's because of them that we can now enjoy much faster evaluations and reactivity.
Notable breaking changes include:#
- Defining features: mainly variable schema and rules
- Building datafiles: v2.0 has a new schema, but you can still build v1-compatible datafiles for backwards compatibility
- Fetching and refreshing datafiles using SDKs
- Experiment activations using SDKs
Backwards compatibility#
Feature management is critical for any organization, and it is understandable that you may be concerned about breaking changes.
That is why, the entire migration is designed to be incremental and fully backwards compatible for existing v1 users.
Migration guide#
The migration process for v1 users can be broken down into two parts:
- Upgrading to latest CLI in your existing Featurevisor project
- Upgrading to latest SDKs in your applications
Once your existing Featurevisor project is migrated to v2.0, you can then move onto your applications for upgrading the SDKs in use at your own pace.
The full migration guide is available here with before/after comparisons.
More SDKs#
The latest JavaScript SDK has become dependency free, which is universal and can be used in any JavaScript environment, including Node.js and browsers.
I built Featurevisor using GitHub Copilot from the very beginning, and now for v2.0 I rewrote the JavaScript SDK so that LLMs can understand it better. This opens up the possibility of creating more SDKs in other languages using AI tools with more ease.
Because of my experience with PHP in the past, I have already created a PHP SDK with all tests passing using Cursor AI, and I will share it with everyone after polishing it up a bit more.
I may do the same for few other languages depending on the time and interest I have in them, but I am keen on the requests coming from real users of Featurevisor.
Higher confidence because of test specs#
It might raise concerns that (partially) AI generated SDKs may not be as reliable as manually written ones. But I must remind you: unlike any other feature management tools, Featurevisor has the concept of test specs which allows testing your own feature configurations against any SDKs from the CLI.
When new SDKs land, they are expected to also have their own test runners. This means you can write tests for your features in a Featurevisor project once, and run them against multiple SDKs to ensure they evaluate the same way everywhere.
No negotiations on quality and confidence here.
Join the project#
If you are eager to join the project by building a new SDK, please get in touch.
Future plans#
I believe v2.0 has wrapped things up very nicely. Besides new SDKs, I don't have any other major short-term plans for Featurevisor v2.x.
The improved architecture is now ready to support more advanced use cases, and I am eager to see how everyone uses it and builds more tools around it, while keeping the core of Featurevisor small and simple.
Like before, I will keep focusing on documentation and examples to help you get the most out of it.
Help spread the word#
One of the best ways to help Featurevisor is to share it with your friends and colleagues. If you find it worthwhile, leave a star on GitHub so more people can discover it.
- The more people engage with the project, the more contributions we can expect.
- The more people come forward as existing users and adopters, the more confidence new users will have.
We can learn together and shape it to serve everyone's needs better this way, that I alone may not be able to do.
That's how Open Source wins.