Feature Toggle API

[tombuildsstuff]

Discussed in #152

Rather than making clients query directly to ETCD to get the status of a toggle - it'd be good to make them query via an API. There's several benefits to this:

• Allows the option of some kind of security per request
• The ETCD config is set inside of Hobknob - not per-app
• ETCD can be secured via routing rules
• It becomes easier to scale the application as required

Personally - I'd recommend that this is done as a separate deployable unit rather than putting it in the same application for the following reasons:

• From a Scalability perspective:
  • it makes life a lot simpler to scale the API as required - keeping only a single instance of the front-end app
• From a Security/Ops perspective:
  • It's possible to lock the application down via Network rules - e.g.:
    • ETCD becomes a Private resource (that only the API + front-end can access) - no longer accessible to teams
  • The Front-End and API can become internal-only
• From a Development perspective:
  • If all endpoints in a given application have to be secured - it's very easy to use middleware to handle that for all scenarios - meaning human error/unsecured endpoints won't happen

Thoughts?

[pbazydlo]

Splitting API into a separate entity seems like a good idea to me, mainly for the ability of encapsulating etcd config in one easily controllable place (API).

[richardhopton]

Agreed - We need to ensure we don't adversely affect performance by having the intermediary but in principle it's a great idea.

[tombuildsstuff]

FWIW I've started this locally - I've been wondering where it belongs - in a separate repo?

[matteofigus]

What about this app hosting endpoints for both API and HTML?

My target really is just simplicity: In theory we could have the same authentication model for each endpoint (api and webapp home)? Or maybe that's not possible because of the G+ web authentication?

[tombuildsstuff]

I'd say that's not possible to reuse it because of the OAuth. What would be nice would be to generate Access Tokens for applications through the Dashboard for Project, that you can use against the API?

[terrybrown]

thanks for the nudge over to here @tombuildsstuff - after reading your thoughts, agree, for our simple use case we could have just piggybacked onto the admin API, but you're a little too coupled there and having a separate API for client consumption makes sense.

I suspect in the first instance, we'll update the client locally to point at the admin API (which I guess longer term will not go to waste as it'll just be a different endpoint/contract perhaps).

Happy to contribute in any way you guys feel would be useful though.