Is it possible to do GraphQL Schema Stitching with Absinthe

Questions / Help
,
1

Does anyone know if it possible to do GraphQL Schema Stitching with Absinthe?

The Apollo article about schema stitching is very exciting:

https://dev-blog.apollodata.com/graphql-schema-stitching-8af23354ac37

But rather than add a nodejs dependency to our application it would be great to do the stitching directly in Elixir (probably with Absinthe), has anyone played with GraphQL schema stitching?

3 Likes
2

Not yet!

This is the primary feature aimed at with Absinthe 1.5. I can’t give you a timeline yet, but we believe we have a high level approach that will work, and it’s largely a matter of carving out the time to make it happen.

11 Likes
3

Cool, I’m glad that it’s on the radar. Is the plan for 1.5 to have “full” stitching (i.e. links as described by that article)? Or will 1.5 just have basic stitching. For the initial version of our API we only really need basic stitching, so it would be nice to play with that before “full” stitching is ready.

1 Like
4

For reference here is the matching issue with discussion in the Absinthe project:

5

I think the plan is to do full linking, there isn’t gonna be much of an incremental change there I think. The largest amount of work here involves refactoring the internal mechanics of schema building, and adding GraphQL client capabilities. Once those capabilities are in place that full feature set should fall out pretty easily. Or at least that’s the plan :wink:

6

Is the implication here that there will also be GraphQL client capability in the API in Absinthe 1.5, or will it only be used internally to support the schema-stitching?

7

@GregMefford this is a good question. The answer is honestly TBD at this point. I can say that in order to make sure that Absinthe 1.5 doesn’t take forever to come out, we’ll likely target the minimum functionality we need to do schema stitching. However if this functionality can be exposed via publicly documented functions we will absolutely do so.

8

My vote would definitely be to focus on the schema-stitching feature! :thumbsup:

I was going to say “it would be nice to have GQL client support if it’s easy”, but on second though, we all know that extending the API is never easy because it’s more surface area that you need to support. Maybe save it for 1.6. :sweat_smile:

9

Yeah exactly. I fully expect to have some internal functions that may be useful to folks, but we’ll likely keep them undocumented so that when we do 1.6 or whatever we can think through the client story in more specific detail. Schema stitching is ambitious enough without also trying to nail down a client API.

10

Is there any recommended approach for super basic schema stitching before 1.5 is out? I’m thinking something along the lines of creating a controller (although code could live somewhere else) that just takes a graphql query, splits it based on top-level keys and sends it to separate GraphQL backends and then merges them back together.

This is the basic foundation of what we need so that we don’t need to expose multiple GraqhQL endpoints to our end-clients. These are all internal GraphQL api’s that we are in the process of building, so it shouldn’t be too difficult to keep them “compatible” in terms of authentication and other concerns.

1 Like
11

Hi @benwilson512 and thank you for everything you’re doing!

I was wondering if schema stitching was still on Absinthe’s roadmap? I’m currently building a small distributed app and this would be a very useful way to manage collaboration of microservices behind GraphQL API.

Cheers! :beers:

12

Hey! Here’s where we stand:

I have largely completed the gigantic rework of schema internals required to do the dynamic schemas we need for stitching.

We also have support for SDL based schemas, and thus by extension introspection based schemas.

So, what remains?

  • Various mechanics around how to dynamically update these schemas.
  • Lots of questions about the client side of this. This has the most work remaining to it. I really need to dig into what other clients are doing, is there even a suggested spec for how this works?

There’s also a handful of small internal changes to do, but that encompasses the bulk of the remaining work.

7 Likes
13

Hi Ben and thank you for your quick and thorough answer.

I’m faced with a quite interesting challenge and after hours of research, I thought maybe you (or anyone else here) would have an idea on how to tackle it.

My goal is to make a distributed app in which the business logic would be split between microservices. I’m not 100% positive but I think schema stitching will be of great help once I want to scale it out on multiple nodes.

For now though, I really don’t need to and would be happy with an umbrella app with local dependencies. I think this would be a viable option for a couple of years. Being careful about encapsulation would also make it easier when it’s time to scale.

Here is an example of a GraphQL document I’d want my app to be able to respond to:

{
  users {
    possessions {
      ...
    }
  }
  possessions {
    users {
      ...
    }
  }
}

A simple many-to-many relationship, but here’s the catch. The umbrella app would look like this:

umbrella_app
  apps
    graphql_entry_point
    users
    possessions

This is not a real life example but you get the idea. I’d like to split some parts of the business logic between multiple apps and have a single GraphQL node to rule them all.

I’ve explored many options. Here are my thoughts:

  • What I’d like the most is to have each business logic app (users and possessions) be responsible for its own GraphQL schema and have the graphql_entry_point app import their types and fields.

    • I can’t seem to make this work. Since users and possessions are related to each other and I therefore need to share their types and fields, I always end up with compilation errors (duplication of things that must be unique). If you have an idea, example or anything that would help me do this, I’d be so happy! :tada:

  • I could have my whole schema defined in the graphql_entry_point app and then call the other apps for the data that I require.

    • This option might not be in line with my former goal, that was to split load between microservices. As the business logic will grow, the graphql_entry_point app will be the only one responsible for building and processing everything Absinthe related. I don’t know if it’s a real concern, maybe Absinthe is so lightweight it could handle any sized schema like a breeze. However, I’d still like each app to be responsible for defining its own schema.
    • I don’t see a viable option for the graphql_entry_point app to call the other apps for getting their data. Function calls through an interface layer? Rest? GraphQL documents (duplicated or altered)? Every option seems to add a lot of complexity and reduce the flexibility GraphQL was engineered for.

Whatever your thoughts are, I’d be very happy to hear them! Don’t hesitate to destroy my ideas or preconceptions as I’m here to learn.

Cheers! :beers:

1 Like
14

I tried the second option:

Since resolvers are just plain Elixir modules, I was able to interface with my business logic apps (users and possessions) using them.

It works like a charm (for now at least! :grin: :pray:).

I think it’s a good trade off for now. The only thing I don’t quite like about this is:

I’m still craving for ideas or suggestions! I’m just sharing this solution as someone might find it useful.

Cheers! :beers:

15

Can’t wait for the 1.5 version. Our whole infrastructure is based on micro services and I’m having a hard time on the implementation of fields with different back-ends.

Any ideas on the date? I can see at least 3 alpha version in GitHub :eyes:

4 Likes
16

Now the absinthe last version is v1.5.0-beta.1, can I do GraphQL Schema Stitching on it?

17

I think not. The pull request is still pending and there is no example in guides.

18

1.5 enables the construction of schemas from many different sources, including APIs. To do schema stitching, you need this kind of schema building plus a bunch of runtime stuff to do the actual splitting of a query.

That latter stuff is no longer slated for 1.5, but will come in a later release. @binaryseed has taken point on the schema stitching execution mechanics since he’s doing a version of schema stitching at his company already.

2 Likes
19

My team has released an example app that does Schema Stitching in Absinthe…

Eventually I’d like to see some form of this make it into Absinthe itself, but there are lots of decisions to make about how to accomplish that. Meanwhile, those who really want to get something up and running can check out what we did in our API at New Relic.

5 Likes
20

Hi,

Now that Schema Stitching is deprecated, do you guys still plan to release that feature as part of 1.5, or have the plan changed to comply with the new “Federation” feature?

TIA

1 Like