apollographql / apollo-kotlin Goto Github PK

Response for query with fragments has different shape than generated model classes.
Custom moshi JsonAdapter should be implemented in order to support parsing response for queries with fragments

Like Sqldelight does

Example query:

query inlineFragmentNoType($expandedInfo: Boolean) {
  user(handle: "zuck") {
    id
    name
    ... on User @include(if: $expandedInfo) {
      firstName
      lastName
      birthday
    }
  }
}

For fragment spreads, we can augment the fragment spread in the IR with an isConditional field.

Pojo generation is optional and defined by flag generateClasses in GraphQLCompiler.
This flag should be exposed as configuration option for apollo-gradle-plugin

The gradle plugin doesn't seem to be respecting the original package name of each graphql file and just adding them all into the generatedIR package (eg.: build/generated/source/apollo/generatedIR/DroidDetails.java)

The generated package name should match the original file path.

The gradle task should read the .graphql files and use apollo-codegen to translate them into IR files.
Once we have the IR, we can use GraphQLCompiler to generate the interfaces.

Usage and features etc

The Android Gradle plugin 2.3.0-beta1 defaults to Gradle 3.2, so we should make sure our plugin works with that version. Right now the tests are failing on 3.2

apollo-codegen supports downloading the schema by sending an introspection query to the server.
It would be nice to have a task that utilizes apollo-codegen download

Create generic GraphQLQuery interface like iOS does
Generate query class implemtentation for each query by implementing GraphQLQuery.
Generated query class implemtentations should allow set arguments.

See https://github.com/apollostack/apollo-android/blob/design-doc/DESIGN.md#query-classes
Swift examples can be found here: https://github.com/apollostack/apollo-ios/blob/master/Tests/ApolloTests/StarWars/API.swift

Query data model generated by apollo android plugin is represented by interfaces. In order to deserialize query response (json) and map it to the data model, apollo service requires to know about the user defined instance classes of that data model. Generated interface declares only accessor api calls to fields (no setters and of course no fields).

Questions:

1. As we discussed before, custom retrofit converter will be implemented in order to support deserializing response. How this converter will get knowledge about setters / fields of user defined data model implementations to be able to map json response fields?

2. How converter is going to instantiate the user defined instances of the model interfaces?

One approach that we considered user uses AutoValue lib to generate instances of data model interfaces. Here is an example of generated model interface:

public interface Data extends Query.Data {
     Hero hero();

    interface Hero {
       String name();

       AsHuman asHuman();

      interface AsHuman {
         String name();

         List<Friend> friends();

         Float height();

        interface Friend {
           String name();

           List<Episode> appearsIn();
        }
      }
...

Then from user to use AutoValue requires to define abstract classes / interfaces that extend all interfaces: Data, Data.Hero, Data.Hero.AsHuman, Data.Hero.AsHuman.Friend etc. with @AutoValue annotation that seems too overwhelming . Even more AutoValue generates immutable value objects that initialize fields inside constructor. So retrofit converter has to parse response json and pass parsed field values as parameters to this constructor.
But converter doesn't know anything about user defined instance classes and especially about how to construct them, so it will require some sort of factory the same approach as SQLDelight implements.

All this complication brings to question, maybe we have to change our code generation to have model be classes with fields, rather then interfaces.

@felipecsl @martijnwalraven @marwanad

We can generate Retrofit service with all defined query endpoints to follow with this pattern:

public interface ApiService {
    @POST
    Call<Response<%QUERY_TYPE%.Data>> %QUERY_NAME%(@Body GraphQlOperationRequest<%QUERY_TYPE%.Variables> query);
...
  }

This generated service to be used with Retrofit client:

ApiService apiService = retrofit.create(ApiService.class);

With such service declaration Retrofit client must be configured with base url pointed to graphql endpoint.

