This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-04-26
Channels
- # beginners (20)
- # cider (59)
- # cljsrn (6)
- # clojars (7)
- # clojure (91)
- # clojure-boston (1)
- # clojure-dusseldorf (3)
- # clojure-finland (1)
- # clojure-italy (8)
- # clojure-losangeles (1)
- # clojure-nl (16)
- # clojure-spec (25)
- # clojure-uk (113)
- # clojurescript (126)
- # core-async (27)
- # cursive (5)
- # data-science (3)
- # datomic (22)
- # emacs (24)
- # fulcro (30)
- # garden (7)
- # graphql (7)
- # leiningen (3)
- # nginx (1)
- # off-topic (63)
- # onyx (13)
- # portkey (1)
- # re-frame (1)
- # reagent (28)
- # shadow-cljs (92)
- # tools-deps (1)
- # uncomplicate (1)
- # vim (24)
- # yada (8)
Hi, wanted to share this paper that found very interesting https://dl.acm.org/citation.cfm?doid=3178876.3186014
Not certain that I care that " This implies that a server can answer a GraphQL query and send the response byte-by-byte while spending just a constant amount of time between every byte sent." As I read it, they seem to be assuming that the entire GraphQL data structure is fully realized in memory before streaming the response, which is anything but the case!
Maybe I'll read it in more detail later. The interesting/hard part of GraphQL and Lacinia is the async construction of the response data NOT the streaming of that data, as JSON, to the client.