won't the application be blocked for first call to get list of N objects to then make batch call ? what if the first call is returning flux of objects.
But if you use such batch mapping you end with large list of IDs inside the SQL IN query. Isn't that bad for performance? Also database systems have limits on the number of parameters that can be passed to the IN query.
you don't have to do things this way. you don't have to use SQL, for a start. You could use any database technology. I mean, use whatever means you want. Surely having the context required to get everything in one request is better than N requests? If not, then you can always just do the N+1 thing.
If one see problems with the specific database server and how you configure it. One can use something that scales better than SQL for that problem or use a distributed SQL or any other database or storage solution. The point here is what @BatchMapping offers to the developers, the option to group the datafetching interactions and requests when it makes sense to do so.
That's not a problem that's especially unique to GraphQL, and there are many workarounds. There's an obvious middle ground between running a query 100 times, and running it once with 100 parameters to the IN clause... you run it 10 times with 10 parameters, if that ends up being more efficient. Or you dump all the keys into a temp table and join on that. Or any of the other tricks that developers have used for decades to make SQL databases work for them.
won't the application be blocked for first call to get list of N objects to then make batch call ? what if the first call is returning flux of objects.
But if you use such batch mapping you end with large list of IDs inside the SQL IN query. Isn't that bad for performance? Also database systems have limits on the number of parameters that can be passed to the IN query.
you don't have to do things this way. you don't have to use SQL, for a start. You could use any database technology. I mean, use whatever means you want. Surely having the context required to get everything in one request is better than N requests? If not, then you can always just do the N+1 thing.
If one see problems with the specific database server and how you configure it. One can use something that scales better than SQL for that problem or use a distributed SQL or any other database or storage solution. The point here is what @BatchMapping offers to the developers, the option to group the datafetching interactions and requests when it makes sense to do so.
That's not a problem that's especially unique to GraphQL, and there are many workarounds. There's an obvious middle ground between running a query 100 times, and running it once with 100 parameters to the IN clause... you run it 10 times with 10 parameters, if that ends up being more efficient. Or you dump all the keys into a temp table and join on that. Or any of the other tricks that developers have used for decades to make SQL databases work for them.
I think you should consider pagination in this case to limit number of objects to be retrieved at once
What about caching?
Great content, but the sound quality is horrible. Get at least a cheap lavalier microphone.
Could be that Josh is doing this last 3 videos not from his main home, he has a much better setup when Josh streams in twitch