It is currently possible to run multiple instances of the ConfigCat application by providing a different name option for each instance, then providing that name in all of the public API calls as ConfigCat.get_value(key, default, user, client: <name>).

We could make this cleaner by following the approach in the "Improving the User Experience" section at the end of https://keathley.io/blog/reusable-libraries.html.

I think that all we'd need to do is define a __using__ block in ConfigCat that automatically supplies a name option of __MODULE__ and then defines versions of the public API functions that call the normal versions with the client option pre-specified.

This would allow us to add this convenience without changing the public API.

Describe the bug

Occasionally, a call to ConfigCat.get_value will time out. The timeout is not handled and therefore leaks to the calling application which can crash a process if the caller doesn't handle the timeout either.

Erlang error: {:timeout, {GenServer, :call, [ConfigCat.Client, {:get_value, "myFeatureFlag", false, nil}, 10000]}}

To reproduce

It is not easy to reproduce this, as it only happens occasionally.

Expected behavior

Any ConfigCat API call that has a default value should rescue the timeout error and return the default value rather than leaking the timeout back to the calling application. This includes get_value and get_variation_id.

It is less clear what should happen for calls like get_all_keys, get_all_variation_ids, and get_key_and_value, but probably returning empty lists for the first two and nil for the last would be best.

force_refresh should return {:error, :timeout} or similar.

My intention when I implemented this library is that get_value and similar calls shouldn't block on HTTP requests which is what seems to be happening here, so it would also be worth figuring out how these timeouts are happening in the first place to see if we can fix the root cause. I'll look into that as well.

Screenshots

If applicable, add screenshots to help explain your problem.

There is an other get function called get_variation_id, which main purpose is to provide a variation_id which can be sent e.g. to an analytics provider. This feature is currently behind a feature flag in ConfigCat, but it will be turned on soon. You will be able to get the variation_id from the dasboard for a rule/percentage item/default value and match it with your analytics tool.

Originally posted by @laliconfigcat in #2 (comment)

When the user provides an on_change callback, we call it directly from the auto-polling process. If the user-provided function is expensive or long-running, it will block our polling loop.

To avoid this issue, we should call the function asynchronously instead.

Please create 3 different files for the different polling modes if possible:
auto_polling_cache_policy.ex
lazy_loading_cache_policy.ex
manual_polling_cache_policy.ex

Originally posted by @laliconfigcat in #2 (comment)

Add full documentation, including:

• Fleshing out the README with more information about how to use the library and add it to a supervision tree
• Documentation for the ConfigCat website
• Adding module documentation for publishing to hexdocs.pm

The other SDK's expose a way to retrieve all keys from a config. This library needs one as well.

And here comes the magic to handle our new datagovernance feature. Please adjust this with the same logic from here:
https://github.com/configcat/python-sdk/blob/master/configcatclient/configfetcher.py#L74

Originally posted by @laliconfigcat in #2 (comment)

Please extract all of the refresh logic to a config_fetcher.ex

Originally posted by @laliconfigcat in #2 (comment)

Create a sample application similar to the ones for other ConfigCat SDKs to demonstrate the use of the library.

Would be nice to have code coverage report & also on travis
https://github.com/codecov/example-elixir

testmatrix_input_semantic_2.csv and testmatrix_variationId.csv tests are missing.
https://github.com/configcat/python-sdk/blob/master/configcatclienttests/testmatrix_input_semantic_2.csv
https://github.com/configcat/python-sdk/blob/master/configcatclienttests/testmatrix_variationId.csv

Originally posted by @laliconfigcat in #2 (comment)

Is your feature request related to a problem? Please describe.

Hi, I'm trying to install the configcat dependency to my Elixir project, but get the following error

Resolving Hex dependencies...
Resolution completed in 1.007s
Because your app depends on configcat ~> 4.0.0 which depends on httpoison ~> 1.7, httpoison ~> 1.7 is required.
So, because your app depends on httpoison ~> 2.1, version solving failed.
** (Mix) Hex dependency resolution failed

Describe the solution you'd like

Is there a way we can make the dependency more flexible? for example {:httpoison, "~> 1.7 or ~> 2.0"}

Describe alternatives you've considered

Forking this project?!

Please add the email and country next to the identifier with a default "" value.

Also if the identifier is :nil please use "" instead of it

Originally posted by @laliconfigcat in #2 (comment)

Is your feature request related to a problem? Please describe.

Currently reading feature flag values always happens through a GenServer.call/3. From my understanding for a given SDK key it's a single process handles all read requests. This creates a natural bottleneck.

If for example a feature flag is accessed in a hot code path, potentially from thousands of processes every single second, then this will invariably overwhelm the process that handles the feature flag requests, slowing down the system as a whole.

Describe the solution you'd like

