a GAE-friendly (probably synchronous) client?

[jcjones1515]

I'm evaluating LaunchDarkly for my company and I'm running into some issues getting things going on Google App Engine standard for python.

I got past the familiar SSL issues, but App Engine Standard and background threads aren't very compatible, I was wondering if there was a simple way to make the client be synchronous with perhaps some in-memory caching. I'd be more than willing to contribute code along these lines but would need some guidance.

I found a similar issue with a different library that seems to have found a workaround.

Thanks,

Jason

[jcjones1515]

here's an example of what you get in the logs:

Thread running after request. Creation traceback:
  File "/base/data/home/runtimes/python27_experiment/python27_lib/versions/1/google/appengine/runtime/runtime.py", line 152, in HandleRequest
    error)
  File "/base/data/home/runtimes/python27_experiment/python27_lib/versions/1/google/appengine/runtime/wsgi.py", line 329, in HandleRequest
    return WsgiRequest(environ, handler_name, url, post_data, error).Handle()
  File "/base/data/home/runtimes/python27_experiment/python27_lib/versions/1/google/appengine/runtime/wsgi.py", line 267, in Handle
    result = handler(dict(self._environ), self._StartResponse)
....
  File "/base/data/home/apps/s~gain-data/document:3770ee8.400953481398027178/lib/gain_util/feature_flag.py", line 38, in _get_client
    _ld_client = ldclient.get()
  File "/base/data/home/apps/s~gain-data/document:3770ee8.400953481398027178/lib/ldclient/__init__.py", line 93, in get
    __client = LDClient(config=__config, start_wait=start_wait)
  File "/base/data/home/apps/s~gain-data/document:3770ee8.400953481398027178/lib/ldclient/client.py", line 85, in __init__
    self._update_processor.start()
  File "/base/data/home/runtimes/python27_experiment/python27_dist/lib/python2.7/threading.py", line 749, in start
    _start_new_thread(self.__bootstrap, ())
  File "/base/data/home/runtimes/python27_experiment/python27_lib/versions/1/google/appengine/runtime/runtime.py", line 82, in StartNewThread
    return base_start_new_thread(Run, ())

[jcjones1515]

one note, I hacked together a prototype client which seems to work here: https://github.com/GainCompliance/launchdarkly-python-client/tree/google-app-engine

It:

• loads features upon init of the client
• uses poll_interval to decide when the features are stale and need to be re-fetched
• doesn't use threads

I haven't exercised it too thoroughly, but as a POC it seems to show it can be done

[pkaeding]

Hi Jason

I'm happy to give you some guidance on this. There are two main things we use background threads for:

• listening for flag targeting rule updates
• flushing events back to LaunchDarkly. These events are used to populate the user search functionality, targeting autocomplete, flag statuses, a/b test result, and a few other features

To make this work in GAE, you would need to implement:

• A feature store that read rules from the GAE key/value datastore (See the RedisFeatureStore for a good starting point.)
• An UpdateProcessor that connects to the stream, and updates the rules in the datastore (consumed by the above). I'm not very familiar with GAE, but it looks like you could use a push queue to start this job, have it run for almost 10 minutes, and then queue up the next iteration of it. This way, there would always be one running, and it would mostly stay connected continuously. This would likely be a wrapper around the StreamingEventProcessor
• An EventConsumer that takes the events from the SDK, and queues them for flushing in a pull queue (again, I might be wrong about the best GAE tool to use here).
• A job to batch those events from the pull queue, and flush them to LaunchDarkly. You'd probably need to split the stock EventConsumerImpl in two for this and the previous.

Hope that helps! Please let me know if you have any questions.

Thanks,
Patrick

[jcjones1515]

Thanks @pkaeding, if I put something along these lines together, would you prefer I just start another repo, or a package within this client? I'll need to use some of the existing code, but I could pull it into a new repo as a package.

I'll think through how to put together the pieces you've described in App Engine. Is there anything like webhooks for feature adds/changes that I could plug into?

[pkaeding]

If you can make a package in this repo that contains the GAE stuff, that is probably simpler.

There isn't a webhook that we fire when flags change, but there is an SSE stream. I'm not sure the best way to consume that in GAE. (From some quick reading of the docs, I found the push queue, which limits tasks to 10 minutes, so you could just schedule a new task right before that one is about to timeout, but that definitely feels hacky.)

[pkaeding]

Actually @jcjones1515, there is a way you could use our audit log webhooks to trigger a refresh of the rules. This blog entry gives an overview, using AWS Lambda. Basically, you listen for audit log webhooks that might cause the rules to change, and then refresh them when they fire (ignoring the content of the webhook payload, because it won't be in the right shape that you need).

Hope that helps!