Home

#Overview SchemaGen GraphQL is designed to be the connector between your Application and the GraphQL-Java schema and Execution package. At the highest level this package provides annotations and supporting classes for turning POJO's into an executable GraphQL Schema definition.

This includes (but is not limited to):

• Annotations for defining your GraphQL Schema
• Generics Type Mapper for turning POJO's and Annotation markup in an Executable GraphQL Schema
• Datafetchers for connecting the Schema Model to your application
• Typeconverters for converting different special Java types into the High Level types supported by Graphql
• Extensions points for customizing all of the above behavior

The best way to become familiar with the SchemaGen GraphQL is to go through the example applications and to read this wiki.

---

Benefits of Graphql

At the heart of GraphQL is the exposure of your data model as a query able, connected graph. This changes our thinking about how we interact with wb services from one of

What endpoints does the server provide and what data do these queries return

into one more

What is data model that server exposes and how do I want to query it to get the information I need

This is a fundamental shift in how we think about web services. It's more akin the server being a database that can can connect directly to and write any query we want to get the data we need and nothing else.

The benefits that come along with this is:

• GraphQL is self documenting.
• GraphQL is explorable
• Data fetching and Server round trips can be minimized
• Extract the exact sub-graph of the data model you need
• Batch these sub-graph extractions into a single web request
• Perform single or batch mutations of these sub-graphs

---

Data as a connected graph

Typically when we wish to expose our data model to a Front end, for example a Web UI, we will:

1. Create a Web version of our business objects as a set of DTO's representing the Entities (or nodes in a graph) we wish to expose.
2. Create a list of endpoints exposing queries that can be executed on a page by page bases, consolidating appropriately.
3. Optionally create another list of endpoints that support paging through different relationships
4. Optionally create different Detail levels of the same DTO's to for objects that are large and needed in views with low detail or high detail views.

• Or alternatively create one master DTO and only fill in the fields required and not serialize null fields.

If you're lucky you only have to do #1 and #2 above. Once you enter into the realm of #3 and #4 things get hellish pretty fast. You get an explosion of endpoints just for paging through relationships due to large plurality of the relationships and the need for fast/efficient UI's. Additionally you have an explosion of DTO's to represent different Detail levels of DTO's with a large number of properties, or to only return a predefined set of relationships and fields needed for different views. The alternative is to over-fetch and just get the entire thing slowing down both you're front end and backend creating a varying quality of user experience.

Graph QL solves one of these problems very well, #4 above, by requiring the UI to specify a view of the Data Model to return so that you only need one set of DTO's and can return different lightweight slices based upon the view your trying to provide to the user.

Graph QL doesn't directly solve problem #3, but it provides a path to solving this problem which is discussed in the section Be Lazy when you can.