experimental_pollInterval Why is this bad?

[joepuzzo]

Im running a few federated graphql servers and we are trying to keep things as simple and up to date as possible. In order to prevent having to restart our gateway every time we make a schema change, we utilize experimental_pollInterval. We don't want the complexity of a graphql manager. We want a very simple federated schema.

This works perfectly! However there is that warning that says

Polling running services is dangerous and not recommended in production. Polling should only be used against a registry. If you are polling running services, use with caution.

I struggle to see why this is bad?

[abernix]

Our recommendation is that you use a single source of truth for the schema to avoid schema flapping during roll-outs. With one running instance of every downstream service (i.e. no load-balancer in front of downstream services), it's fine. However, a single server is not very scalable and usually, there is a load-balancer in front of those containers. In that mode of operation and with polling enabled, if a downstream service is in the middle of a rollout and containers are changing from running one schema to another, the gateway (or multiple gateways) may start flapping back and forth between in-flight schemas during the roll-over as they poll.

One of the offerings of our cloud product provides that single source of truth: Basically, we host the fully-composed schema in our schema registry. It updates automatically when you use apollo service:push to push a new schema which also validates that the schema changes are not inadvertently breaking for existing clients based on actual usage metrics. The gateway then rolls over to the new services once the new schema is available. This can be even further stabilized by having blue-green deployments and only triggering the gateway rollover when the new service is available. For reliability purposes, our "schema registry" is a highly-available and durable storage bucket (e.g., Amazon S3 or Google Cloud Storage) which we manage for you. This is a free Apollo offering!

Hope that helps explain the risk! Of course, if that isn't relevant to you — or isn't relevant yet, then you can probably use the option safely.

[repl-chris]

Sorry, this is probably a dumb question, but could you explain why schema flapping is bad/dangerous? During this deployment period clients may get the old or the new schema...but, really, that would be the case anyways even without the flapping. Granted, now it's possible that a client may get the old schema after they've already gotten the new schema, but is that really an issue? Do clients generally retrieve the schema multiple times? I'm a bit of a newbie, so it's likely I don't fully understand how the schema is used. Thanks!