OOP 2023, Online, Februar 2023, Sonja Wegner (Lead Software Architect @QAware) & Stefan Schmöller (Senior Software Engineer @QAware).
== Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! ==
With GraphQL a modern and flexible way of providing APIs for our data is emerging.
The clients specify which data they need, the provisioning of data becomes more flexible and dynamic. Over-fetching or under-fetching are history.
But does this mean we have to rewrite all APIs to benefit? How can we retrofit a GraphQL API onto our existing API landscape?
In this talk we explore three different alternatives:
- The Developer Way: Writing a GraphQL API layer by hand
- The Cloud-native Way: Using lightweight API gateways such as Gloo or Tyk
- The Serverless Way: Using Cloud Provider native services
We will look at all three approaches conceptually and justify when and why each makes sense. Additionally, we will show in a live demo how GraphQL APIs can be added to an existing REST API.
Your API on Steroids - Retrofitting GraphQL by Code, Cloud Native or Serverless
1. qaware.de
Your API on Steroids
Retrofitting GraphQL by Code, Cloud Native
or Serverless
Sonja Wegner and Stefan Schmöller, QAware GmbH
2. Sonja Wegner
Lead Software Architect @ QAware GmbH
Stefan Schmöller
Senior Software Engineer @ QAware GmbH
3. Agenda
Why GraphQL?
The Developer Way: Writing a GraphQL API layer by hand
The Cloud-native Way: Using a lightweight API gateway
The Serverless Way: Using Cloud Provider native services
Conclusion and Q&A
4. What is it?
Query Language for APIs
and runtime to fulfill this
queries with existing data
Why do we want it?
Clients can dynamically
define the structure of
required data, which is then
returned by the server.
Over-fetching and
under-fetching are history!
Does it work?
Stay tuned :)
https://graphql.org/
5. Today’s Demo Use Case
■ What we will use today:
– Given: REST APIs for a conference (Sessions, Speaker, …)
– using Quarkus as Framework
– API calls have to be combined
6. Ask for what you want:
No more under-fetching or over-fetching
sessionId
sessionTitle
speakerLastName
sessionId
sessionTitle
firstName
lastName
currentLocation
phone
/sessions
/speakers/{speaker-id}
/schedule
Use Case 1:
● aggregate
● select only relevant attributes
● rename
7. Ask for what you want:
No more under-fetching or over-fetching
sessionId
sessionTitle
speakerLastName
sessionId
sessionTitle
firstName
lastName
currentLocation
phone
/full-schedule
/schedule-for-my-use-case
dateOfBirth
favoriteDish
shoeSize
Use Case 2:
● select only relevant attributes
of large API
11. “The Developer Way”: Directly offering a GraphQL API using
Quarkus
■ Initial situation: two seperate APIs for sessions and speakers at the conference
■ Idea: We implement a GraphQL-Endpoint providing and combining all the information
■
GET /sessions
[{
id: 1
title: “abc”
speaker: [1,2]
…
}]
GET /sessions/{id}
…
GET /speakers
[{
id: 1
firstName: “Bill”
lastName: “Gates”
…
}]
GET /speakers/{id}
…
GET
/sessions/speaker/{id}
[{
title:
…
}]
12. Summary: How to provide a GraphQL endpoint with Quarkus
■ Create a resource annotated with @GraphQLApi
■ Methods annotated with @Query(value=”...”) (or @Mutation) are made available at endpoint
– If value is specified, this is the name of the query (mutation)
– Otherwise the name of the method is used (get… will be removed)
– Schema is built using the Java Objects
■ @Description can be used to add a descriptive text
■ Types can be extended using @Source in methods
– Annotated Input parameter marks the type to be extended
– Extension happens automatically
– Return type defines what to add
■ Important application paths:
– /graphql → Application endpoint for GraphQL queries (can be changed via property)
– /graphql/schema.graphql → Request current schema
– /q/graphql-ui/ → GraphiQL UI for testing requests
14. ■ API Gateways
– are already widely used for several
use cases like routing,
authentication, …
■ GraphQL API Gateways can
– provide a single schema for several
microservices
– enhance APIs of services who are
not capable of GraphQL directly
– enable clients to query a
combination of available data
without having to know about the
service architecture
GraphQL via API Gateways
Ernie
GraphQL
Service
Bert Restful
Service v1
Bert Restful
Service v2
GraphQL
API
Gateway
15. Demo with Tyk
■ We will setup a Graph QL API with Tyk (tyk.io)
■ Tyk offers an open source API gateway, we are
using the “self-managed” version (requires a
license), as the open source version is fairly
limited
https://tyk.io/docs/tyk-on-premises/
Schedule +
Session Service
Tyk API
Gateway
20. The client side: Consuming a GraphQL service using Quarkus
■ Two different implementation variants:
– Dynamic
• Building the query with a fluent API
• Client returns a JsonObject of the GraphQL response
@Inject @GraphQLClient("ec-dynamic")
DynamicGraphQLClient client;
@GET @Path("sessions")
public Uni<JsonObject> getSessions() {
Document query = document(operation(
field("sessions",
field("startTime"),
field("title"),
field("speaker",
field("fullName")
)
)
));
return client.executeAsync(query).map(Response::getData);
}
21. The client side: Consuming a GraphQL service using Quarkus
■ Two different implementation variants:
– Typesafe
• Define the DTOs and let Quarkus do the rest
• DTOs are related via Query name and GraphQL schema
• Annotations can be used for name mapping
public class EngineeringCampTypesafeResource {
@Inject
EngineeringCampTypesafeClient client;
@GET @Path("sessions")
public Uni<List<Session>> getSessions() {
return client.getAllSessions();
}
}
@GraphQLClientApi(configKey = "ec-typesafe")
public interface EngineeringCampTypesafeClient {
@Query(value = "sessions")
Uni<List<Session>> getAllSessions();
}
22. qaware.de
QAware GmbH
Aschauer Straße 32
81549 München
Tel. +49 89 232315-0
info@qaware.de
twitter.com/qaware
linkedin.com/company/qaware-gmbh
xing.com/companies/qawaregmbh
slideshare.net/qaware
github.com/qaware
Conclusion and Q&A