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:

5 Likes