Slajdy z konferencji Confitura 2019.
Wszyscy znamy podejście REST do definiowania API naszych aplikacji. Jednak REST ma swoje wady i ograniczenia. To dla tego Facebook stworzył GraphQL jako alternatywę. W mojej prezentacji przedstawię ograniczenia RESTa i jak je rozwiązuje GraphQL. Pokażę składnię, zalety jak i wady. Będzie też jak zaimplementować GraphQL w Javie oraz co jeszcze warto o nim wiedzieć.
[DevCrowd] GraphQL - gdy API RESTowe to za małoMarcinStachniuk
Slajdy z konferencji DevCrowd
Wszyscy znamy architekturę REST do definiowania API naszych aplikacji. Jednak REST ma swoje wady i ograniczenia. To dlatego Facebook stworzył GraphQL jako alternatywę. W mojej prezentacji przedstawię ograniczenia RESTa i jak je rozwiązuje GraphQL. Pokażę składnię, zalety jak i wady. Będzie też o tym jak zaimplementować GraphQL w Javie oraz co jeszcze warto o nim wiedzieć.
GraphQL - when REST API is to less - lessons learnedMarcinStachniuk
We all know the REST architectural style to define a good API for your applications. However, REST has its disadvantages and constraints. That’s why Facebook developed GraphQL as an alternative.
In my talk, I will present you some REST constraints and how GraphQL solves them. I will talk about how we implemented GraphQL in our application and why.
Get to know our successes… and failures from the first row.
Web APIs have revolutionized all kinds of products and services, and still continue to do so. Nowadays the most relevant architecture is REST along with the JSON media type. Furthermore, lots of specifications to serialize those media types are appearing. JSON API has released its first version last May.
JSON-LD is a set of W3C standards track specifications for representing Linked Data in JSON. It is fully compatible with the RDF data model, but allows developers to work with data entirely within JSON.
More information on JSON-LD can be found at http://json-ld.org/
[DevCrowd] GraphQL - gdy API RESTowe to za małoMarcinStachniuk
Slajdy z konferencji DevCrowd
Wszyscy znamy architekturę REST do definiowania API naszych aplikacji. Jednak REST ma swoje wady i ograniczenia. To dlatego Facebook stworzył GraphQL jako alternatywę. W mojej prezentacji przedstawię ograniczenia RESTa i jak je rozwiązuje GraphQL. Pokażę składnię, zalety jak i wady. Będzie też o tym jak zaimplementować GraphQL w Javie oraz co jeszcze warto o nim wiedzieć.
GraphQL - when REST API is to less - lessons learnedMarcinStachniuk
We all know the REST architectural style to define a good API for your applications. However, REST has its disadvantages and constraints. That’s why Facebook developed GraphQL as an alternative.
In my talk, I will present you some REST constraints and how GraphQL solves them. I will talk about how we implemented GraphQL in our application and why.
Get to know our successes… and failures from the first row.
Web APIs have revolutionized all kinds of products and services, and still continue to do so. Nowadays the most relevant architecture is REST along with the JSON media type. Furthermore, lots of specifications to serialize those media types are appearing. JSON API has released its first version last May.
JSON-LD is a set of W3C standards track specifications for representing Linked Data in JSON. It is fully compatible with the RDF data model, but allows developers to work with data entirely within JSON.
More information on JSON-LD can be found at http://json-ld.org/
Presentation of the paper "Creating 3rd Generation Web APIs with Hydra" at the 22nd Internation World Wide Web Conference (WWW2013) in Rio de Janeiro, Brazil
Hydra: A Vocabulary for Hypermedia-Driven Web APIsMarkus Lanthaler
Presentation of the paper "Hydra: A Vocabulary for Hypermedia-Driven Web APIs" at the 6th Workshop on Linked Data on the Web (LDOW2013) at the WWW2013 in Rio de Janeiro, Brazil
An introduction to modern web technologies HTML5, including Offline, Storage, and Canvas Embedded JavaScript RESTful WebServices using MVC 3, jQuery, and JSON Going mobile with PhoneGap and HTML and CSS
BruJUG Brussels GraphQL when RESR API is to less - lessons learnedMarcinStachniuk
We all know the REST architectural style to define a good API for your applications. However, REST has its disadvantages and constraints. That’s why Facebook developed GraphQL as an alternative.
In my talk, I will present you some REST constraints and how GraphQL solves them. I will talk about how we implemented GraphQL in our application and why.
Get to know our successes… and failures from the first row.
GraphQL - Piękne API w Twojej Aplikacji - KrakowGraphAcademyMarcinStachniuk
Wszyscy znamy i tworzymy API RESTowe. Jednak to podejście ma swoje wady i ograniczenia. Dlatego Facebook stworzył GraphQL jako alternatywę. W mojej prezentacji przedstawię problemy RESTa oraz jak je rozwiązuje GraphQL. Pokażę składnię, jak projektować takie API oraz zalety i wady.
Cdm mil-18 - hypermedia ap is for headless platforms and data integrationDavid Gómez García
Slides from my talk at Codemotion Milan 2018. Speaking about how Headess and Hypermedia REST APIs can leverage the way . we integrate different platforms and share date between them
David Gómez G. - Hypermedia APIs for headless platforms and Data Integration ...Codemotion
We live in a interconnected world, were every day new devices, systems, and applications are connected to share information or interact between them. Thus, the importance of designing systems prepared to offer their services and data to a wide range of customers, that could discover, navigate and use their API in a standard and easy way to be consumed. But designing a headless platform to be used easily through their services is not straightforward. In this talk we will go over the challenges that we've found in adding headless nature to our platform and the foundations and tools that we have
Presentation of the paper "Creating 3rd Generation Web APIs with Hydra" at the 22nd Internation World Wide Web Conference (WWW2013) in Rio de Janeiro, Brazil
Hydra: A Vocabulary for Hypermedia-Driven Web APIsMarkus Lanthaler
Presentation of the paper "Hydra: A Vocabulary for Hypermedia-Driven Web APIs" at the 6th Workshop on Linked Data on the Web (LDOW2013) at the WWW2013 in Rio de Janeiro, Brazil
An introduction to modern web technologies HTML5, including Offline, Storage, and Canvas Embedded JavaScript RESTful WebServices using MVC 3, jQuery, and JSON Going mobile with PhoneGap and HTML and CSS
BruJUG Brussels GraphQL when RESR API is to less - lessons learnedMarcinStachniuk
We all know the REST architectural style to define a good API for your applications. However, REST has its disadvantages and constraints. That’s why Facebook developed GraphQL as an alternative.
In my talk, I will present you some REST constraints and how GraphQL solves them. I will talk about how we implemented GraphQL in our application and why.
Get to know our successes… and failures from the first row.
GraphQL - Piękne API w Twojej Aplikacji - KrakowGraphAcademyMarcinStachniuk
Wszyscy znamy i tworzymy API RESTowe. Jednak to podejście ma swoje wady i ograniczenia. Dlatego Facebook stworzył GraphQL jako alternatywę. W mojej prezentacji przedstawię problemy RESTa oraz jak je rozwiązuje GraphQL. Pokażę składnię, jak projektować takie API oraz zalety i wady.
Cdm mil-18 - hypermedia ap is for headless platforms and data integrationDavid Gómez García
Slides from my talk at Codemotion Milan 2018. Speaking about how Headess and Hypermedia REST APIs can leverage the way . we integrate different platforms and share date between them
David Gómez G. - Hypermedia APIs for headless platforms and Data Integration ...Codemotion
We live in a interconnected world, were every day new devices, systems, and applications are connected to share information or interact between them. Thus, the importance of designing systems prepared to offer their services and data to a wide range of customers, that could discover, navigate and use their API in a standard and easy way to be consumed. But designing a headless platform to be used easily through their services is not straightforward. In this talk we will go over the challenges that we've found in adding headless nature to our platform and the foundations and tools that we have
Tomer Elmalem - GraphQL APIs: REST in Peace - Codemotion Milan 2017Codemotion
This talk will introduce attendees to GraphQL and then dive into the intricacies of how we built the API. It’ll cover end-to-end the flow we provide to our developers and some of the specific considerations we took when making it a public API: * solving the N+1 data retrieval problem and query planning * structuring models for optimal data retrieval * when to use GraphQL This talk will also cover some of the specifics of hooking GraphQL into a service-oriented architecture, how it’s built into our infrastructure, and the advantages you gain by having GraphQL interface with your services.
Example-driven Web API Specification DiscoveryJavier Canovas
Slides of my presentation at European Conference on Modelling Foundations and Applications (ECMFA'17). To be presented during the session on Thursday 16:00-17:30
Moje slajdy z prezentacji na GraphQL Wroclaw #3 https://www.meetup.com/GraphQL-Wroclaw/events/261828347/
Większość prezentacji dotyczących GraphQL opowiada o JavaSkryptowych narzędziach, natomiast mało kto mówi o tym jak korzystać z GraphQL w Javie. Prezentacja będzie o tym, jak sprawić aby nasz backendowy, Javowy serwer korzystał z GraphQL. Będzie o możliwych podejściach w implementacji, dobrych praktykach i 4-letnim doświadczeniu z GraphQL na produkcji.
Do you know how Continuous Delivery of Java Open Source libraries looks? How big is your release overhead? Do you update release notes and include contributors manually? How do you handle versioning? Do you use semantic versioning?
During this workshop, you will learn how to set up Continuous Delivery for your library. You’ll never have to manually release new versions again. We will use the following tools: GitHub, TravisCI, Bintray, Maven Central. We will glue everything using Shipkit.org - a project born from Mockito (and still used there). You’ll additionally learn SerVer.
This workshop is mostly for Java open source and Gradle plugins developers. We will use a library prepared especially for this training, so no worries if you don’t have your own open source project (yet).
Prerequisites: GitHub account, Java & Gradle basics.
Continuous delivery w projekcie open source - Marcin StachniukMarcinStachniuk
Opublikowałeś swój projekt jako Open Source i zastanawiasz się co dalej? Jaki jest twój następny krok? Podczas prezentacji przedstawię, w jaki sposób można zbudować darmowy pipeline continuous delivery dla twojego projektu. Praca wtedy stanie się od razu przyjemniejsza i będzie można zapomnieć o nudnych i powtarzalnych czynnościach. Dodatkowo podpowiem jak zadbać o swój projekt, aby wyglądał profesjonalnie.
Prezentacja na targi Kariera IT 2017 we Wrocławiu.
Liquibase - Zarządzanie zmianami w relacyjnych bazach danychMarcinStachniuk
Prezentacja wygłoszona na Wrocławskim JUGu 30 września 2015. Prezentacja opisuje w jaki sposób można zarządzać zmianami w relacyjnych bazach danych i jak ten problem rozwiązuje Liquibase.
Podstawy tworzenia gier w J2ME, dla początkujących adeptów sztuki programowaniaMarcinStachniuk
Prezentacja pokazująca podstawy tworzenia gier w technologii J2ME z wykorzystaniem niskopoziomowego API.
Prezentacja dla osób zaczynających przygodę z programowaniem.
Enhancing Research Orchestration Capabilities at ORNL.pdfGlobus
Cross-facility research orchestration comes with ever-changing constraints regarding the availability and suitability of various compute and data resources. In short, a flexible data and processing fabric is needed to enable the dynamic redirection of data and compute tasks throughout the lifecycle of an experiment. In this talk, we illustrate how we easily leveraged Globus services to instrument the ACE research testbed at the Oak Ridge Leadership Computing Facility with flexible data and task orchestration capabilities.
Gamify Your Mind; The Secret Sauce to Delivering Success, Continuously Improv...Shahin Sheidaei
Games are powerful teaching tools, fostering hands-on engagement and fun. But they require careful consideration to succeed. Join me to explore factors in running and selecting games, ensuring they serve as effective teaching tools. Learn to maintain focus on learning objectives while playing, and how to measure the ROI of gaming in education. Discover strategies for pitching gaming to leadership. This session offers insights, tips, and examples for coaches, team leads, and enterprise leaders seeking to teach from simple to complex concepts.
Large Language Models and the End of ProgrammingMatt Welsh
Talk by Matt Welsh at Craft Conference 2024 on the impact that Large Language Models will have on the future of software development. In this talk, I discuss the ways in which LLMs will impact the software industry, from replacing human software developers with AI, to replacing conventional software with models that perform reasoning, computation, and problem-solving.
Developing Distributed High-performance Computing Capabilities of an Open Sci...Globus
COVID-19 had an unprecedented impact on scientific collaboration. The pandemic and its broad response from the scientific community has forged new relationships among public health practitioners, mathematical modelers, and scientific computing specialists, while revealing critical gaps in exploiting advanced computing systems to support urgent decision making. Informed by our team’s work in applying high-performance computing in support of public health decision makers during the COVID-19 pandemic, we present how Globus technologies are enabling the development of an open science platform for robust epidemic analysis, with the goal of collaborative, secure, distributed, on-demand, and fast time-to-solution analyses to support public health.
How to Position Your Globus Data Portal for Success Ten Good PracticesGlobus
Science gateways allow science and engineering communities to access shared data, software, computing services, and instruments. Science gateways have gained a lot of traction in the last twenty years, as evidenced by projects such as the Science Gateways Community Institute (SGCI) and the Center of Excellence on Science Gateways (SGX3) in the US, The Australian Research Data Commons (ARDC) and its platforms in Australia, and the projects around Virtual Research Environments in Europe. A few mature frameworks have evolved with their different strengths and foci and have been taken up by a larger community such as the Globus Data Portal, Hubzero, Tapis, and Galaxy. However, even when gateways are built on successful frameworks, they continue to face the challenges of ongoing maintenance costs and how to meet the ever-expanding needs of the community they serve with enhanced features. It is not uncommon that gateways with compelling use cases are nonetheless unable to get past the prototype phase and become a full production service, or if they do, they don't survive more than a couple of years. While there is no guaranteed pathway to success, it seems likely that for any gateway there is a need for a strong community and/or solid funding streams to create and sustain its success. With over twenty years of examples to draw from, this presentation goes into detail for ten factors common to successful and enduring gateways that effectively serve as best practices for any new or developing gateway.
Exploring Innovations in Data Repository Solutions - Insights from the U.S. G...Globus
The U.S. Geological Survey (USGS) has made substantial investments in meeting evolving scientific, technical, and policy driven demands on storing, managing, and delivering data. As these demands continue to grow in complexity and scale, the USGS must continue to explore innovative solutions to improve its management, curation, sharing, delivering, and preservation approaches for large-scale research data. Supporting these needs, the USGS has partnered with the University of Chicago-Globus to research and develop advanced repository components and workflows leveraging its current investment in Globus. The primary outcome of this partnership includes the development of a prototype enterprise repository, driven by USGS Data Release requirements, through exploration and implementation of the entire suite of the Globus platform offerings, including Globus Flow, Globus Auth, Globus Transfer, and Globus Search. This presentation will provide insights into this research partnership, introduce the unique requirements and challenges being addressed and provide relevant project progress.
We describe the deployment and use of Globus Compute for remote computation. This content is aimed at researchers who wish to compute on remote resources using a unified programming interface, as well as system administrators who will deploy and operate Globus Compute services on their research computing infrastructure.
Custom Healthcare Software for Managing Chronic Conditions and Remote Patient...Mind IT Systems
Healthcare providers often struggle with the complexities of chronic conditions and remote patient monitoring, as each patient requires personalized care and ongoing monitoring. Off-the-shelf solutions may not meet these diverse needs, leading to inefficiencies and gaps in care. It’s here, custom healthcare software offers a tailored solution, ensuring improved care and effectiveness.
Innovating Inference - Remote Triggering of Large Language Models on HPC Clus...Globus
Large Language Models (LLMs) are currently the center of attention in the tech world, particularly for their potential to advance research. In this presentation, we'll explore a straightforward and effective method for quickly initiating inference runs on supercomputers using the vLLM tool with Globus Compute, specifically on the Polaris system at ALCF. We'll begin by briefly discussing the popularity and applications of LLMs in various fields. Following this, we will introduce the vLLM tool, and explain how it integrates with Globus Compute to efficiently manage LLM operations on Polaris. Attendees will learn the practical aspects of setting up and remotely triggering LLMs from local machines, focusing on ease of use and efficiency. This talk is ideal for researchers and practitioners looking to leverage the power of LLMs in their work, offering a clear guide to harnessing supercomputing resources for quick and effective LLM inference.
Navigating the Metaverse: A Journey into Virtual Evolution"Donna Lenk
Join us for an exploration of the Metaverse's evolution, where innovation meets imagination. Discover new dimensions of virtual events, engage with thought-provoking discussions, and witness the transformative power of digital realms."
top nidhi software solution freedownloadvrstrong314
This presentation emphasizes the importance of data security and legal compliance for Nidhi companies in India. It highlights how online Nidhi software solutions, like Vector Nidhi Software, offer advanced features tailored to these needs. Key aspects include encryption, access controls, and audit trails to ensure data security. The software complies with regulatory guidelines from the MCA and RBI and adheres to Nidhi Rules, 2014. With customizable, user-friendly interfaces and real-time features, these Nidhi software solutions enhance efficiency, support growth, and provide exceptional member services. The presentation concludes with contact information for further inquiries.
Into the Box Keynote Day 2: Unveiling amazing updates and announcements for modern CFML developers! Get ready for exciting releases and updates on Ortus tools and products. Stay tuned for cutting-edge innovations designed to boost your productivity.
How Recreation Management Software Can Streamline Your Operations.pptxwottaspaceseo
Recreation management software streamlines operations by automating key tasks such as scheduling, registration, and payment processing, reducing manual workload and errors. It provides centralized management of facilities, classes, and events, ensuring efficient resource allocation and facility usage. The software offers user-friendly online portals for easy access to bookings and program information, enhancing customer experience. Real-time reporting and data analytics deliver insights into attendance and preferences, aiding in strategic decision-making. Additionally, effective communication tools keep participants and staff informed with timely updates. Overall, recreation management software enhances efficiency, improves service delivery, and boosts customer satisfaction.
Globus Connect Server Deep Dive - GlobusWorld 2024Globus
We explore the Globus Connect Server (GCS) architecture and experiment with advanced configuration options and use cases. This content is targeted at system administrators who are familiar with GCS and currently operate—or are planning to operate—broader deployments at their institution.
3. Who is using REST?
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
4. REST - REpresentational State Transfer
https://api.example.com/customers/123
DELETE
PUT
POST
GET
PATCH
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
10. Platform Architecture - How to define a good API?
Platform
App 1 App 2
Customer
App X...
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
13. GraphQL
● Graph Query Language
● Published by Facebook in 2015
● Growth from Facebook Graph API
● Reference implementation in JavaScript
● First version of Java Library: 18 Jul 2015
https://github.com/graphql-java/graphql-java
● First usage: 21 Sep 2015
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
14. GraphQL main concepts
● One endpoint for all operations
● Always define in request what you need
● Queries, Mutations and Subscriptions
● Defined by schema
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
15. Data is a graph
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
16. GraphQL time for demo
● Fragments
● Aliases
● Directives
● Interfaces
● Unions
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
● Query
● Syntax Error
● Mutation
● Operation name
● Variables
17. GraphQL Simple API
GET /customers/2?fields=id,name,email
type Customer {
#fields with ! are not null
id: ID!
name: String!
email: String!
}
type Query {
customer(id: String!): Customer!
}
{
"data": {
"customer": {
"id": "2",
"name": "name",
"email": "a@b.com"
}
}
}
{
customer(id: "2") {
id
name
email
}
}
RE
ST
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
18. GraphQL Bad Request
GET /custo!@#$ -> 404
{
"data": null,
"errors": [
{
"message": "Invalid Syntax",
"locations": [
{
"line": 2,
"column": 8
}
],
"errorType": "InvalidSyntax",
"path": null,
"extensions": null
} ] }
{
custo!@#$
}
RE
ST
http.cat/200
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
19. Go back to the roots
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
20. GraphQL Simple API
GET /customers/2?fields=id,name,email,company(id,name)
type Customer {
id: ID!
name: String!
email: String!
company: Company
}
type Company {
id: ID!
name: String!
website: String!
}
type Query {
customer(id: String!): Customer!
}
{
"data": {
"customer": {
"id": "2",
"name": "name",
"email": "a@b.com",
"company": {
"id": "211",
"name": "Company Corp."
}
}
}
}
{
customer(id: "2") {
id
name
email
company {
id
name
}
}
}
RE
ST
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
21. GraphQL Simple API
GET /customers/2?fields=id,name,email,orders(id,status)
type Customer {
id: ID!
name: String!
email: String!
company: Company
orders: [Order]
}
type Order {
id: ID!
status: Status
}
enum Status {
NEW, CANCELED, DONE
}
{
"data": {
"customer": {
"id": "2",
"name": "name",
"orders": [
{
"id": "55",
"status": "NEW"
},
{
"id": "66",
"status": "DONE"
}
] } } }
{
customer(id: "2") {
id
name
orders {
id
status
}
}
}
RE
ST
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
22. GraphQL Aliases
GET /customers/2?fields=id,name,email +
{
"data": {
"cust1": {
"id": "2",
"name": "name",
"email": "a@b.com"
},
"cust2": {
"id": "3",
"name": "John Doe",
"email": "john@doe.com"
}
}
}
query get2Cust {
cust1: customer(id: "2") {
id
name
email
}
cust2: customer(id: "3") {
id
name
email
}
}
RE
ST
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
GET /customers/3?fields=id,name,emailRE
ST
23. GraphQL Fragment
GET /customers/2?fields=id,name,email +
{
"data": {
"cust1": {
"id": "2",
"name": "name",
"email": "a@b.com"
},
"cust2": {
"id": "3",
"name": "John Doe",
"email": "john@doe.com"
}
}
}
query get2Cust {
cust1: customer(id: "2") {
... frag1
}
cust2: customer(id: "3") {
... frag1
}
}
fragment frag1 on Customer {
id
name
email
}
RE
ST
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
GET /customers/3?fields=id,name,emailRE
ST
24. GraphQL Arguments
GET /customers/2?fields=id,name,email +
{
"data": {
"cust1": {
"id": "2",
"name": "name",
"email": "a@b.com"
},
"cust2": {
"id": "3",
"name": "John Doe",
"email": "john@doe.com"
}
}
}
query get2Cust($arg1:String!, $arg2: String!) {
cust2: customer(id: $arg1) {
... frag1
}
cust3: customer(id: $arg2) {
... frag1
}
}
fragment frag1 on Customer {
id
name
email
}
RE
ST
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
GET /customers/3?fields=id,name,emailRE
ST
25. GraphQL Directive
GET /customers/2?fields=id,name
{
"data": {
"customer": {
"id": "2",
"name": "name"
}
}
}
query getCust ($showEmail: Boolean!) {
customer(id: "2") {
id
name
email @include(if: $showEmail)
}
}
{
"showEmail": false
}
RE
ST
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
26. GraphQL Interface
GET /users?fields=id,name,superAdmin,permissions
type Query {
users: [User]
}
interface User {
id: ID!
name: String!
email: String!
}
type Admin implements User {
superAdmin: Boolean! // + id...
}
type Moderator implements User {
permissions: [String] // + id...
}
{
"data": {
"users": [
{
"id": "777",
"name": "Admin a",
"superAdmin": true
},
{
"id": "888",
"name": "Moderator",
"permissions": [
"Delete Customer",
"Delete comment"
]}]}}
query getUsers {
users {
... on Admin {
id
name
superAdmin
}
... on Moderator {
id
name
permissions
}
}
}
RE
ST
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
27. GraphQL Union
GET /search?input=a?fields=typename,name
type Query {
search(input: String):
[SearchResult]
}
union SearchResult =
Customer |
Admin |
Moderator
{
"data": {
"search": [
{
"__typename": "Customer",
"name": "name"
},
{
"__typename": "Admin",
"name": "Admin a"
},
{
"__typename": "Moderator",
"name": "Moderator"
}]}}
query searchSmth {
search(input: "a") {
__typename
... on Customer {
name
}
... on Admin {
name
}
... on Moderator {
name
}
}
}
RE
ST
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
28. GraphQL mutations
input CreateCustomerInput {
name: String
email: String
clientMutationId: String!
}
type CreateCustomerPayload {
customer: Customer
clientMutationId: String!
}
type Mutation {
createCustomer(input: CreateCustomerInput):
CreateCustomerPayload!
}
{
"data": {
"createCustomer": {
"customer": {
"id": "40",
},
"clientMutationId":
"123"
}
}
}
POST /customers PUT /customers/123 DELETE /customers/123 PATCH /customers/123
mutation {
createCustomer(input: {
name: "MyName"
email: "me@me.com"
clientMutationId: "123"
}) {
customer {
id
}
clientMutationId
}
}
RE
ST
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
29. GraphQL mutations + operation name
mutation crCust {
createCustomer(input: {
name: "MyName"
email: "me@me.com"
clientMutationId: "123"
}) {
customer {
id
}
clientMutationId
}
}
{
"data": {
"createCustomer": {
"customer": {
"id": "40",
},
"clientMutationId":
"123"
}
}
}
POST /customers PUT /customers/123 DELETE /customers/123 PATCH /customers/123RE
ST
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
mutation {
createCustomer(input: {
name: "MyName"
email: "me@me.com"
clientMutationId: "123"
}) {
customer {
id
}
clientMutationId
}
}
30. GraphQL Variables
{
"data": {
"createCustomer": {
"customer": {
"id": "40",
},
"clientMutationId":
"123"
}
}
}
POST /customers PUT /customers/123 DELETE /customers/123 PATCH /customers/123
mutation crCust {
createCustomer(input: {
name: "MyName"
email: "me@me.com"
clientMutationId: "123"
}) {
customer {
id
}
clientMutationId
}
}
RE
ST
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
mutation crCust ($input: CreateCustInput) {
createCustomer(input: $input) {
customer {
id
}
clientMutationId
}
}
{
"input": {
"name": "MyName 2",
"email": "me2@me.com",
"clientMutationId": "123"
}
}
31. Lessons Learned #1
Never add a library to your project
few days after init release
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
● No community
● A lot of bugs
● Bad documentation
● Strict following reference
implementation and specification
DO NOT TRY
THIS AT WORK
32. GraphQL Java implementations
How to implement GraphQL in Java?
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
/graphql-java/graphql-java /leangen/graphql-spqr
Senātus Populusque Rōmānus
The Roman Senate and People
pronounced like speaker
33. GraphQL Simple API
GET /customers/2?fields=id,name,email,orders(id,status)
type Customer {
id: ID!
name: String!
email: String!
company: Company
orders: [Order]
}
type Order {
id: ID!
status: Status
}
enum Status {
NEW, CANCELED, DONE
}
{
"data": {
"customer": {
"id": "2",
"name": "name",
"orders": [
{
"id": "55",
"status": "NEW"
},
{
"id": "66",
"status": "DONE"
}
] } } }
{
customer(id: "2") {
id
name
orders {
id
status
}
}
}
RE
ST
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
34. How to implement DataFetcher for queries
GET /customers/2?fields=id,name,email,orders(id,status)
@Component
public class CustomerFetcher extends PropertyDataFetcher<Customer> {
@Autowired
private CustomerService customerService;
@Override
public Customer get(DataFetchingEnvironment environment) {
String id = environment.getArgument("id");
return customerService.getCustomerById(id);
}
}
RE
ST
{
customer(id: "2") {
id
name
orders {
id
status
}
}
}
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
35. How to implement DataFetcher for queries
GET /customers/2?fields=id,name,email,orders(id,status)
public class Customer {
private String id;
private String name;
private String email; // getters are not required
}
RE
ST
{
customer(id: "2") {
id
name
orders {
id
status
}
}
}
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
public class OrderDataFetcher extends PropertyDataFetcher<List<Order>> {
@Override
public List<Order> get(DataFetchingEnvironment environment) {
Customer source = environment.getSource();
String customerId = source.getId();
return orderService.getOrdersByCustomerId(customerId);
}
}
36. GraphQL mutations
input CreateCustomerInput {
name: String
email: String
clientMutationId: String!
}
type CreateCustomerPayload {
customer: Customer
clientMutationId: String!
}
type Mutation {
createCustomer(input: CreateCustomerInput):
CreateCustomerPayload!
}
{
"data": {
"createCustomer": {
"customer": {
"id": "40",
},
"clientMutationId":
"123"
}
}
}
POST /customers PUT /customers/123 DELETE /customers/123 PATCH /customers/123
mutation {
createCustomer(input: {
name: "MyName"
email: "me@me.com"
clientMutationId: "123"
}) {
customer {
id
}
clientMutationId
}
}
RE
ST
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
37. How to implement DataFetcher for mutations
POST /customers PUT /customers/123 DELETE /customers/123 PATCH /customers/123
@Component
public class CreateCustomersFetcher extends
PropertyDataFetcher<CreateCustomersPayload> {
@Override
public CreateCustomerPayload get(DataFetchingEnvironment env) {
Map<String, Object> input = env.getArgument("input");
String name = (String) input.get("name");
String email = (String) input.get("email");
String clientMutationId = (String) input.get("clientMutationId");
Customer customer = customerService.create(name, email);
return new CreateCustomerPayload(customer, clientMutationId);
}
RE
ST
mutation {
createCustomer(input: {
name: "MyName"
email: "me@me.com"
clientMutationId: "123"
}) {
customer {
id
}
clientMutationId
}
}
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
38. In case Interfaces and Unions - Type Resolver is needed
public class UserTypeResolver implements TypeResolver {
@Override
public GraphQLObjectType getType(TypeResolutionEnvironment env) {
Object javaObject = env.getObject();
if (javaObject instanceof Admin) {
return env.getSchema().getObjectType("Admin");
} else if (javaObject instanceof Moderator) {
return env.getSchema().getObjectType("Moderator");
} else {
throw new RuntimeException("Unknown type " + javaObject.getClass().getName());
}
}
}
public interface User {...}
public class Admin implements User {...}
public class Moderator implements User {...}
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
39. Glue everything together
RuntimeWiring runtimeWiring = RuntimeWiring.newRuntimeWiring()
.type("Query", builder ->
builder.dataFetcher("customer", customerFetcher))
.type("Mutation", builder ->
builder.dataFetcher("createCustomer", createCustomerFetcher))
.type(newTypeWiring("User")
.typeResolver(new UserTypeResolver())
.build())
...
.build();
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
40. GraphQL type system
How to define your schema?
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
41. Code First approach
private GraphQLFieldDefinition customerDefinition() {
return GraphQLFieldDefinition.newFieldDefinition()
.name("customer")
.argument(GraphQLArgument.newArgument()
.name("id")
.type(new GraphQLNonNull(GraphQLString)))
.type(new GraphQLNonNull(GraphQLObjectType.newObject()
.name("Customer")
.field(GraphQLFieldDefinition.newFieldDefinition()
.name("id")
.description("fields with ! are not null")
.type(new GraphQLNonNull(GraphQLID))
.build())
….
.build()))
.dataFetcher(customerFetcher)
.build();
}
Schema First approach
type Query {
customer(id: String!): Customer!
}
type Customer {
#fields with ! are not null
id: ID!
name: String!
email: String!
company: Company
orders: [Order]
}
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
42. Schema First approach
type Customer {
# fields with ! are required
id: ID!
name: String!
email: String!
company: Company
orders: [Order]
}
*.graphqls
SchemaParser schemaParser = new SchemaParser();
File file = // ...
TypeDefinitionRegistry registry = schemaParser.parse(file);
SchemaGenerator schemaGenerator = new SchemaGenerator();
RuntimeWiring runtimeWiring = RuntimeWiring.newRuntimeWiring()
.type("Query", builder ->
builder.dataFetcher("customer", customerFetcher))
// ...
.build();
return schemaGenerator.makeExecutableSchema(registry, runtimeWiring);
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
44. SPQR approach
public class UserService {
@GraphQLQuery(name = "user")
public User getById(@GraphQLArgument(name = "id") Integer id) {
//...
}
}
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
public class User {
//...
@GraphQLQuery(name = "name", description = "A person's name")
public String getName() {
return name;
}
}
By default argument names will be arg0, arg1,...
You can use @GraphQLArgument or
Compile code with -parameters option
45. SPQR approach - Smart conventions
@GraphQLType(name = "Item")
public class SpqrItem {
private String id;
private int amount;
// ...
@GraphQLId
@GraphQLNonNull
@GraphQLQuery(name = "id", description = "Item id")
public String getId() {
return id;
}
public int getAmount() {
return amount;
}
}
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
// 'ID' type in schema, add 'implements Node'
// add ! (non null) in schema
// optional
// add ! (non null) because it’s int
46. Classic Code First Approach
Pros:
● Stable library
● Some Javadoc and
documentation
● It was the only way at the
beginning to define a schema
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
Cons:
● Hard to maintain
● Missing big picture
● Backend part needs to be
implemented first
● One DataFetcher for one
operation
● No possibility to mix with
Schema First
● No easy way to migrate to
Schema First or SPQR
47. Schema First Approach
Pros:
● Easy to maintain
● Stable library
● Some Javadoc and
documentation
● Easy DSL to understand and
maintain
● Reduce boilerplate to write
● A possibility to split schema into
more files
● Parallel development (frontend &
backend)
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
Cons:
● Possible mismatch between
types in schema file and Java
code
● Binding between operations
defined in schema and
DataFetcher's is needed
● One DataFetcher for one
operation
48. SPQR Approach
Pros:
● The author reply to Github issues
quickly
● Reduce boilerplate to write
● No mismatch between Schema
and Java code
● No binding between schema and
DataFetchers is needed
● Smart conventions
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
Cons:
● Production ready?
● Zero Javadoc or other
documentation
● Missing big picture
● Backend part needs to be
implemented first
● Ugly names for generics:
MutationPayload<User> =>
MutationPayload_User
● Hard to change smart
conventions
49. Lessons Learned #2
Classic Code First Approach is the worst
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
● Big project
● High risk project
● Old project
● Small project
● Low risk project
● New Project
?
50. From Code First to Schema First migration
https://github.com/mstachniuk/graphql-schema-from-introspection-generator
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
51. From Code First to Schema First migration alternatives
● In graphql-java - see: IntrospectionResultToSchema
● In graphql-js:
const graphql = require("graphql");
const schema = require("path/to/schema.json");
const clientSchema = graphql.buildClientSchema(schema.data);
const schemaString = graphql.printSchema(clientSchema);
console.log(schemaString)
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
52. GraphQL - How to define pagination, filtering, sorting?
Pagination:
● before, after
● offset, limit
Filtering:
● filter(name: “Bob” email: “%@gmail.com”)
● filter: {
OR: [{
email: “%@gmail.com”
}]
}, name: “Bob”
}
Sorting:
● orderBy: ASC, DESC
● sort: NEWEST, IMPORTANCE
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
53. Lessons Learned #3
GraphQL is not full query language
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
● Flexibility
● Less common conventions
● Dgraph.io created GraphQL+-
54. Complex Queries
fragment Friends on Friend {
id
name
friends {
id
name
friends {
id
name
...
}
}
}
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
graphQL = GraphQL.newGraphQL(schema)
.instrumentation(
new ChainedInstrumentation(asList(
new MaxQueryComplexityInstrumentation(20),
new MaxQueryDepthInstrumentation(2)
)))
.build();
55. Lessons Learned #4
Performance killer?
Define instrumentation!
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
56. Lessons Learned #5
Thinking shift is a key
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
● Let’s think in graphs and NOT in
endpoints / resources / entities / DTOs
● Bad design of our API
57. Versioning
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
GraphQL takes a strong opinion on avoiding
versioning by providing the tools for the
continuous evolution of a GraphQL schema.
Src: https://graphql.org/learn/best-practices/#versioning
58. Versioning
type Query {
customer(id: String!): Customer! @deprecated(reason: "not used ...")
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
59. Lessons Learned #6
Versioning is not a problem
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
GET /v2/customers/111RE
ST
GET /customers/111?v=v2RE
ST
GET /customers/111 Accept header: application/vnd.myapp.2+jsonRE
ST
GET /customers/111 Custom header: x-ms-version:2RE
ST
Versioning problem is different
62. Tools Relay
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned @MarcinStachniukGraphQL - when REST API is not enough - lessons learned
user(...) {
photo(width: "120", height: "120")
}
user(...) {
name
}
user(...) {
email
}
user(...) {
name
email
photo(width: "120", height: "120")
}
65. More libraries and projects related to graphql-java
https://github.com/graphql-java/awesome-graphql-java
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
● JPA Implementation of GraphQL (builds on graphql-java)
● And more examples
66. Apollo
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
Build a universal GraphQL API on top of your existing REST
APIs, so you can ship new application features fast without
waiting on backend changes.
67. Prisma.io
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
Building a GraphQL server with Prisma
● Solves N+1 Problem with built-in dataloader
● No boilerplate for CRUD, filters, pagination & more
● Easily implement GraphQL subscriptions
68. Lessons Learned #7
Tooling is nice
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
now
69. Good practices
● Always generate GraphQL Schema and commit into your repository
● Validate your schema
● Do not use classic code first approach to define schema
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
70. Summary
GraphQL Pros:
● Nice alternative to REST
● It can be used together with REST
● Good integration with Relay / ReactJS
● You get exactly what you want to get
● Good for API with different clients
● Good to use on top of existing API
● Self documented
● Easy testing
● Nice tooling
● Thin layer
GraphQL Cons:
● High entry barrier
● Hard to return simple Map
● Not well know (yet)
● Performance overhead
● A lot of similar code to write
● No Operation Idempotency
● No Cache & Security
● No Authorisation
● Always HTTP 200 -
unsupported tools
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned
71. Nothing is a silver bullet
@MarcinStachniukGraphQL - when REST API is not enough - lessons learned