Last July, the Privacy Shield, which had been so useful for companies doing business on both sides of the Atlantic, became ineffective. It took us all by surprise, since it was quite a new program (only 4 years old) building the framework for exchange of information and data between the United States (US) and the European Union (EU) and it had eased a lot the business between the two markets.
Let's say you've just built a new feature, but it's not ready for a full release just yet. So, you decide to test it with a small group of people.
You can go about it in two ways - deterministic or random. The first way lets you specify people by name, email, company or any other attribute you know about them. The latter uses fancy math and probability to randomly assign users into groups. Let's see how you'd accomplish both using ConfigCat.
When I implement a new feature to my application, I would like to manage it after the release (enable, target, tune and obviously in urgent cases roll it back). The feature/release toggles design pattern can solve my issue, but how can I answer the business needs? For example:
- turn on the feature on Sunday at 12 PM
- increase the discount value of the promotion every workday
- enable the feature only on weekends or on weekdays
When we designed ConfigCat, our main purpose was to create an architecture that is scalable and resilient to short interruptions, so you don't have to worry about latency, service outages, and unwanted glitches in the system.
Do you know what's this? Can you recognize multiple layers of load balancing working here?
Do you know why you see distinct group of lines fluctuating around different trends? It's there to achieve four contradictory goals at the same time. Let me explain that.
ConfigCat's validation phase was a success in our eyes, so we had to step ahead. Above making a great product with great features we had to provide a really stable and reliable system.
When it comes to feature flags, teams with 5-20 engineers face similar challenges to teams with hundreds of developers. What you never want is one engineer flipping a feature toggle to unintentionally affect the work of another engineer.
This is a conceptual problem with feature flags. It doesn't matter if you are using an open-source feature flag tool, or a feature flag service. Let's see best practices ConfigCat recommends.
In the next few articles I would like to introduce the core infrastructure of ConfigCat, how it has evolved over time and what challenges we faced through its validation phases.
Ever since we heard about Zapier we have been ecstatic by the possibilities this could bring to our platform. Zapier is an integration platform that allows you to easily connect multiple platforms by taking inputs from one service and outputting them to another service. While software integration is common, some integration may not be appropriate for your technology stack, or native integration may not yet be supported. This is where Zapier can step in and save the day.
It truly is an exciting day for ConfigCat, we would like to introduce a brand new way to use our platform via our new public management API. This new feature makes it easier than ever to test and manipulate your feature flags allowing you to create, read, update and delete any entity within ConfigCat, such as Feature Flags, Configs, Environments or Products. For anyone familiar with using Public Management API systems the benefits will be beyond clear, if you are not, we will show you in this blog how you can make feature requests quickly and easily, all without writing any external code.