API gateway for Australian shards?

[TroyLaurin]

We recently triaged an issue with an access key in the au2 shard returning unauthorized because we were only using the default api.cliniko.com host.

I understand from https://github.com/redguava/cliniko-api/blob/master/guides/sharding.md that sharding was introduced to make it easier to conform to local laws, but the fact that there are multiple Australian shards seems less useful. Would it be possible to introduce a forwarding gateway in front of either api.cliniko.com or a new api.au.cliniko.com that forwards to the correct Australian shard based on the API key in the request?

[jfriedlaender]

The API keys now include shard information, so it should be easy to pull that out, and use it for the right API request. Is there a reason that doesn't work for you?

We don't have plans for a gateway like you're suggesting, part of the benefit of the environments is performance, and also complete isolation of the information within a shard.

If you can share more why this would be needed that would be great.

[TroyLaurin]

It's mostly protection against the shard scheme changing and having to update our code again in the future.

For the two Australian shards, how much is performance a concern? Are the two shards in different regions on different parts of the nation's backbone? And since our infrastructure is in a single location then as long as the API gateway is on the east coast there would be no discernable difference to performance anyway. But I can see how it would be a killer for the international shards.

Back to your question, it's not strictly necessary since adopting your code to identify the host from the API key works fine, and the situation I'm describing only applies to the Australian shards. I guess it was just surprising to discover that there are essentially two distinct Cliniko "services" in Australia that don't talk to each other 😄

[jfriedlaender]

@TroyLaurin we won't change the scheme for as long as possible. We very rarely make breaking changes to the API (just a handful in the last 6+ years of having an API). So I don't think it will be needed for this.

As for performance, we get tens of thousands of API requests per minute. So for us, sharing those across different environments helps us scale and keep response times low.

In future, we expect to have more shards that don't talk to each other, within a region (like the Australian ones), as well as in more international regions. We won't let AU2 get as big as AU1 did. We like this approach to scaling and data sovereignty.

[TroyLaurin]

Makes sense. On reflection, I've raised https://github.com/redguava/cliniko-api/issues/317 instead to make it easier for developers who run into the same problem to figure out how to fix it properly.