Hi @leifriksheim and @ldwm! So yes, interesting discussion this one as always, with @tats_sato we wrote this article detailing a little bit of the why of this approach: https://holochain-open-dev.github.io/blog/graphql-holochain/.
So, in here, the two “release scenarios” that (will) exist in hololand are very different from each other:
On holochain, you are running the node on your local machine. This means that network requests to your localhost are almost instantaneous. I don’t think that it’s worth it to do graphql request to a hosted server and then back to your own machine in this scenario, since you could directly call yourself. This is the only scenario available to us right now through holoscape.
On holo, we are going to call a hosted holochain application on a holoport. In this case, we do have to request a process running on an external machine, so reducing the number of calls would have at least a partial improvement on the performance. I think though that the main scenario that holo is going to support through frontend libraries (see here is having the UI call directly call holo’s infrastructure, so I don’t know how much flexibility we are going to have here… Also, “proxying” the request through a Node.js server seems to me to solve the JS bundle size issue, but not the “reduce network requests” issue, and adding a possible centralized point susceptible to attacks… I think when holo launches with all details and infrastructure we’ll see what’s possible and what isn’t, maybe the best strategy would be a zome with Jupiter compiled with resolvers to your particular happ, but we have to see what real impact these are going to have in the performance.
Also note that on both cases, the majority of network requests will be done by the holochain nodes pinging and hopping with each other to navigate the DHT, not from the UI to the holochain node. So, yes we could reduce the number of requests from the UI to the node, but this would only partially speed up the process.
I don’t follow exactly: couldn’t you reuse all graphql middleware in all frontend frameworks? The ApolloClient stack for example is pretty much framework agnostic: although it offers different adapters/APIs to call from the components, the “middleware” layer stays pretty much the same, no? Am I missing something?
So, at least this is what I’m thinking/how I frame the problem, maybe we are missing something to fix all of our issues… Let me know if you have some ideas around this