[Connectors Live] Stripe Q&A

About the Community General
1

We will be having our first trial run of Connectors Live on 12/12 at 10AM PST where we spend 30 minutes to build a real connector with a real API. We’ll also cover hosting the Apollo Router and getting everything setup.

If you haven’t registered for a spot already, you can do that here. We’ll have it recorded and share the recording once it’s ready. I’ll also be pointing any questions to this thread after we wrap up the stream.

1 Like
2

Question from the stream:

How to dynamically update the REST API URL?

Great question! You can do this with the override_url option in your router.yaml (docs):

preview_connectors:
  subgraphs:
    example: # The name of the subgraph
      sources:
        v1: # Refers to @source(name: "v1")
          override_url: "https://api.example.com/v1/beta"
3

Question from the stream:

Would you recommend using or avoiding connectors in cases where we have more complex mapping logic between the REST API and the exposed graph types? Are there ways to simplify that setup or test the mapping logic in the schema?

There is a current list of limitations in our documentation that would be good to review if your use case crosses that. Those will change over time as we build out more in Connectors.

As for testing the mapping logic, there is some tools coming in the near future that would help you with testing that. Currently, there is a language server integrated into the Rover CLI that provides validation on the mapping/selection you type in the schema.

One way to simplify that setup is to just start with entities for your graph. Don’t think about the mapping logic between them, just expose the raw entities themselves like this:

type Foo {
  id: ID!
  active: Boolean
}
type Bar {
  id: ID!
  name: String
}
type Query {
  foo(id:ID!): Foo 
    @connect(
      source: "api"
      http: { GET: "/foo/{$args.id}" }
      selection: """
        id
        active
      """
      entity: true
    )
  bar(id:ID!): Bar
    @connect(
      source: "api"
      http: { GET: "/bar/{$args.id}" }
      selection: """
        id
        name
      """
      entity: true
    )
}

Then if you wanted to start connecting these entities, you can start to think about how they map together and implement something like:

type Foo {
  id: ID!
  active: Boolean
}
type Bar {
  id: ID!
  name: String
  foo: Foo
}
type Query {
  foo(id:ID!): Foo 
    @connect(
      source: "api"
      http: { GET: "/foo/{$args.id}" }
      selection: """
        id
        active
      """
      entity: true
    )
  bar(id:ID!): Bar
    @connect(
      source: "api"
      http: { GET: "/bar/{$args.id}" }
      selection: """
        id
        name
        foo { id: fooId } # <- this is the connection where the Bar API endpoint returns the id for the Foo object
      """
      entity: true
    )
}

:point_up: the nice thing here is that the executed requests only include a fetch to /foo/{id} when the query includes bar.foo like below:

query {
  bar(id:"1") {
    name 
    foo {
      id
      active # <- adding this field will have the router orchestrate a request to /foo/{id}
    }
  }
}

I would love to learn more about your specific complex scenario and try to help! I’ll see about reaching out to you directly.

4

Question from stream:

is there an equivalent for dataloaders with connectors?

This is something we have coming! It would also be helpful if you would send us any information about how your batch endpoints work so we can ensure the system we’re designing would work with your APIs!

5

Question from stream:

How can circuit breaker functionality be implemented for the apis connected?

We would recommend doing your circuit breaking with a service mesh or some other general networking management tool.