Allow gateway to dynamically reload schema in self-managed federation

[kuskoman]

Since one of the latest releases (prolly 0.23) we no longer have ability to call .load() to reload previously loaded schema.

I used this function to reload it on development environments. At this moment to be able to call this function I have to make this workaround:

import { ApolloGateway } from '@apollo/gateway';

export class Gateway extends ApolloGateway {
    public async refreshSchema() {
        return await this.updateComposition();
    }
}

to be able to call this protected method updateComposition.

Is there any other way to do that (or is going to be)?

[glasser]

Hi! When I did the refactoring in v0.23.0 (#452) I didn't realize that calling load more than once was something people did. In my mind, since load() sets up background tasks that can (and should) be stopped, it should be something that is only called once — the difference between "start the gateway" and "do a single load in the middle". But it sounds like I'm missing a use case here!

Out of curiosity, what's the use case for you here? Are you reloading from managed federation, or reloading from a file on disk somehow, or what?

I'm wondering if the best fix is to return load to being OK to call more than once, or to publicly expose the "do a single load" method (updateComposition, perhaps with a different name) for this case.

@trevor-scheer do you have any thoughts?

[kuskoman]

@glasser Hi! I am working for a company, where we are using apollo gateway in many big projects. We are working with microservices, which are able to hot-reload code in local environments. In our use case we are calling this method after every service reload, since we found this method the easiest way to fetch the latest version of schema. Of course there are better ways to reload gateway on other environments, this way is used only by backend devs on localhost.

I understand that this way of reloading schema was some kind of workaround, however as I said, at this moment I don't know about a better way of doing it on local environments, where speed is the biggest priority

Edit: sorry for the confusion, by writing self-managed I meant not using apollo engine/studio, etc., because it's a local setup

[glasser]

Makes sense to me. I do think we need a difference between "the function we call once to start the gateway which loads and perhaps also sets up background processes that may need to be stopped" and "a single instance of loading the schema". Answer might just be to make updateComposition public, maybe just with a different name. Thoughts @trevor-scheer?

(FYI — I'm on vacation next week. If this is an immediate problem for you I'd recommend staying on v0.22 for now.)

[brettski]

Out of curiosity, what's the use case for you here? Are you reloading from managed federation, or reloading from a file on disk somehow, or what?

@glasser we have a similar setup at THAT where we utilize a micro service configuration running our child api's which are are all federated together. When one of the children are updated/deployed, we would run load() to have the gateway refresh the schema. As mentioned, with the update in version 0.23.0 we are no longer able to run load() and have fixed the federation to version 0.22.0 for now.

Honestly I am not sure what the correct approach here is for us to keep the schema current at the federation service.

[glasser]

OK, this seems reasonable. I'll add some sort of pollSchema() call which has the semantics of:

• If we're currently waiting to poll, transition immediately into polling and wait for it to conclude
• If we're currently polling, wait for the current poll to finish and then immediately poll again and wait for it to include

Because @trevor-scheer 's PR https://github.com/apollographql/federation/pull/458 refactors the loading logic I think I want to wait until that PR is completed, but I'll put a reminder for myself to address this after that merges.

[brettski]

Greetings @glasser . Any updates on this or work-arounds discovered we can use? I noticed that PR #458 has been merged.

Thank you!

[glasser]

I haven't forgotten this issue, but I have not worked on it yet, sorry.

[brettski]

I am not sure if this is going to happen. We are still stuck on server version 0.22.2 and would like to get our bits up to date. Are there other options for us to run multiple function Apollo servers and keep federation up-to-date?

[brettski]

Hello @glasser. We are curious to know if this update may still happen. Is this still a feasible option for Apollo and make it into the application? Thank you.

[glasser]

Heh, I've had this on my back-burner for a bit, but it would probably be a good idea to raise its priority a bit. I also think it might not be too hard for somebody else to implement based on the description at https://github.com/apollographql/federation/issues/461#issuecomment-791819823 ...

[kuskoman]

@glasser as a person who needs it (actually company I work for needs it, right now we are using workarounds) I can work on it, but probably over weekend after this weekend (28-29 august), so anyone can feel free to do it, but if nobody is interested in it, I can take it

[brettski]

Heh, I've had this on my back-burner for a bit, but it would probably be a good idea to raise its priority a bit. I also think it might not be too hard for somebody else to implement based on the description at #461 (comment) ...

I was wondering with serviceList on its way of being deprecated, is this still a feasible option for Apollo Server? I am assuming this solution only works with a serviceList federation configuration. Personally I like the serviceList approach, though it seems pre-generated schemas (Rover CLI && managed federation) is the future...