https://www.prisma.io/ logo
Join Slack
Powered by
# prisma-whats-new
  • n
    but I don't see how this does any harm?
  • n
    in the issue, you talk of mutations and race conditions. mutations are indeed executed sequential to prevent race conditions. see http://graphql.org/learn/queries/#multiple-fields-in-mutations
  • s
    Also worth noting is the @export feature described in the Batch section of https://medium.com/apollo-stack/new-features-in-graphql-batch-defer-stream-live-and-subscribe-7585d0c28b07#.tjykbn58o . If implemented this will allow you to specify dependencies between queries and/or mutations.
  • s
    But in short it seems what you want to do is already possible 😄
  • m
    ohh neat
  • m
    is this somethign that's possible in graph.cool right now?
  • m
    @nilan that wouldn't quite work unless i have some sort of query combiner
  • m
    it's not a huge deal, i'm just making like 1-3 requests to fetch data right now, but it would make a lot more sense to do it in 1
  • n
    do you mean it adds additional complexity in your app or do you mean the query itself does not execute correctly? Apollo and Relay both combine queries to reduce the amount of fetches.
  • n
    the query I wrote above is functional with graphcool, of course you have to provide the variables first
  • m
    @nilan so i think apollo does the batching on the server, but it looks like they're also trying to combine client-side queries here: https://github.com/apollostack/query-merging
  • m
    the reason i'd like it to execute these queries separately on the server is that it's not trivial to combine two queries on the client (or in general) it seems
  • m
    my tree looks like this: 
    <App><Page1>page 1</Page1><Page2>page 2</Page2></App>
  • m
    i'd like to be able to define specific queries on the App (load a logged in user), and respective Pages (load certain page data).
  • m
    send all those queries to the server, and have the server resolve it and send it back down
  • m
    then store it in redux (or equivalent) under whatever alias or query i've defined
  • m
    then i'd cache the queries, so they aren't performed again, making the assumption that all state changes will be done on the client from there on out (which is fine for non-realtime apps)
  • m
    basically it seems like a cheap way to get the big wins from relay. it's much less precise in terms of what exactly you're requesting (ie. if App and Page both request the name field of a user) and what you're caching (it caches on whole queries not on keys), but it's also conceptually way easier (like 30 LOC)
  • m
    cc/ @sashko please let me know if i'm making any serious flaws in my assumptions here 🙂
  • s
    (1) Apollo has query merging, which can be activated just by passing a 
    shouldBatch: true
    flag to the client, which mangles the queries to send everything in one request. This is somewhat complicated so we aren't going to recommend it in the future (which is why we are moving it into a separate package)
  • s
    (2) both Apollo and Relay let you use fragments to assemble a lot of different data requirements using GraphQL fragments, so you can send a query which, in one request, fetches all of the data you need at once
  • s
    (3) Apollo and Relay support transport batching, which means if your server has special support for sending multiple query documents in one request, the client will do that for you
  • s
    however, there's a real question here: what benefit are you actually looking to get from sending multiple queries in one request?
  • m
    @sashko thanks for the response! actually i need to look into (2) because I might be able to pull off what i'm trying to do by concatenating fragments
  • s
    I guess I'm curious why it matters how many requests are done
  • s
    I agree it's bad to do multiple roundtrips, where fragments can be useful
  • s
    but I'm wondering what your specific use case is, and what you're trying to achieve
  • m
    so right now to load my app, like just to show a page, it requires 2 requests, possibly more in the future depending on how complex my tree gets
  • s
    right, so here's my question: how would your app become better if it was one request instead?
  • m
    ideally it would load faster
1...313233...637Latest