Apollo-server: SQL Generation and Optimization

[idibidiart]

(@marcfawzi here)

Hey guys,

I've been looking at both Join Monster and the Sangria GraphQL server. I like the dynamic SQL generation in Join Monster and its many advantages including its focus on performance. I also like the lazy evaluation for nested/recursive queries in Sangria, so we don't have to adopt awkward defensive measures like here (https://medium.com/@mattmazzola/graphql-controlling-the-depth-of-recursive-relationships-a5ff63dee0de#.uk66i9j7n)

Being new to the whole GraphQL thing, could you please enlighten on whether or not these features are generally valuable and whether or not they will make it in Apollo one day?

Thanks.

[smolinari]

AFAIK, the general thinking with Apollo server is to support just a light standard GraphQL API up front with certain tools and not deal directly with any business or persistence logic below it. All that logic is up to the client dev using Apollo. I personally think it is the right thing to do too. There are just too many scenarios to cover to be able to come up with such mechanisms, and at the same time, make a lot of users happy. You could say Apollo Server is the start for solutions like Sangria and Join Monster.

What I'd like to know is, couldn't there be a clearly designed plug-in interface within Apollo Server, which would help integrate more specific solutions for business and persistence logic into the server and also create a springboard for their creation, instead of people making their own specialized GraphQL server solutions? I know there is the "options object as a function" feature, but is that really enough?

Edit: This is a perfect example of what I mean. https://github.com/apollostack/graphql-server/issues/267

Imagine they create a plug-in for Apollo, which allows any other dev to use their nice new RabbitMQ interface and help them improve it too. We'd be talking about a cool Apollo Server ecosystem.

Scott

[idibidiart]

It's not a question as much as it is a suggestion for enhancement. Any comments?

[idibidiart]

I mean regarding the plugin idea from above?

[DxCx]

well apollo server (At least for now) is more into integrations (Transport) then how to implement your scheme.
graphql-tools tries to simplify the scheme part.
however, most of the addons are coming as external packages, and i suggest you to do the same =)
but before you do, i suggest you to look at this
https://www.youtube.com/watch?v=OQTnXNCDywA
which might be relevant for your plugin =)

[idibidiart]

Join Monster is actually different than DataLoader

"Why Not Use Data Loader?

DataLoader is Facebook's own solution for batch requests. It also caches individual entities. It's a simple and general tool for data fetching.

Join Monster is able to specialize for SQL, so you can avoid manually writing the queries (more configuring less programming). Data loader only batches requests for one resource, e.g. batching requests for users, or posts, etc. Join Monster can batch everything into one trip.

DataLoader derives its performance benefit from caching. Caching opens a can of worms. You have to think about cache invalidation, memory pressure, loading the cache, etc. For us, the batching was such a win that our performance issues were solved. The cache is complexity that we didn't need. This means less developer labor and cognitive burden."

That's one thing.

The other thing is:

The 'plugin' idea is not mine. It was suggested by @smolinari

=) x 2

[DxCx]

:)

yeah i know they are different, but i think that anyone who tries to do such tasks needs to watch this code-trough with lee since it gives alot value for developing similar solutions.. :)

[idibidiart]

Not in plugin development land just yet... :) Just asking if the plugin idea is under consideration by Apollo team or not. You're saying the current thinking is to use external packages, which sounds good to me!