Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow Bramble to store its gateway state externally #99

Open
nmaquet opened this issue Nov 7, 2021 · 1 comment
Open

Allow Bramble to store its gateway state externally #99

nmaquet opened this issue Nov 7, 2021 · 1 comment
Labels
enhancement New feature or request

Comments

@nmaquet
Copy link
Contributor

nmaquet commented Nov 7, 2021

In High Availability deployments, it would be desirable to allow Bramble to store the merged schema and the other bits of gateway state into an external consistent storage service (e.g. etcd). At Movio, we have struggled to keep separate instances of Bramble synchronised and this would go a long way in solving that issue.

@nmaquet nmaquet added the enhancement New feature or request label Nov 7, 2021
@gmac
Copy link
Contributor

gmac commented Nov 9, 2021

Huge +1, especially on the end state of Bramble having a defined cartridge format. As part of this objective, I'd suggest the following core APIs:

  • ComposeExecutableSchema([{ServiceURL string, SchemaSDL string, Options ...}]) – accepts an array of URL/SchemaSDL pairs, and composes them all into an ExecutableSchema. This allows the Bramble server's default schema fetcher workflow to be bypassed, thus supporting other architectures that handle schema fetching and caching in custom ways.

  • ExecutableSchema.Export() cartridge – exports the ExecutableSchema instance into a JSON-serializable cartridge format.

  • ImportExecutableSchema(cartridge) ExecutableSchema – imports a deserialized cartridge into an ExecutableSchema.

For the import and export, I go back and forth if it makes sense for them to use JSON strings as the IO formats. While that's nice and tidy, my gut says that NOT baking stringification into the import/export process is preferable so that implementors can choose to perform tailored caching steps to portions of the payload without having to go in and out of string formats repeatedly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants