Absinthe: Usage without Ecto

[fbjork]

Is there any documentation on using Absinthe without Ecto, but instead to talk to micro services directly?

[benwilson512]

Hey there!

Depends on what you mean by documentation. The Absinthe hexdocs don't really deal with Ecto at all. As far as guides go however I don't know of any off hand. One challenge with writing such guides is that how you write your resolvers will depend pretty significantly on how your microservice works. Ecto provides an easy example that is commonly understood.

That said of course, nothing about Absinthe or GraphQL is in any way tied to using relational database directly. You'd simply have resolution functions and in them call your microservices. Is there some specific question you have about how to do this?

[fbjork]

An example or guide of how to structure the code when resolving to REST APIs instead of Ecto would be very helpful. Things like caching, batching and parallel requests come to mind.

[johannesE]

@fbjork So to understand this correctly, you (and others) want a guide on how to use an rest API behind a graphql API? I think I did not quite understand the use case for this. Can't you call the other API from the client directly to avoid sending the data over the net twice and increase the delay unnecessarily?

Nevertheless:
I think caching can done with a genserver (acts data holder) that invalidates his data with a Process.send_after/3 message. Please make sure your clients are aware they are receiving cached data.

Batching probably depends on the REST API Interface. Bear in mind that you probably don't want to slow down the graphql queries even further by waiting for the data of other queries to arrive.

Parallel requests should be very easy because you can spawn a different process for every request with Task.async/1 and then Task.await/2 them.

Maybe a stackoverflow answer will bear more fruits as I don't think this is related to graphql. Please feel free to correct me on that point.

[bruce]

I think the following example would be useful to most people:

• A GraphQL document that includes multiple fields that come from a _single_ HTTP URL
• An implementation of the schema using Absinthe batching to ensure only one HTTP request is sent to provide the data for these fields

This isn't really backing REST API-specific.

[johannesE]

Oh, okay, so I completely misunderstood this and the question makes sense now. Sorry for my previous comment.

[fbjork]

My use case is to have a GraphQL API Gateway in front of multiple (micro) services. The services currently expose REST APIs.

So the examples I would like to see are multiple requests being fired off in parallel to multiple services from the GraphQL gateway.

Does that makes more sense @johannesE ?

[mgwidmann]

@fbjork you'd be able to do this with the batch functionality
https://github.com/absinthe-graphql/absinthe/blob/80315a3cf915534d41f489cace18f22c1caa3ea5/lib/absinthe/middleware/batch.ex#L38

[bruce]

We're adding a "Batching Resolution" guide (for now, it's just a stub pointing at the middleware) as part of the documentation updates landing in #416.