# prisma-whats-new
- s
sashko
10/22/2016, 6:00 AMbatching multiple requests together actually makes the initial load slower, not faster - s
sashko
10/22/2016, 6:01 AMsince you have to wait for the server to have all of the data before you get anything back - s
sashko
10/22/2016, 6:01 AMthe main case where you want to reduce roundtrips is when you have data that depends on a previous result - s
sashko
10/22/2016, 6:01 AM``` - s
sashko
10/22/2016, 6:01 AMso for example: - s
sashko
10/22/2016, 6:01 AMdang it, slack settings - s
sashko
10/22/2016, 6:01 AManyway, it's bad to fetch A and then use result from A to fetch B, since you have to wait two whole roundtrips - s
sashko
10/22/2016, 6:02 AMbut just sending A and B in parallel is fine, I think merging those into one query doesn't actually help that much - m
Matt Mueller (Prisma Client PM)
10/22/2016, 6:02 AMhmm, yah you might be right about that, in my case A and B both need to be present before i send anything - m
Matt Mueller (Prisma Client PM)
10/22/2016, 6:03 AMthough they are independent - m
Matt Mueller (Prisma Client PM)
10/22/2016, 6:03 AMthe other benefit of a single request is dataloader caching - s
sashko
10/22/2016, 6:03 AMyeah, but with a BaaS it's not really a thing I guess? - m
Matt Mueller (Prisma Client PM)
10/22/2016, 6:03 AMbut i think that's secondary since it would probably not conflict too much - s
sashko
10/22/2016, 6:03 AMunless Graphcool charges per db query - s
sashko
10/22/2016, 6:03 AMI agree it could be a big deal if you were running your own server and wanted to take advantage of server-side caching more - s
sashko
10/22/2016, 6:04 AMthat's one good reason to send as many queries as possible in one request - s
sashko
10/22/2016, 6:04 AMI think the main impact would be a reduction in server load though, not necessarily a faster response in the UI - s
sashko
10/22/2016, 6:05 AM(this is just from our recent experiences using batching in production, it's not always something you need, and sometimes it actually makes things slower) - s
sashko
10/22/2016, 6:05 AManyway, I guess I'm saying my advice would be to not worry too much about running several queries in parallel, but avoid roundtrips to fetch dependent data - m
Matt Mueller (Prisma Client PM)
10/22/2016, 6:06 AMhmm, okay that's really good to know, that certainly simplifies things even more - m
Matt Mueller (Prisma Client PM)
10/22/2016, 6:06 AMi'd still like to have the option though for when there are query dependencies and when i can take advantage of dataloader - m
Matt Mueller (Prisma Client PM)
10/22/2016, 6:07 AMi was talking to @schickling and it seems like they do use a dataloader equivalent on the backend - s
sashko
10/22/2016, 6:07 AMfair - s
sashko
10/22/2016, 6:07 AMyeah, so query merging gets you pretty far, but it can get buggy when the query is very complex - s
sashko
10/22/2016, 6:08 AMI'd suggest it would make sense for graphcool to implement transport batching on the server - s
sashko
10/22/2016, 6:08 AMbasically the ability to send an array of GraphQL documents in one request - s
sashko
10/22/2016, 6:08 AMfor dependent data, I think you pretty much need to manually combine fragments if you want that to happen in one request - s
sashko
10/22/2016, 6:09 AMwe've been working on some cool fragment utilities for apollo: https://github.com/apollostack/GitHunt-React/pull/112/files - m
Matt Mueller (Prisma Client PM)
10/22/2016, 6:12 AMoh interesting, yah i still have to give fragments a try, i've been a bit skeptical of them because it seems like if you define components by fragments they are no longer independent - m
Matt Mueller (Prisma Client PM)
10/22/2016, 6:12 AMlike they'll need some sort of top-level query to make them work.