Fork me on GitHub
#off-topic
<
2017-05-20
>
kzeidler00:05:16

@wunsch that sounds rad. Always wished more terminal utilities used repl interfaces instead of command-line flags

john03:05:25

@noisesmith what's the jazz with graphql? Haven't looked at it yet. Is that a general graph solution?

noisesmith03:05:54

it's not even a graph solution, it's a query language for getting data to web clients more efficiently

john03:05:16

yeah, the use cases didn't sound very graph-y to me

noisesmith03:05:29

I am not sure if it even supports proper graphs of data to query - it might only do trees (but I don't know that for sure)

noisesmith03:05:11

we have looked at graphql as a way to get better request throughput - basically treating it as a way for clients to opt out of some of the data we generate

noisesmith03:05:31

which can mean we do less work per request, which, hey, no reason to turn that down 😄

john03:05:41

where are you at?

john03:05:14

which company?

akiroz03:05:43

graphql has nothing to do with graphs 😂

dominicm06:05:48

https://coreos.com/blog/introducing-zetcd is etcd better than zk? I can see maybe for ease of deploy?

jimmy06:05:34

Dose anyone feel like these examples insane ? https://hnpwa.com/ The react app is poorly optimised, it has server rendering and the it re renders one more time later ?

dvingo16:05:55

very interesting stuff

val_waeselynck20:05:52

@john Graphql is also a good way to avoid breaking your APIs - since you can add new attributes without worrying about payload size instead of changing existing attributes

val_waeselynck20:05:43

It's really not just about performance, it's about allowing clients and APIs to evolve with less coordination and breakage