awslabs / awslabs/aws-mobile-appsync-sdk-android
Use Android apollo-client as a dependency instead of modifying its code
- Dominant language
- Java
- Stars
- 106
- Forks
- 56
- PR merge metrics
- No merged PRs in 30d
Description
While looking at AppSync code it is obvious that large part of it is just a fork of https://github.com/apollographql/apollo-android
Also that fact is stated in the doc on the first page.
For example class
AppSyncResponseFetchers
is exactly the same like
ApolloResponseFetchers
down to the docs. Only class name and Licence header are different in this case.
My guess is that team behind the Android Sdk has more legal knowledge than me so this is probably aligned with MIT licenced source. But from the technical point of view it is a complete puzzle why it's done this way.
Could the Apollo lib be a dependency of this project and AWS added classes another artifact?
Having it setup like this would allow users of this library to chose the Apollo client version they want to use, would allow them to more easily read the docs/tutorials and to know on which project to report bugs.
Contributor guide
Research direction
Start by comparing AppSyncResponseFetchers with ApolloResponseFetchers and then inspect the repository's Gradle dependency setup. Determine the scope of the duplicated Apollo code and how AWS-specific classes are separated. Done means the SDK consumes Apollo as a dependency, preserves its AWS additions, and builds successfully with the supported version choices documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, graphql, java
- Domain
- build-system, mobile-dev
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100