Server architecture for large schemas. Type extensions?

Aperta
#290 10 commenti 2 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
fsharp, graphql
Ambito
api, backend-api-design

Direzione di ricerca

Inizia esaminando la struttura descritta di User.fs, Organization.fs e Query.fs insieme alla specifica GraphQL Object Extensions collegata nella issue. Determina se la libreria dispone già di un punto di ingresso per lo schema o per la definizione degli oggetti per questa architettura. L’attività sarà considerata completata quando sarà disponibile una raccomandazione condivisa o un piano di implementazione chiaramente circoscritto per i campi delle relazioni tra file e le estensioni.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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!

Lingua principale
F#
Stelle
406
Fork
74
Merge medio
1g 8h
PR unite (30g)
14

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di fsprojects/FSharp.Data.GraphQL

Tutte le issue di fsprojects/FSharp.Data.GraphQL

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.