Graphql-engine: remote schema enable/disable

[praveenweb]

When i have a remote schema which doesn't work (lets say the server is down or deleted), i'm not able to make any postgres schema changes to Hasura GraphQL via console. (this is expected, because of the dependancy check that happens during merging).

But right now to get around this, i have to delete the remote schema which isn't working. If i can enable/disable remote schema, instead of deleting, it would be a better experience during development.
This feature basically helps in preserving the config (url, name and headers) of remote schema.

[dafrie]

Quick addition here: It seems that HGE can not start up (at least it happened to me on Heroku) if a remote schema is not reachable. Would be nice, if it automatically could set non-reachable remote schemas to "disabled" on start! What do you think?

[coco98]

@ecthiender Thoughts?

[ecthiender]

If i can enable/disable remote schema, instead of deleting, ...

Sure. But if HGE is already down (because remote schema is not available), the only way to disable would be to fiddle with the HGE's state in postgres (and change the disable column true, for example). We won't be able to disable the remote schema through console or the API, right? Even right now, to delete the remote schema we have to fiddle in postgres.

Or do you mean we can disable it (from the console) as part of a workflow?

1. Add remote schema
2. Play around with it.
3. Once done, disable it, and then go on about your business. (so that next time when HGE starts up, it won't try to stitch this remote schema) (if you forget to do this step, you would have to go to pg to disable it)

In my mind, this issue is similar to "server should start-up, in inconsistent state, but with warnings". (#231).

---

Would be nice, if it automatically could set non-reachable remote schemas to "disabled" on start! What do you think?

This might be convenient during dev, but in a production instance this might not be a safe behaviour. So, there should be a flag to toggle this behaviour (downside: one more flag).

[praveenweb]

If HGE is already down, i suggest that

1. HGE logs output info about unreachable remote schema(s) and may be ask users to go and edit via Postgres.
2. Or an overall flag to disable remote schemas so that i can get HGE up and running before i debug.

The ideal scenario would be to start HGE in an inconsistent state with warnings on logs and on the console, but in a production scenario this error might be silent and go unnoticed.

[hmexx]

HGE should definitely still start, and continue working, if a remote schema is unavailable.

One of Hasura's selling points is building a unified API for all of your internal services. You wouldn't want it to go down if a tiny inconsequential feature is unavailable (example: weather service). If a query requires remote data, an error message should trickle down to the client, each time a request is received, until the remote schema is available again, at which point the queries should start working again without any intervention.

It can also make development a bit more annoying :-)

[fsc7]

I am having the same problem and I think Hasura should still start even if some schemas are not available.

[c19]

Also found that doing hasura metadata export and hasura metadata apply would requires the remote schema to be available.

[rakeshkky]

https://github.com/hasura/graphql-engine/pull/1863 solves the problem of HGE crashing if a remote schema is unavailable.

[rakeshkky]

Do we still want to manually enable/disable a remote schema?
@coco98 @0x777 @ecthiender