Server architecture for large schemas. Type extensions?

My team is migrating an existing GraphQL API from JS to F#. Our API has a lot of types, so we decided to create a file per type (Define.Object).

The file structure looks like this:

• Schema
  • User.fs
  • Organization.fs
  • …
  • Query.fs

If Organization has a users field that returns ListOf User, you can simply compile User.fs before Organization.fs. However, this doesn’t work if User also needs to have an organizations field, because F# doesn’t allow mutual recursion across files.

What is the recommended way to architecture a big server like this? The samples use a single schema file, but unfortunately, that’s just not feasible for our use case. If we did this, we would eventually have a file with 20K+ lines of code (judging by the size of our JS API).

A solution might be supporting Type Extensions. Especially, Object Extensions: http://spec.graphql.org/June2018/#sec-Object-Extensions

With Object Extensions, we would be able to define these relationship fields at the return type module instead. In my example, Organization.fs would add the organizations field to the User type, and User.fs would add the users field to the Organization type.

This architecture would work out pretty nicely for us because the querying and authorization logic needed to return records of a type would remain in its module as opposed to being spread across the codebase.

Supporting GraphQL extensions would also allow users of this library to build GraphQL microservices, that could be composed using tools like Apollo Federation.

If you think that’s a good idea, I’d be more than happy to contribute. Thanks!

[agu-z]

Yep, that’s where the inspiration came from.

I think adding all types explicitly is not a problem. It’s easy to put them on a lists and concat them at the end.

I’ll start working on an ObjectRef implementation tonight. Extensions can come later.

Thanks for the feedback!

[jberzy]

@agu-z,

Another option is we could always allow for forward declarations of a typedef. e.g.:

// User.fs

let OrganizationRef = Define.ObjectRef<OrganizationModel>("Organization")
let User = Define.Object(...
     Define.AsyncField("organizations", ListOf OrganizationRef, fun _ user -> organizationsByUserId user.Id)
)

// Organization.fs

let UserRef = Define.ObjectRef<UserModel>("User")
let Organization = Define.Object(...
     Define.AsyncField("users", ListOf UserRef, fun _ organization -> usersByOrganizationId organization.Id)
)

The primary benefit of this approach over extensions is it doesn’t require the typedefs be split across multiple files.

At least one drawback is more “orphaned” typedefs not reachable from entrypoints. e.g. in the above scenario if UserRef and not User is ever “seen” by the schema we wouldn’t have a handle to the underlying typedef to swap. The solution is to register User to the schema through SchemaConfig.Types (but that’s still an additional thing to remember).

This would not cover all the use-cases for extensions. I think supporting both approaches would be ideal.

Thoughts?

Thanks, John