menu

Apollo

A community of developers, designers and others who love Apollo and GraphQL. 🚀

Channels
# All channels
view-forward
# General
view-forward
# Apollo Angular
view-forward
# Announcements
view-forward
# Apollo Android
view-forward
# Apollo Client
view-forward
# Apollo iOS
view-forward
# Apollo Link
view-forward
# Apollo Link Rest
view-forward
# Local State
view-forward
# Apollo Studio
view-forward
# Apollo Server
view-forward
# Apollo Tooling
view-forward
# Contributing
view-forward
# Docs
view-forward
# Events
view-forward
# GraphQL Tools
view-forward
# Jobs
view-forward
# Random
view-forward
# React Apollo
view-forward
# Showcase
view-forward
# Subscriptions
view-forward
# Testing
view-forward
# Vue Apollo
view-forward
Team

Is generated code safe to use across multiple Apollo versions?

January 27, 2021 at 7:37pm

Is generated code safe to use across multiple Apollo versions?

January 27, 2021 at 7:37pm (Edited 3 months ago)
For example, is it safe to assume a library/sdk that contains generated Apollo code from 2.4.1 can integrate into an app using Apollo 2.5.2? Gradle in this scenario will upgrade Apollo 2.4.1 in the library to 2.5.2, resulting in it reading generated code from an older version. This will certainly break when going too far back in versions, but I'm more curious about the recent + future versions of Apollo.
If it's not deemed safe, it would seem the only solution (which most SDKs should then do) is to shadow/rename Apollo + the generated classes in the library, correct?

January 27, 2021 at 10:49pm
Hi Daniel 👋.
Gradle in this scenario will upgrade Apollo 2.4.1 in the library to 2.5.2, resulting in it reading generated code from an older version.
If I understand correctly, the generated classes (from the lib) will be compiled against 2.4.1 and end up in lib.jar. At runtime these classes will run against 2.5.2
This transition should be fairly safe. More generally, we try to follow semantic versioning. While there might have been some exceptions in the past, we now have tools like metalava and japicmp to ensure API's are backward compatible. Furthermore, the generated code uses only classes from the apollo-api module which is a relatively small part of apollo-android that moves less frequently so it should really be safe.
Shading the whole library is a last resort option as that will duplicate some bytecode. I'm not too familiar with the shadow plugin but I think you'll have to relocate com.apollographql.apollo in the lib module (where generated classes are) as well as apollo-runtime and apollo-api (and other support artifact like coroutines if you use them).
I'm hoping you won't have to do that though. As said above, I'm fairly confident 2.4.1 -> 2.5.2 works well. Let us know how that went!
like-fill
1
  • reply
  • like