When can we expect global data centers?

[atuttle]

According to your product roadmap "global data centers (US/Asia)" is on the "to-do" list. I assume, then, that the current data center is only in Europe?

My initial tests showed a time around 300ms to get a flag value from the api (from PA-USA). I simply can't proceed while that's true. It's entirely possible we could be checking 5-10 flags in a single request, so the extra load time will get out of control quite fast.

As far as I'm concerned, response time is the most important thing after the most basic of functionality.

[dabeeeenster]

Hi Adam,

We're working on a global API right this moment! Hoping to have it deployed end of Q1 2021. Just out of interest, what latency would you find acceptable?

[atuttle]

Ideally a single <=20ms lookup per request. I'm imagining a system that gets the status of all flags at the start of every request and caches them in memory for the duration of the request. Obviously this will be dependent on the number of flags in use and other factors, but you asked for a target so I'm happy to paint one.

For my application's architecture it would be even better if there were a push mechanism where you could call a webhook or an API endpoint in my application to publish flag changes, and the application could assume them to be in memory already and shared across all requests.

I'm new to the world of feature flags and I understand that user segmentation also plays a big role in flag determinations, so I'm not sure if what I've described above is even possible.

Perhaps some basic data can be cached locally and updated via push, and then the SDK can do the segmentation (user/etc) determinations. Having never used LaunchDarkly and only spoken with a friend who does, that's the impression that I get for how their system works.

[dabeeeenster]

Just to explain - when you call get flags in Flagsmith, we return all the flags for that environment or identity; most people just do this once per session.

We do have webhooks and they are particularly useful if you are running server rendered pages/infra: https://docs.flagsmith.com/system-administration/#web-hooks - a common pattern is to grab the flags when a server starts, store them in a shared cache and then update that cache state upon receiving a webhook.

Our platform is designed around clients not performing segment calculations. In order to do this you need to send the segment rules to the client, which we feel is pretty weak from a security/privacy perspective. This is one of the reasons why we are building out the global api!

20ms is a pretty tough target! We are aiming to provide < 100ms for most populations on the planet with the initial roll out.

[atuttle]

At once per session, 100ms would be acceptable.

This can be a different discussion thread if necessary but another part of my frustration so far has been that, while I am working on the JVM, I am not a java developer. My platform can utilize java classes, but there's not enough documentation around using the java SDK for me to have been able to get it running happily in my application. It was also extremely frustrating to have to hunt down all of the various JARs to get it running in my app. I'm not even sure I had them all. Assuming all java sdk users are going to use maven or gradle is simply just wrong.

If I'm remembering correctly, I also got frustrated that I had to add every user to Flagsmith, and the id values that I provided in my app would not match up with the values I entered in the flagsmith dashboard no matter what I tried. Sorry, but I forget the details. It was so frustrating that I believe I reached out to support and asked for my account to be not just deactivated but also deleted!

I heard about Flagsmith from the online presentation with Dan Wilson and TJ VanToll, but I left that very early into the talk because it was going too slowly and I didn't have the patience to waste an hour+ to get the 10 minutes of information I needed.

I feel like you need some better onboarding documentation. For example, the docs jump straight from initializing the sdk to checking a flag, but that doesn't explain the once-per-session data load you've described.

[dabeeeenster]

hey @atuttle - thanks for the feedback - will be incorporated!

[dabeeeenster]

This is live!