How do you use this library? Please tell me to help improve it! about graphql-gateway HOT 25 CLOSED

Subscriptions, @defer and @stream will be supported from the beginning.

I'd say the biggest difference against existing solutions is that we're compiling Queries.
I've tested against Apollo Federation Gateway and was able to perform between 37-165x faster with sub-millisecond 99th percentile latency whereas Apollo was at >1s latency 99th percentile.

Another difference is the flexibility of data sources. We'll support GraphQL Schema Stitching, GraphQL Federation and REST APIs from the beginning. Later on, we'll add support for SOAP, OData, Kafka, RabbitMQ, NATS etc.
So you can do a lot more than just GraphQL stitching.

We'll also add Authentication, Authorization & Caching and an additional Code Generator so that you don't even have to write client code yourself. Just write a query, annotate it with a directive and that's it.

from graphql-gateway.

@jensneuse I updated the Apollo Federation to run four Go GraphQL (gqlgen) Services federated behind the Apollo Gateway, over here: federation demo

I would like to set up your gateway as a replacement for the Apollo Gateway. Do you have an example of how to do this?

Looks great!
Let me finish my work and I'll open a PR to add a fully working example.
I guess it'll be done before Christmas.

In the meantime, would you like to add an extra branch with subscriptions?
Apollo Gateway won't start once you enable subs, just so you know.
Otherwise, I can add it too.

from graphql-gateway.

If so, then that would be a deal breaker for me and I wouldn't push the changes, or I would leave them on a branch. DGraph supports subscriptions, so ideally I would like a federated set of services including DGraph with a gateway that supported subscriptions (yours). I'll let you know what I find out though.

It's nothing I can promise before Q1 2021 but I'm actually looking into a way to make non-federated services federated without changing them. It's just a matter of configuration and then rewriting the queries so that the participants behave like federated graphql servers even when they don't implement the spec themselves.

from graphql-gateway.

It's worth looking at this Dgraph forum thread Dgraph Directives reference (for other tools)? as they've recently added Apollo Federation support:

we have recently added support for Apollo Federation in master branch. This will be available in our next release, 21.03 scheduled for March.
The schema with (@Custom and @auth removed) can be obtained by running the following the query,

query {
    _service{
        sdl
    }
}

We are in the process of adding documentation for Apollo Federation Support.

I have a similar use case to @StevenACoffman where I need to put something in front of Dgraph, either a proxy or federate it, but also need to add some additional business logic GraphQL endpoints which in turn also use data from Dgraph.

At the moment I'm wondering if this is best done by creating a proxy (hence looking at graphql-go-tools) and splicing in the additional bits into the overall schema; or by using a federated gateway where the Dgraph and business logic endpoints are more side-by-side. In both cases authorisation of access to the API are a key requirement.

I've also been looking at pulling the expanded GraphQL schema out of Dgraph (see the query above) and using that to generate much of the boilerplate. e.g. using a combination of something like gqlgen and gqlgenc.

More documentation and some examples would really help my understanding of graphql-go-tools. From the test cases I can see that it's potentially very suitable, but I'm struggling a bit to understand how I would best use it as an augmented proxy.

Your use case sounds very interesting. I'd love to have a chat and see how I might help: https://calendly.com/jens-neuse

from graphql-gateway.

I think ,it may use like k8s-ingress

client -> loadbalance -> k8s-ingress -> service

client -> loadbalance -> graphql-gateway -> service

from graphql-gateway.

@jensneuse Hi! I was wondering if you are continuing this as part of the Tyk Gateway.

from graphql-gateway.

@jensneuse Hi! I was wondering if you are continuing this as part of the Tyk Gateway.

Hey, thanks for asking. Yes, you're absolutely right. The first version actually got just shipped a few days ago. You can test it out in the cloud version. It's capable of protecting existing graphql APIs as well as stitching together GraphQL and REST APIs. More datasources to come. So it's basically the functionality of this repo here with some advanced security features like field level permissions etc. plus a GUI to configure everything rather than annotating schemas with directives.

Let me know if you have any questions or want to get into contact with a consulting engineer at tyk to get you started.

from graphql-gateway.

There's a general discussion about DGraph and different federation techniques happening over at dgraph-io/dgraph#4724 that I mentioned your work.

from graphql-gateway.

Hi!
What do you think is missing to achieve following functionality:

• introspect multiple GQL schemas from different servers
• publish a stitched schema

Ideally, a really small config would be required:

servers:
 - serverA: 127.0.0.1:3000
 - serverB: 127.0.0.1:3001
port: 3002

from graphql-gateway.

Hi!
What do you think is missing to achieve following functionality:

• introspect multiple GQL schemas from different servers
• publish a stitched schema

Ideally, a really small config would be required:

servers:
 - serverA: 127.0.0.1:3000
 - serverB: 127.0.0.1:3001
port: 3002

Actually, I'm currently working on exactly this. It'll support GraphQL Federation + Schema stitching. Will keep you posted.

from graphql-gateway.

That's awesome!

Will it support subscriptions from the beginning?
And how would it differentiate from https://github.com/nautilus/gateway ?

from graphql-gateway.

@jensneuse I updated the Apollo Federation to run four Go GraphQL (gqlgen) Services federated behind the Apollo Gateway, over here: federation demo

