I didnt expect GraphQL to make my life so much eas...

# chicago

[bjonnh]

I didnt expect GraphQL to make my life so much easier

[Dariusz Kuc]

Indeed front end development experience is so much better than with traditional rest apis

[bjonnh]

I didn't do front end really yet

[bjonnh]

Just played with hasura in front of my postgres DB

[bjonnh]

I'll put javafx in front

[Dariusz Kuc]

well hasura is just wrapping up your DB

[Dariusz Kuc]

with GraphQL you could have single endpoint to integrate with (vs many rest apis)

[Dariusz Kuc]

your data models are exactly what you ask for and also automatically generated based on your queries

[Dariusz Kuc]

and you got type safety out of the box

[Dariusz Kuc]

all our mobile devs and web app devs love it

[bjonnh]

Yeah I really want to dig that more

[rharter]

I’ve always shied away from GraphQL because my interpretation has been that it basically moves the burden from the backend to the front-end, and all of that complexity from one system in back to all systems in front, just like Firebase db/firestore apis. (app on multiple platforms? hope they all access and update the data the same way!) . There may be one endpoint to access, but you lose a structured API and assurance that your business logic behind the scenes is happening consistently. Am I wrong, there?

[Dariusz Kuc]

If you are doing it this way then yes it is completely wrong

[Dariusz Kuc]

GraphQL was created to address the needs of the mobile clients and actually can help your front end apps simpler

[Dariusz Kuc]

IMHO GraphQL works best as an "experience API" layer that is above your domain layer and is custom tailored to provide various app experiences

[Dariusz Kuc]

with BFF model you have highly optimized service for single app

[Dariusz Kuc]

GraphQL takes this further by providing highly optimized schema for all your apps

[Dariusz Kuc]

*also GraphQL is not only strongly typed but relies on a schema that explicitly defines what data is available and what operations can be performed

[Dariusz Kuc]

btw this is a pretty good talk that shows how Airbnb is migrating to use GraphQL

https://www.youtube.com/watch?v=pywcFELoU8E&list=PLpi1lPB6opQyraZSmwFre_FpL00_3nTzV&index=4▾

[rharter]

Does it have something like a “service def”? For instance, when a user creates a new profile in a hypothetical social app they need to have their image uploaded to a storage service, a profile created in the profiles table, default followers added, etc. Does all of that now happen client side, where each app implementation and version needs to implement those identically, or is there a service class that gets generated or something to take care of all of those intricacies? With a rest API, I can send a request with the data and the server is a single actor to handle all of those intertwined dependencies.

[Dariusz Kuc]

it still should be managed server side, your exposed GraphQL mutation would be processing the same thing as your old REST API (or even simply just invoke it)

[rharter]

Firebase RTDB and Firestore had this promise of client side access to the data, which sounded awesome since we didn’t need a server team, or to wait for a server team, but through experience has all of these issues with distributing these responsibility. GraphQL has sounded the same to me, exposing the data instead of structured API and responses, so that client devs don’t have to wait on server devs, but also distributing that complexity.

[Dariusz Kuc]

key difference here is that Firebase/Firestore are databases

[Dariusz Kuc]

GraphQL does not tie itself to any database or storage

[Dariusz Kuc]

it is a specification that basically tells how to expose to expose your data

[Dariusz Kuc]

it is up to the devs to decide where to get the data from and how to get it (quite often people just wrap their existing rest apis in graphql layer OR expose their DB through it)

[Dariusz Kuc]

when you say "structured API" -> GraphQL is tied to a schema so all queries are structured

[Dariusz Kuc]

and the contract is actually stronger than with REST API

[rharter]

I think it’s clear that I haven’t learned enough to understand it, so don’t want to waste your time 🙂 I was under the impression that, while it’s behind a schema, the developer accessing it still has to (gets to?) understand the structure and build queries against it. My mental model sort of lumps GraphQL with SQL (not in backend storage, but how you interact with it), and REST APIs as more of a Java/Kotlin public interface for a library. With the former you need to have internal knowledge of the internal structure to know how to build a query to assemble the information you need (i.e. build a query that gets all the disparate data that makes up a user’s profile), but with the latter you simply make a request, similar to calling an API function, and get the complete data, without needing to know how it’s arranged on the backend.

[rharter]

Not saying either is better or worse, or right or wrong, just sharing why I’ve shied away and trying to learn more. Thanks for sharing the video, I’ll check that out, as I’d like to understand it a bit more 🙂

[Dariusz Kuc]

I was under the impression that, while it’s behind a schema, the developer accessing it still has to (gets to?) understand the structure and build queries against it

yes clients have to create their queries but the tooling in place makes it a trivial experience - using something like https://github.com/prisma-labs/graphql-playground you got visual access to the schema that you can traverse (aka "swagger on steroids") and from the editor you got autocomplete etc

[Dariusz Kuc]

as for the individual query vs complete REST response

[Dariusz Kuc]

yes end users have to build their queries but they only get the data they ask for, in REST it is all or nothing so while you can have highly optimized service (i.e. BFF) if clients don't care about 99% of the response you are overfetching the data

similarly with REST APIs you work with the concept of resource so often you might have to call multiple endpoints to get all the data you need, with GraphQL you can select multiple queries in single request

also once you write your queries you generate your client data model directly from it (which is null aware) so you got custom tailored models in each app

[Dariusz Kuc]

as for the video - it shows how Airbnb is approaching their migration but I think there are better intro videos (e.g. from my colleague

https://www.youtube.com/watch?v=IkPMpzQ-TRI▾

)

[rharter]

Awesome, thanks!

[bjonnh]

nice.

[bjonnh]

I would still like a JVM side GraphQL client that works…

[bjonnh]

So I could have my client GUI JavaFX app talk to the graphql server

[Dariusz Kuc]

Working on one :)

[Dariusz Kuc]

In the meantime apollo-android is the most popular one

[bjonnh]

does that work on non android JVM?

[Dariusz Kuc]

Yeah its for jvm

[Dariusz Kuc]

Its called android but its generic client

[Dariusz Kuc]

It was created by apollo but since then it is managed by community

[Dariusz Kuc]

Maybe they should consider renaming it :)