@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: https://github.com/vvvvalvalval/d2q

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.

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

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

also, I think GraphQL is agnostic of transport layer

so you could talk GraphQL over homing pidgeons

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” 🙂

http://bit.ly/expulative

Then, if you squint really hard, you get cross eyed: https://simonwillison.net/2018/Oct/4/datasette-ideas/

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

I think https://jsonapi.org/ 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

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