 Retrofit retrofit = new Retrofit.Builder()
        .baseUrl("http:// ..... /graphql/")

In most GraphQL service implementations, there is also a way to specify custom scalar types. For example, we could define a Date type

Add support of type conditions
Design doc ref https://github.com/apollostack/apollo-android/blob/design-doc/DESIGN.md#type-conditions

Example: #27 (comment)

As discussed on #15
Need to use the field responseName as the interface name and handle duplicated names by making them unique

All Junit tests in GraphQLCompilerTest follow the same pattern:

1. check actual generated file with expected
2. compile

A lot of code duplication. We can do better, define only test fixtures (probably map of actual / expected file paths) and run tests against them

In order to support mutation operation support input types is required.

Query as example :

mutation CreateReviewForEpisode($ep: Episode!, $review: ReviewInput!) {
  createReview(episode: $ep, review: $review) {
    stars
    commentary
  }
}

IR json:

{
	"operations": [
		{
			"operationName": "CreateReviewForEpisode",
			"operationType": "mutation",
			"variables": [
				{
					"name": "ep",
					"type": "Episode!"
				},
				{
					"name": "review",
					"type": "ReviewInput!"
				}
			],
			"source": "mutation CreateReviewForEpisode($ep: Episode!, $review: ReviewInput!) {\n  createReview(episode: $ep, review: $review) {\n    stars\n    commentary\n  }\n}",
			"fields": [
				{
					"responseName": "createReview",
					"fieldName": "createReview",
					"type": "Review",
					"fields": [
						{
							"responseName": "stars",
							"fieldName": "stars",
							"type": "Int!"
						},
						{
							"responseName": "commentary",
							"fieldName": "commentary",
							"type": "String"
						}
					],
					"fragmentSpreads": [],
					"inlineFragments": []
				}
			],
			"fragmentsReferenced": []
		}
	],
	"fragments": [],
	"typesUsed": [
		{
			"kind": "EnumType",
			"name": "Episode",
			"description": "The episodes in the Star Wars trilogy",
			"values": [
				{
					"name": "NEWHOPE",
					"description": "Star Wars Episode IV: A New Hope, released in 1977."
				},
				{
					"name": "EMPIRE",
					"description": "Star Wars Episode V: The Empire Strikes Back, released in 1980."
				},
				{
					"name": "JEDI",
					"description": "Star Wars Episode VI: Return of the Jedi, released in 1983."
				}
			]
		},
		{
			"kind": "InputObjectType",
			"name": "ReviewInput",
			"description": "The input object sent when someone is creating a new review",
			"fields": [
				{
					"name": "stars",
					"description": "0-5 stars",
					"type": "Int!",
					"defaultValue": null
				},
				{
					"name": "commentary",
					"description": "Comment about the movie, optional",
					"type": "String",
					"defaultValue": null
				},
				{
					"name": "favoriteColor",
					"description": "Favorite color, optional",
					"type": "ColorInput",
					"defaultValue": null
				}
			]
		},
		{
			"kind": "InputObjectType",
			"name": "ColorInput",
			"description": "The input object sent when passing in a color",
			"fields": [
				{
					"name": "red",
					"description": "",
					"type": "Int!",
					"defaultValue": null
				},
				{
					"name": "green",
					"description": "",
					"type": "Int!",
					"defaultValue": null
				},
				{
					"name": "blue",
					"description": "",
					"type": "Int!",
					"defaultValue": null
				}
			]
		}
	]
}

Latest apollo-codegen:0.9.5 includes type information as part of typesUsed.
See apollographql/apollo-tooling@a90cf59

Generation of fragments doesn't annotate accessor methods with Nullable / Nonnull annotation

interface Hero {
      Fragments fragments();

      interface Fragments {
        HeroDetails heroDetails();
      }
    }

For stuff that will be needed while running the app (eg.: executing queries, etc.)

It should have a simple builder interface that takes at least a retrofit object and is able to fire GraphQL requests using the generated query interfaces and optionally arguments.

Example of query:

query Query {
  hero {
    name
    friends {
      name
    }
    ... on Human {
      height
      friends {
        appearsIn
 		friends {
  			...HeroDetails
		}   
      }
    }
  }
}

fragment HeroDetails on Character {
	name
	friendsConnection {
		totalCount
		edges {
			node {
				name
			}
		}
	}
	... on Droid {
		name
		primaryFunction
	}
}

As reference here is how it's used on iOS:
https://github.com/apollostack/apollo-ios/blob/master/Tests/ApolloTests/StarWars/API.swift

See #13 for more details

Append an extra $ character at the end of the interface name to avoid conflicts

eg.:

public interface QueryName {
  String name();
  Hero hero();
  interface Hero {
    List<Hero> friends();
    interface Hero {
      long id();
    }
  }

From Slack discussion:

felipecsl [12:21 PM]
@martijnwalraven I was looking at the HeroAppearsIn query and the generated IR references the Episode type in the typesUsed array, however its definition can’t be found anywhere in the data. Also I checked the Swift code generated for that query and noticed that it does include a public enum Episode. Sounds like we’re gonna have to add the definition of any external types to the IR so we can generate code based solely on the IR. It sounds like the Swift generator is retrieving that data from somewhere else

The interface should have methods for each of the queries found in the IR files with the correct Data types.

Add with @Nullable annotations to methods

Add support for @skip and @include directives

query HeroNameInclusionDirective {
     hero {
          name @include(if: someCondition)
        }
}

There would be an isConditional field in the IR and handling those should be somewhat similar to handling nullability.

Add integrations tests to the Gradle plugin and update the sample project

For example, it's incorrectly singularizing species to specy

Make sure the package name includes graphql so it's clearer