Fork me on GitHub
#off-topic
<
2018-11-07
>
val_waeselynck14:11:14

@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

val_waeselynck15:11:40

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

val_waeselynck15:11:47

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

👍 4
souenzzo15:11:08

Any plans to a frontend lib to create/compose queries

val_waeselynck16:11:39

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

val_waeselynck16:11:26

(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

gklijs17:11:43

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

gklijs18:11:58

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
dominicm18:11:45

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

3Jane18:11:28

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

12
slipset21:11:24

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

3Jane22:11:10

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

3Jane22:11:49

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

3Jane22:11:29

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

3Jane22:11:12

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

dominicm21:11:56

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 https://jsonapi.org/ does a very good job with creating a good standard for how to write rest apis

yen23:11:32

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

yen23:11:16

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

yen23:11:40

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

csm23:11:22

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
csm23:11:13

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