41–46 of 46 posts
I’ve always wanted this to exist! Very nice execution.
Feel free to send me an email at mark flipt.io, or drop into our Discord to say hi at https://flipt.io/discord
I am a user. What i would like is something very "simple", no server Use the same SDK and ping github rest api to get the values of the the flag. I know, this is very weird... But i cant deny it would be helpful for very small projects
We've been thinking a lot recently about supporting 'edge' k/v stores like vercel/cloudflare and having the client side evaluation SDKs pull from there, which wouldn't require a server at all. This seems very similar just with using GitHub. We could even use GitHub Container Registry as the store as its OCI compliant.
Thank you for using Flipt btw!!
Love the design!
I am a user. What i would like is something very "simple", no server Use the same SDK and ping github rest api to get the values of the the flag. I know, this is very weird... But i cant deny it would be helpful for very small projects
Thats a cool idea! Feel free to put something in our community on Discourse ( https://community.flipt.io/c/flipt-cloud/6 ) or Discord ( https://www.flipt.io/discord ) so we can talk through how this could work. We've been thinking a lot recently about supporting 'edge' k/v stores like vercel/cloudflare and having the client side evaluation SDKs pull from there, which wouldn't require a server at all. This seems very…
Also S3 (+ azure and GCP) would be a good 'edge' k/v store.
Someone could start with Github in a simple project, migrate to S3 to handle more requests and then migrate later to a full server solution... All of this keeping the same client codebase
Earlier quoted context omitted.
Feature flag state is still served dynamically through Flipt. Your code doesn’t have to redeploy for the changes to “become live”. That’s the main benefit. Means you can experiment and target different cohorts with variants of your app without restarting processes everywhere.
Thank you. I guess I was imagining that the flags lived in your source code repo, and required a commit and push to update, thus triggering some CD build and redeploying your app anyways.
However, this can be changed, so that not all commits/pushes are treated equally during CD. Either by using rules to ignore changes to certain sub-directories / files or through having reproducible builds and skipping the process restarting parts when the resulting artefacts between two commits haven't changed (e.g. the digest of a docker image not changing from one commit to the next).
This is often an optimisation though, and takes time/effort to put in place.
Earlier quoted context omitted.
Thats a cool idea! Feel free to put something in our community on Discourse ( https://community.flipt.io/c/flipt-cloud/6 ) or Discord ( https://www.flipt.io/discord ) so we can talk through how this could work. We've been thinking a lot recently about supporting 'edge' k/v stores like vercel/cloudflare and having the client side evaluation SDKs pull from there, which wouldn't require a server at all. This seems very…
cool. Looking forward for this. Also S3 (+ azure and GCP) would be a good 'edge' k/v store. Someone could start with Github in a simple project, migrate to S3 to handle more requests and then migrate later to a full server solution... All of this keeping the same client codebase
We already support S3, Azure and GCS, as well as OCI (any compatible registry) as a source in the open-source server-side evaluator. So if you pop a deploy step to any of these sources from your Git repo, you can use them via the Flipt server process as a source of truth in production. Our server-side and client-side SDKs can source from Flipt in these scenarios.
But, we are keen to both explore skipping the Flipt server middle-man for client-SDKs, as well as make the publish step to these locations a simple configuration process in our UI. To avoid having to write things like GH actions to achieve the end to end result.