I would like to set up your gateway as a replacement for the Apollo Gateway. Do you have an example of how to do this?

from graphql-gateway.

I'm going to play around with swapping out some of the services with DGraph, so I don't think I'll get around to adding a subscriptions branch before the holidays, but you are welcome to do so! I'd love to be able to try that out!

from graphql-gateway.

I'm going to play around with swapping out some of the services with DGraph, so I don't think I'll get around to adding a subscriptions branch before the holidays, but you are welcome to do so! I'd love to be able to try that out!

If you replace them with DGraph, does this mean they will no longer come with federation?

from graphql-gateway.

If so, then that would be a deal breaker for me and I wouldn't push the changes, or I would leave them on a branch. DGraph supports subscriptions, so ideally I would like a federated set of services including DGraph with a gateway that supported subscriptions (yours). I'll let you know what I find out though.

from graphql-gateway.

Hmm, so I would love to be able to use wundergraph/graphql-go-tools#22 to add a proxy in front of DGraph 's GraphQL that would make it support Apollo Federation. Basically like Using Apollo Federation with Local Schemas (Repo) but in Go instead of Node.JS. I thought I would ask before diving into trying it myself in case you already did that and it's laying around somewhere convenient.

from graphql-gateway.

Yeah, I can and will make that happen.
Can you give me a bit more detail?
E.g. where will the types come from and how do you want to extend things?
So, some parts will come from DGraph? And then you'll extend DGraph types with Federation Services? Would be nice to be as detailed as possible to I'm able to write tests for this and work towards the goal. Otherwise, I might be misunderstanding and not actually solving the problem.

from graphql-gateway.

Based on federation demo, the combined schema is:

type Product {
  upc: String!
  name: String
  price: Int
  weight: Int
  reviews: [Review]
  inStock: Boolean
  shippingEstimate: Int
}

type Query {
  me: User
  topProducts(first: Int = 5): [Product]
}

type Review {
  id: ID!
  body: String
  author: User
  product: Product
}

type User {
  id: ID!
  name: String
  username: String
  reviews: [Review]
}

I would like to replace the Product service with DGraph behind a federate-able proxy:

type Product @key(fields: "upc") {
  upc: String!
  name: String
  price: Int
  weight: Int
}

This Product type is extended by the inventory and reviews services.

DGraph does not support Apollo Federation, but is otherwise GraphQL native. The @key directive (and other apollo federation directives ) is/are not supported by DGraph, DGraph does not support _service introspection entry point (although it has something similar at /admin), DGraph also does not make each entity in the schema part of the _Entity union or Implement the _entities field on the query root.

I'm not sure that creating stub types for references would be required for this specific example. Does that clarify things?

from graphql-gateway.

@StevenACoffman I guess, DGraph doesn't offer the root query field topProducts, right?
So the final API will look a bit different I guess.

from graphql-gateway.

@StevenACoffman have a look at this:
https://github.com/wundergraph/wundergraph-demo
I'd love to hear your feedback

from graphql-gateway.

It's worth looking at this Dgraph forum thread Dgraph Directives reference (for other tools)? as they've recently added Apollo Federation support:

we have recently added support for Apollo Federation in master branch. This will be available in our next release, 21.03 scheduled for March.

The schema with (@Custom and @auth removed) can be obtained by running the following the query,

query {
    _service{
        sdl
    }
}

We are in the process of adding documentation for Apollo Federation Support.

I have a similar use case to @StevenACoffman where I need to put something in front of Dgraph, either a proxy or federate it, but also need to add some additional business logic GraphQL endpoints which in turn also use data from Dgraph.

At the moment I'm wondering if this is best done by creating a proxy (hence looking at graphql-go-tools) and splicing in the additional bits into the overall schema; or by using a federated gateway where the Dgraph and business logic endpoints are more side-by-side. In both cases authorisation of access to the API are a key requirement.

I've also been looking at pulling the expanded GraphQL schema out of Dgraph (see the query above) and using that to generate much of the boilerplate. e.g. using a combination of something like gqlgen and gqlgenc.

More documentation and some examples would really help my understanding of graphql-go-tools. From the test cases I can see that it's potentially very suitable, but I'm struggling a bit to understand how I would best use it as an augmented proxy.

from graphql-gateway.

I did find I’m writing a graphql proxy. (How) Would you use one? which has example code is in this branch which seem to have been merged in wundergraph/graphql-go-tools#22 ... but the proxy and example middleware directories don't seem to exist on master any more? I'm guessing this was split into graphql-gateway as per wundergraph/graphql-go-tools#42 ?

from graphql-gateway.

So I took the Apollo Federation demo that had already been ported to Go + gqlgen, and updated it.
The DGraph engineers then ported it to use DGraph (with a Dgraph lambda for the little dynamic behavior) here. However, this is still using Apollo's NodeJS gateway.

It looks like you have Gateway support now (woohoo!) in this example.

This is pretty cool, as it opens up a variety of pure-Go options for Federation!

from graphql-gateway.

I'm not sure which is more appropriate to ask in, wundergraph/graphql-go-tools#243 I put a question about why the schema is different in the federation example in that repository.

from graphql-gateway.

this codebase here is deprecated, conversations should happen on the other repo.

from graphql-gateway.