Feedback thread: Future deprecation of serviceList in ApolloGateway

So, going to share a bit of a hot take here. :stuck_out_tongue: I want to start by being VERY CLEAR that this is my attempt to be honest and not to be hostile. I love Apollo and the products this team pumps out!

Iā€™ve been a massive fan of federation and my team was a very early adopter of it. I understand the advantages/disadvantages of managed versus unmanaged but thus far we have gone with unmanaged for three reasons:

1.We like the dynamic nature of being able to deploy a single microservice and the changes in schema be picked up immediatelyā€¦ especially when doing local development. Itā€™s nice to not have to restart services.
2.We donā€™t have any plans to utilize Apollo Studio for a variety of reasons.
3. There isnā€™t a stable, well-documented way to do home-grown managed federation.

What worries me about this deprecation, and the direction Iā€™ve seen Apollo seeming to go, is it seems that there is a push for ā€œuse our paid services or elseā€. This is a major step back from the typical monetized open source model that I typically see where it is more ā€œHereā€™s an awesome open source product. Here are additional features/functionality/support that you CAN use to add additional value.ā€

This change to remove serviceList, with a lack of stable and documented way to NOT use studio, is anti-open source, in my opinion, because it leaves zero options for consumers who are not in the Studio ecosystem.

For this to be ā€œfairā€ open source product that doesnā€™t back consumers into a corner and that doesnā€™t leave consumers stranded, consider eitherā€¦

  1. Leave serviceList as is or
  2. Provide VERY CLEAR alternatives for consumers not using the Studio ecosystem.

Again, trying to provide this outside prospective as a consumer who loves the library. :slight_smile:

6 Likes

Hey all, firstly thank you for everyoneā€™s input. I know this is a hot topic and I appreciate everyoneā€™s willingness to contribute to the conversation.

I donā€™t think what weā€™re proposing is a contentious change, so Iā€™d like to make at least this bit perfectly clear in case there was any misunderstanding. We have every intention of supporting past functionality with the replacement weā€™re proposing. Use of the word ā€œdeprecatingā€ may have sent the wrong message, since our plan is to replace this bit of API with something entirely more capable than just polling your services. The new API should be inclusive of all existing use cases while supporting a reactive model that weā€™d like to recommend going forward.

Iā€™ve opened a GH issue and expect to start work on this change as soon as I reasonably can, which realistically should be some time this month. Thereā€™s something of a proposal written in there which Iā€™m happy to refine/concretize if anything is unclear, but I think thereā€™s enough there for others to chime in and provide feedback. Iā€™m very interested in hearing if there are any gaps for existing use cases, so I encourage anyone to look and participate.

https://github.com/apollographql/federation/issues/1180

4 Likes

This change has landed to the v0.x branch and is available as an alpha for testing. I encourage anyone interested in these changes to try it out and provide any feedback! I expect to release this on both v0.x and v2 late this week / early next week.

npm install @apollo/gateway@0.46.0-alpha.0

The PR: https://github.com/apollographql/federation/pull/1246

Thanks again!

4 Likes

This is now officially released for both latest branches of the @apollo/gateway package :tada:

v0.46.0 (latest tag)
v2.0.0-alpha.4 (latest-2 tag)

1 Like

Hey!
Didnā€™t read through the entire thread but I assume it is related ā€“ we are currently using serviceMap to identify our subgraphs in runtime and fetch data from our database according to the subgraph that the request is made to, I elaborated more on this stackoverflow topic ā†’

https://stackoverflow.com/questions/69988248/apollo-graphql-dynamic-authenticated-subgraphs

Where I want to create dynamic flow in accordance to the required subgraph, and I see that internally serviceMap is using serviceList in its implementation ā€“ is it also on the way to deprecation?

Hey @Avivon, Iā€™m not quite sure I follow. I donā€™t see where youā€™re making use of serviceMap in your example.

I think I see where youā€™re referring to serviceMap depending on serviceList, however I think that particular serviceList is not the same as the one thatā€™s public API and deprecated.