Fork me on GitHub

@valtteri @rgb.ide It may be worth noting than a GraphQL-style API is usually more general than a REST - by which I mean that if you have set up a GraphQL-style engine, building a REST API on top of that is fairly easy: you could have each REST point be implemented with a constant GraphQL(-ish) query, and links between entities can be expressed via an :entity/href attribute


in other words, you could view GraphQL and the like as a programming language for implementing REST APIs


Of course, you may want to choose a server-side library that is simpler and more programmable than GraphQL, and that's where I bring my shameless plug:

👍 4

Any plans to a frontend lib to create/compose queries


@U2J4FRT2T not sure I understand the question, what are you missing currently?


(AFAICT you can already create / compose queries, they're just data)

👍 4
Andrea Imparato15:11:23

I prefer way more rest than graphql, graphql loses all the HTTP semantic power and I don't really like it


I really like the ability to select which fields you want, and to have subscriptions. You can have your custom update with just the information you want to see.

Lennart Buit17:11:30

also, I really like that GraphQL has a single format. REST can grow wild in which every endpoint returns slightly different data

Lennart Buit17:11:28

that is ofcourse also behaving yourself, but that turns out to be harder than it seems


Also HTTP return codes are nice, but often not well implemented in REST

Lennart Buit18:11:18

also, I think GraphQL is agnostic of transport layer

Lennart Buit18:11:31

so you could talk GraphQL over homing pidgeons

😂 4

Rest encourages you to implement them. Yada does a lot of work to make sure the right status code is generated.


graphql is a formatting standard, where a “squint your eyes” summary would be “what if you had SQL but in JSON” 🙂


Then, if you squint really hard, you get cross eyed:


I like SQL as a language and prefer it over wrappers like ORMs


That said, the difference between GraphQL and SQL is that GraphQL is literally formatting: which is why you can’t optimise the query in the same way as you can with SQL and relational algebra


This is good because it allows to decouple data formatting from storage and query performance


But I love that someone went “actually you know what, we’ve had something that worked for ages already” :D


I'm trying to find some benchmarks relating to execution speeds of graalvm vs openjdk. Not native image. Anyone have some convenient links? Particularly as it relates to Clojure

Andrea Imparato22:11:44

I think does a very good job with creating a good standard for how to write rest apis


My favourite feature of GraphQL is that clients have to explicitly request fields that they want


Where I work, our GraphQL endpoint is not publicly exposed, so we always know which fields are in use, and which are not


This means we can statically determine if a change to the schema is going to break things on the client


I think the issue with REST (and thus the value prop of GraphQL) is that you force clients to consume way more than they need from an API endpoint, or you force clients to make multiple network calls to gather all the information they need

💯 12

and practically, nobody consuming your API is going to care beyond “did I get a 200”