Instead relying on GenServer.call/3 to fetch feature flag values I suggest to use an ets table. In a nutshell an ets table can be created on start - e.g. by the ConfigCat.Client process - potentially with the read_concurrency option enabled (I'd assume that reading is more frequent than writing).

Then feature flags can be read from the ets table, eliminating the need for most message passing and as such the natural bottleneck.

Describe alternatives you've considered

/

Additional context

This approach combines neatly with the "auto" and "manual" polling modes. It does get a bit more complicated when considering the "lazy" mode.

A naive implementation of the "lazy" mode would check the ets table first and - if the value is missing - send a message to fetch the value. But in a high load scenario this can mean that thousands of messages pour in when a value expires.

To solve this problem I suggest what I call an "optimistic lazy" approach, not unlike the stale-while-revalidate HTTP Cache-Control behaviour. In addition to reading values from the ets table you'd keep track of the last access time for each key - potentially on another ets table this time with write_concurrency enabled.

The "optimistic lazy" cache refresh implementation would then look at which keys are about to expire and refresh those that were accessed very recently, whereas "very recently" would be a matter of configuration with a sensible default (e.g. 5 seconds).

Allow a client to provide their own cache implementation.

The idea is to change the current public interface from:

{:ok, client} = ConfigCat.start_link("sdk_key", fetch_policy: FetchPolicy.manual())
value = ConfigCat.get_value("any_feature", "default", client: client)

To:

{:ok, client} = ConfigCat.create_client("sdk_key", fetch_policy: FetchPolicy.manual())
value = client.get_value("any_feature", "default")

This change would make our public interface more similar to the ones we currently have on other SDKs.

Previous discussion:
https://configcat-community.slack.com/archives/C01CN2YNWGK/p1603106388007500

Publish the library to hex.pm and the documentation to hexdocs.pm.

We'll have previously set up CI for building and testing (in #6) and written the documentation (in #4), but once we're ready to officially release this SDK, we'll want to start publishing to hex.pm and hexdocs.pm.

Describe the bug

Using the auto policy, we are often getting a GenServer timeout from the FetchConfig genserver.

{:timeout, {GenServer, :call, [ConfigCat.ConfigFetcher, :fetch, 5000]}}

In CacheControlConfigFetcher, the handle_call for :fetch is making a request and using the HTTPoison library which has some timeouts that are larger than the GenServer.call/2 default time.

https://hexdocs.pm/elixir/GenServer.html#call/3

call(server, request, timeout \ 5000)

https://hexdocs.pm/httpoison/HTTPoison.Request.html

:timeout - timeout for establishing a TCP or SSL connection, in milliseconds. Default is 8000
:recv_timeout - timeout for receiving an HTTP response from the socket. Default is 5000

To reproduce

Run ConfigCat with the auto policy and let it run, this will periodically happen.

Expected behavior

The genserver allows enough time for the fetching of the updated config from ConfigCat or handles this error in some way.

Many Elixir projects rely on Dialyzer typespecs. As a library, we should provide proper type specs for our clients to rely on. They also help document use of the library.

As I've been adding behaviours to the system, I've specified some typespecs. For now, I've hard-coded map() as the type of a config, but we will likely want to define a more explicit type for that and use it everywhere.

Announce the existence of the library in various ways:

Maybe some or all of:

• blog post
• submission to various Elixir newsletters
• Twitter
• ElixirForum post
• submit PR to https://github.com/h4cc/awesome-elixir

Having the SDK listed in the official docs will help a lot as well, but if we tell people about this SDK it might draw some more interest in ConfigCat as well.

Add a TravisCI configuration for automatically building and running tests against whichever Elixir versions we want to support.

Describe the bug

13 tests are failed on Elixir 1.11.x. (All tests are working on Elixir 1.10.x)

To reproduce

• Install Elixir 1.11.x dev environment
• Install dependencies

  mix local.rebar --force
  mix local.hex --force
  mix deps.get

• Run tests

  mix coveralls.json

• 13 tests are failed:

  108 tests, 13 failures

Expected behavior

All tests are passed on all Elixir versions

SDK version

v1.0.1

Language/Framework version

Erlang/OTP 23 [erts-11.2] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [hipe] [dtrace]
IEx 1.11.4 (compiled with Erlang/OTP 23)

Platform

Mac OS X 10.15.7

We are using now the new config_v5.json format. There are some breaking changes in that (structure modified).

Originally posted by @laliconfigcat in #2 (comment)

Allow a client to specify a callback that should be called when automatic polling fetches an updated configuration. The callback shouldn't be called if the configuration hasn't been changed.

See https://github.com/configcat/ruby-sdk/blob/master/lib/configcat/configcatclient.rb#L83-L93 for the Ruby implementation.

Background

In order to support a number of desired features that would make the SDK more extensible and closer in structure to the other language SDK's, I'm proposing a restructuring of the architecture as outlined below.

Here are the features we'd like to support:

• #10 - Allow a custom cache implementation
• #14 - Extract config logic to a ConfigFetcher module
• #15 - Split cache policies into separate files (if possible)
• #30 - Improve public interface

I've based this "desired future" largely on the current Ruby SDK as that's the one I'm most familiar with.

Current State

• Almost all of the logic lives in the ConfigCat GenServer.

• The state of the GenServer includes both client settings and the currently-cached config.

• FetchPolicies are simple structs and the FetchPolicy module provides some helper functions that pattern match based on the type of the policy.

Something that's not clear from the tests is how this library would be used within an application, and I think this lack of clarity is what spawned #30.

Once we add a sample application (#5) and documentation (#4) this will become more clear, but here's a rough summary:

• The current tests make it seem like we have to call ConfigCat.start_link every time we want to request a value; however, that's not the intended use for a client application.

• Instead, a client application adds ConfigCat to its supervision tree as appropriate using a child spec such as {ConfigCat, [sdk_key()]}.

• The client can then call ConfigCat.get_value(key, default, user) as appropriate.

• By default, the public API in ConfigCat will talk to the running GenServer process using its default name (the ConfigCat module name).

• It is possible to provide a different name for the GenServer (as is done in the tests), and to have the public API talk to a different GenServer via an optional client: pid argument. These extra arguments are there mostly for the tests, or for a more complicated use case where we want to use multiple different ConfigCat configurations in the same application. In normal circumstances, the client application doesn't need to provide those arguments.

Design Considerations

• Since Elixir is not an object-oriented language like Ruby, we can't simply initialize a class with some instance variables that we can then call functions on.

• The current ConfigCat module has too many responsibilities.

• The current architecture does not easily support a pluggable cache implementation.

• Other language clients split their cache policies into separate files/classes.

• In Elixir, persistent state is normally managed by GenServers as are asynchronous periodic processes (like the auto-polling cache policy).

Proposal

• Split ConfigFetcher out to its own (non-GenServer) module.

• Define an Elixir behaviour for a ConfigCache.

• Rename FetchPolicy to CachePolicy to match the other language SDKs; other changes as outlined below.

• Divide the rest of the application into a Supervisor with a family of child GenServers:

  • A Client GenServer will manage any global application state (similar to the inst vars in the Ruby Client class). This state will include the configured cache policy (renamed from FetchPolicy) and anything else necessary.

  • A CachePolicy GenServer: one of CachePolicy.ManualPolling, CachePolicy.AutoPolling, or CachePolicy.LazyLoading. Whichever of these GenServers is running will keep a reference to the cache and config fetcher as well as its own settings. The AutoPolling GenServer will also manage the polling loop.

  • (optional) A Cache GenServer: we'll provide a Cache.InMemory GenServer as a default and add it to our supervision tree. This GenServer will manage the current configuration as its state. More on pluggable cache implementations below.

• We might need to find a way to eliminate duplication between the CachePolicy GenServers.

• The way the calling application specifies the cache policy might change; internally, we'll turn that specification into a child_spec that we can add to our supervision tree.

• The calling application can provide a custom cache implementation as either cache_module: SomeModule or cache_spec: some_child_spec. In the former case, we'll call functions on that module; in the latter, we'll add the cache to our supervision tree (and then call functions on the module). This will allow callers to provide a cache (like Redis) that is already supervised by their application, or a simpler cache (like our InMemoryCache) that needs to be started and supervised.

• The public API stays largely as it is today: the calling application adds ConfigCat to its supervision tree and then calls public API functions like ConfigCat.get_value(key, default, user). This goes against what #30 is asking for, but I'm hoping that the explanation above shows that this is already a very usable (and Elixir-like) API.

This is a more complex architecture than what we have today. However, it also divides up responsibilities into smaller, more easily-testable (and pluggable) pieces. It is also structured much more like the other language SDKs.

Roadmap

Here's how I think we can get to this new architecture incrementally:

• Extract a ConfigFetcher module to manage the communication with the ConfigCat servers. (#40)

• Add a Supervisor above the current ConfigCat GenServer. (#38)

• Extract a ConfigCache behaviour and InMemory implementation of that GenServer.

• Convert FetchPolicy into a family of CachePolicy GenServers.

Depending on the polling mode this should be:

• manual poll: ConfigCat-Elixir/m-
• auto poll: ConfigCat-Elixir/a-
• lazy loading: ConfigCat-Elixir/l-

Originally posted by @laliconfigcat in #2 (comment)

When a calling application is using more than one instance of ConfigCat, there is not an easy way to distinguish the log messages between them.

It would be helpful if we included the custom name provided by the user as part of the log message. This might be a bit tricky, as the name is not necessarily available everywhere we call the logger.

It looks like this is also an issue with the Ruby implementation, so maybe it's not worth worrying about, but I thought I'd capture the issue anyway.

Also please fetch the version from the mix.exs if possible.

Originally posted by @laliconfigcat in #2 (comment)

The properties shouldn't be lowercased (downcased :) ), they properties should match as is. So e.g. Identifier != identifier in the other SDKs.

Originally posted by @laliconfigcat in #2 (comment)

We (the e-commerce team at InfluxData) wrote a ConfigCat client for Elixir a few months ago. It's currently embedded within our one of our (closed-source) apps, but I was literally just about to create a new repo to extract and open source our work when I found this repo.

I don't see any code here yet, but we're wondering how far along you are with development. Can we combine forces to make a single, official Elixir client for ConfigCat?