9ecd81ebb4
This change fixes the OpenAPI schema to disallow non-string properties on the top level of the context (except, of course, the `properties` object). This means that we'll no longer be seeing issues with rendering invalid contexts, because we don't accept them in the first place. This solution comes with some tradeoffs discussed in the [PR](https://github.com/Unleash/unleash/pull/6676). Following on from that, this solution isn't optimal, but it's a good stop gap. A better solution (proposed in the PR discussion) has been added as an idea for future projects. The bulk of the discussion around the solution is included here for reference: @kwasniew: Was it possible to pass non string properties with our UI before? Is there a chance that something will break after this change? @thomasheartman: Good question and good looking out 😄 You **could** pass non-string, top-level properties into the API before. In other words, this would be allowed: ```js { appName: "my-app", nested: { object: "accepted" } } ``` But notably, non-string values under `properties` would **not** be accepted: ```js { appName: "my-app", properties: { nested: { object: "not accepted" } } } ``` **However**, the values would not contribute to the evaluation of any constraints (because their type is invalid), so they would effectively be ignored. Now, however, you'll instead get a 400 saying that the "nested" value must be a string. I would consider this a bug fix because: - if you sent a nested object before, it was most likely an oversight - if you sent the nested object on purpose, expecting it to work, you would be perplexed as to why it didn't work, as the API accepted it happily Furthermore, the UI will also tell you that the property must be a string now if you try to do it from the UI. On the other hand, this does mean that while you could send absolute garbage in before and we would just ignore it, we don't do that anymore. This does go against how we allow you to send anything for pretty much all other objects in our API. However, the SDK context is special. Arbitrary keys aren't ignored, they're actually part of the context itself and as such should have a valid value. So if anything breaks, I think it breaks in a way that tells you why something wasn't working before. However, I'd love to hear your take on it and we can re-evaluate whether this is the right fix, if you think it isn't. @kwasniew: Coming from the https://en.wikipedia.org/wiki/Robustness_principle mindset I'm thinking if ignoring the fields that are incorrect wouldn't be a better option. So we'd accept incorrect value and drop it instead of: * failing with client error (as this PR) or * saving incorrect value (as previous code we had) @thomasheartman: Yeah, I considered that too. In fact, that was my initial idea (for the reason you stated). However, there's a couple tradeoffs here (as always): 1. If we just ignore those values, the end user doesn't know what's happened unless they go and dig through the responses. And even then, they don't necessarily know why the value is gone. 2. As mentioned, for the context, arbitrary keys can't be ignored, because we use them to build the context. In other words, they're actually invalid input. Now, I agree that you should be liberal in what you accept and try to handle things gracefully, but that means you need to have a sensible default to fall back to. Or, to quote the Wikipedia article (selectively; with added emphasis): > programs that receive messages should accept non-conformant input **as long as the meaning is clear**. In this case, the meaning isn't clear when you send extra context values that aren't strings. For instance, what's the meaning here: ```js { appName: "my-app", nested: { object: "accepted", more: { further: "nesting" } } } ``` If you were trying to use the `nested` value as an object, then that won't work. Ideally, you should be alerted. Should we "unwind" the object and add all string keys as context values? That doesn't sound very feasible **or** necessarily like the right thing. Did you just intend to use the `appName` and for the `nested` object to be ignored? And it's because of this caveat that I'm not convinced just ignoring the keys are the right thing to do. Because if you do, the user never knows they were ignored or why. ---- **However**, I'd be in favor of ignoring they keys if we could **also** give the users warnings at the same time. (Something like what we do in the CR api, right? Success with warnings?) If we can tell the user that "we ignored the `a`, `b`, and `c` keys in the context you sent because they are invalid values. Here is the result of the evaluation without taking those keys into account: [...]", then I think that's the ideal solution. But of course, the tradeoff is that that increases the complexity of the API and the complexity of the task. It also requires UI adjustments etc. This means that it's not a simple fix anymore, but more of a mini-project. But, in the spirit of the playground, I think it would be a worthwhile thing to do because it helps people learn and understand how Unleash works. |
||
|---|---|---|
| .do | ||
| .floe | ||
| .github | ||
| .husky | ||
| .vscode | ||
| coverage | ||
| docker | ||
| docs/api/oas | ||
| examples | ||
| frontend | ||
| perf | ||
| scripts | ||
| src | ||
| test-migrations | ||
| website | ||
| .dockerignore | ||
| .editorconfig | ||
| .gitignore | ||
| .lycheeignore | ||
| .mergify.yml | ||
| .node-version | ||
| .nvmrc | ||
| app.json | ||
| biome.json | ||
| CHANGELOG.md | ||
| cliff.toml | ||
| CODE_OF_CONDUCT.md | ||
| CODEOWNERS | ||
| CONTRIBUTING.md | ||
| docker-compose.yml | ||
| Dockerfile | ||
| LICENSE | ||
| package.json | ||
| README.md | ||
| renovate.json | ||
| tsconfig.json | ||
| USERS.md | ||
| yarn.lock | ||
What is Unleash?
Unleash is a powerful open source solution for feature management. It streamlines your development workflow, accelerates software delivery, and empowers teams to control how and when they roll out new features to end users. With Unleash, you can deploy code to production in smaller, more manageable releases at your own pace.
Feature flags in Unleash let you test your code with real production data, reducing the risk of negatively impacting your users' experience. It also enables your team to work on multiple features simultaneously without the need for separate feature branches.
Unleash is the most popular open source solution for feature flagging on GitHub. It supports 15 official client and server SDKs and over 15 community SDKs. You can even create your own SDK if you wish. Unleash is compatible with any language and framework.
Getting Started with Unleash
1. Setting Up Unleash
To get started with Unleash, you need git and docker installed on your machine.
Execute the following commands:
git clone git@github.com:Unleash/unleash.git
cd unleash
docker compose up -d
Then point your browser to localhost:4242 and log in using:
- username:
admin - password:
unleash4all
If you'd rather run the source code in this repo directly via Node.js, see the step-by-step instructions to get up and running in the contributing guide.
2. Connect your SDK
Find your preferred SDK in our list of official SDKs and import it into your project. Follow the setup guides for your specific SDK.
If you use the docker compose file from the previous step, here's the configuration details you'll need to get going:
- For front-end SDKs, use:
- URL:
http://localhost:4242/api/frontend/ clientKey:default:development.unleash-insecure-frontend-api-token
- URL:
- For server-side SDKs, use:
- Unleash API URL:
http://localhost:4242/api/ - API token:
default:development.unleash-insecure-api-token
- Unleash API URL:
If you use a different setup, your configuration details will most likely also be different.
Check a feature toggle
Checking the state of a feature toggle in your code is easy! The syntax will vary depending on your language, but all you need is a simple function call to check whether a toggle is available. Here's how it might look in Java:
if (unleash.isEnabled("AwesomeFeature")) {
// do new, flashy thing
} else {
// do old, boring stuff
}
Run Unleash on a service?
If you don't want to run Unleash locally, we also provide easy deployment setups for Heroku and Digital Ocean:
Configure and run Unleash anywhere
The above sections show you how to get up and running quickly and easily. When you're ready to start configuring and customizing Unleash for your own environment, check out the documentation for getting started with self-managed deployments, Unleash configuration options, or running Unleash locally via docker.
Online demo
Try out the Unleash online demo.
Community and help — sharing is caring
We know that learning a new tool can be hard and time-consuming. We have a growing community that loves to help out. Please don't hesitate to reach out for help.
💬 Join Unleash on Slack if you want ask open questions about Unleash, feature toggling or discuss these topics in general.
💻 Create a GitHub issue if you have found a bug or have ideas on how to improve Unleash.
📚 Visit the documentation for more in-depth descriptions, how-to guides, and more.
📖 Learn more about the principles of building and scaling feature flag solutions.
Contribute to Unleash
Unleash is the largest open source feature flag solution on GitHub. Building Unleash is a collaborative effort, and we owe a lot of gratitude to many smart and talented individuals. Building it together with the community ensures that we build a product that solves real problems for real people. We'd love to have your help too: Please feel free to open issues or provide pull requests.
Check out the CONTRIBUTING.md file for contribution guidelines and the Unleash developer guide for tips on environment setup, running the tests, and running Unleash from source.
Contributors
Features our users love
Flexibility and adaptability
- Get an easy overview of all feature toggles across all your environments, applications and services
- Use included activation strategies for most common use cases, or use a custom activation strategy to support any need you might have
- Organise feature toggles by feature toggle tags
- Canary releases / gradual rollouts
- Targeted releases: release features to specific users, IPs, or hostnames
- Kill switches
- A/B testing
- 2 environments
- Out-of-the-box integrations with popular tools (Slack, Microsoft Teams, Datadog) + integrate with anything with webhooks
- Dashboard for managing technical debt and stale toggles
- API-first: everything can be automated. No exceptions.
- 12 official client SDKs, and ten community-contributed client SDKs
- Run it via Docker with the official Docker image or as a pure Node.js application
Security and performance
- Privacy by design (GDPR and Schrems II). End-user data never leaves your application.
- Audit logs
- Enforce OWASP's secure headers via the strict HTTPS-only mode
- Flexible hosting options: host it on premise or in the cloud (any cloud)
- Scale the Unleash Proxy independently of the Unleash server to support any number of front-end clients without overloading your Unleash instance
Looking for more features?
If you're looking for one of the following features, please take a look at our Pro and Enterprise plans:
- role-based access control (RBAC)
- single sign-on (SSO)
- more environments
- feature toggles project support
- advanced segmentation
- additional strategy constraints
- tighter security
- more hosting options (we can even host it for you!)
Architecture
Read more in the system overview section of the Unleash documentation.
Unleash SDKs
To connect your application to Unleash you'll need to use a client SDK for your programming language.
Official server-side SDKs:
Official front-end SDKs:
The front-end SDKs connects via the Unleash Proxy in order to ensure privacy, scalability and security.
- Android Proxy SDK
- Flutter Proxy SDK
- iOS Proxy SDK
- JavaScript Proxy SDK
- React Proxy SDK
- Svelte Proxy SDK
- Vue Proxy SDK
Community SDKs:
If none of the official SDKs fit your need, there's also a number of community-developed SDKs where you might find an implementation for your preferred language (such as Elixir, Dart, Clojure, and more).
Users of Unleash
Unleash is trusted by thousands of companies all over the world.
Proud Open-Source users: (send us a message if you want to add your logo here)
Migration guides
Unleash has evolved significantly over the past few years, and we know how hard it can be to keep software up to date. If you're using the current major version, upgrading shouldn't be an issue. If you're on a previous major version, check out the Unleash migration guide!
Want to know more about Unleash?
Videos and podcasts
- The Unleash YouTube channel
- Feature toggles — Why and how to add to your software — freeCodeCamp (YouTube)
- Feature flags with Unleash — The Code Kitchen (podcast)
- Feature Flags og Unleash med Fredrik Oseberg — Utviklerpodden (podcast; Norwegian)
Articles and more
- The Unleash Blog
- Designing the Rust Unleash API client — Medium
- FeatureToggle by Martin Fowler
- Feature toggling transient errors in load tests — nrkbeta
- An Interview with Ivar of Unleash — Console
- Unleash your features gradually, slideshow/presentation by Ivar, the creator of Unleash