use env_variables in app.yaml?

Is that very much better than having it inline here? We'll still need to say "open up a file and fill in that placeholder", and at least here it's more in-context?

This is pretty gnarly, is there another way to get the info you need?

Yeah - I agree.

The problem is that I need the info from _FIREBASE_CONFIG_TEMPLATE in two places -

• the client needs it 'cuz it receives events from this endpoint
• the server needs it because it sends events to this endpoint.

I could inject it into the template, but the way you get it from the firebase console is it gives you an html snippet to copy/paste, and I'd rather say "paste the entire snippet into a file" than "paste the snippet into a file and then look for the databaseURL and copy that value into this placeholder in firetactoe.py".

Alternatively, I could delete this function (it's only used once) and instead of doing config['databaseURL'], I could do:

with open(os.path.join(_CWD, 'templates', _FIREBASE_CONFIG_TEMPLATE)) as f:
    regex = re.compile(r'\bdatabaseURL\b.*?["']([^'"]+)['"]')
    match = next(regex.search(line) for line in f if regex.search(line))
databaseURL = match.group(1)
# etc...

which isn't as correct, but does the job. It's slightly prettier... okay, updated to use a form of that. LMKWYT

What does this template look like? Can you paste an example?

Fine, regex it is.

Don't modify globals if you can help it, and definitely don't modify global constants. Can this just be pulled into a function?

Mostly I'm trying to cache the url, to avoid reading a file from disk on every request. I dunno - premature optimization? :-)

That's fine, but can you pull all of this caching stuff into it's own function? _get_fire_url?

So it seems the only reason we require them to give the private key is so that pyjwt can sign the jwt. However, App engine can actually sign blob directly using app_identity. We'd have to forgo the jwt library, but do you think that's doable?

I'm not too familiar with how jwts work, so I wasn't sure if the app_identity signing was the same as the tokens firebase expects.

I searched the app_identity page for the string 'jwt' and came up blank, so kept this :-/

encoding a jwt is pretty straightforward, just use this code: https://github.com/GoogleCloudPlatform/google-auth-library-python/blob/master/google/auth/jwt.py#L55

• Don't worry about the kid
• Replace signer.sign with app_identity.sign_blob.

Just noticed that you've done this. 👍

I ran into a problem with this which I fixed, but then realized that using the gcloud way of providing ADC doesn't provide app_identity with everything it needs; so modified the README to use a service account instead.

SG.

Does this need to be a class, or could it just be some constants?

I figured the class groups them together in a namespace, which is nice.

Not a strong enough argument for class. :)

I'd prefer that over having a slew of instance variables and initialization logic in the global namespace.
What would you suggest?

Just

X_WIN_PATTERNS = ...

It's fine to have these as constants because, well, they are constants. There's no argument for having them in a class. Classes are for collective state or behavior. You could maybe argue for having them in a separate module.

I'm unconvinced, but want to get this in sooner rather than later.
Done.

ndb instead of db?

s/f/view_func

jquery could make a lot of this dom manipulation much easier to read.

I considered that too, but I don't think this script is doing anything complex enough to warrant pulling in jquery. The equivalent jquery would have a similar LOC count (I just tried), and then we're importing a relatively heavy-weight library.

(not to say there might not be wins to be gained with a larger refactor... (/me eyes the manual style setting below) but it's non-obvious and the clock is ticking :-/)

It won't decrease the line count, but it'll make things easier. (Also, jquery is hardly heavyweight).

I disagree, but whatever. Refactored.

I would prefer you to store these as data- attributes on some well-known element (body would be fine).

Any particular reason why that seems better? That feels a little global-variable-y to me, whereas passing in the parameters to init with as arguments seems like the Right Thing to do?

You can still invoke the function:

var $config = $('something),
    game_key = $config.data('game-key'),
    ...;

initGame(game_key, ...);

It just decouples the JS from the template engine - I really, really abhor mixing server-side template interpolation in javascript.

Why?
I like it - it puts the information precisely where it's needed, and the templating system makes sure it's safe.

Pull memoization into it's own function, _get_http.