# GraphQL clean schema generation

**URL:** <https://discuss.dgraph.io/t/graphql-clean-schema-generation/12619>\
**Category:** GraphQL\
**Tags:** kind:question\
**Created:** [February 3, 2021, 1:09pm UTC](https://discuss.dgraph.io/t/graphql-clean-schema-generation/12619 "2021-02-03T13:09:00Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Luscha](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/luscha/32/3588_2.png) [@Luscha](https://discuss.dgraph.io/u/Luscha)\
**Post date:** [February 3, 2021, 1:09pm UTC](https://discuss.dgraph.io/t/graphql-clean-schema-generation/12619/1 "2021-02-03T13:09:00Z")

</div>

I’m currently setting up an Apollo federation that federates Dgraph.  
One of the first step is to fetch the Dgraph’s GraphQL schema to serve as federated schema.  
To dump the Dgraph Schema I’m using the NPM graphql package and more precisely the [printSchema](https://graphql.org/graphql-js/utilities/) method.

It does the job and I’m able to fetch the schema, write it in a file and serve that file from Apollo.  
The problem is that the Schema is full of dead code and Dgraph specific directives.

# Dead code

Thanks to the `@generate` directive it is possible to avoid the generation of some operations in the served GraphQL schema. Unfortunately, it does not avoid the generation of the inputs:  
Disabling the `mutation` generation of a type, Dgraph still generates the input needed for the mutation, even if it won’t be used anywhere in the Schema.  
I need therefore to remove manually all the inputs to reduce the size of the served schema (my Dgraph schema is about 1000 line length, which generates a ~10k line GraphQL schema and ~2-3k lines are just dead input types)

# Dgraph specific directives

Fetching the schema, I get also the directives used by Dgraph to actually define the schema (`@generate`, `@id`, `@lambda`, …) and I have once again to manually clean it up because the Federation requires all the services to implement the same set of directives.

* * *

Since GraphQL schema is subject to changes and it is likely to fetch a new schema periodically from Dgraph to serve it thought an Apollo server, is there a better way to fetch a `ready-to-apollo` schema? Maybe using the /admin endpoint?  
And also, is there any plan to improve the auto generation of the GraphQL schema pruning all useless `input` and `*Ref` types?

---

<div class="post-metadata">

**Author:** ![rajas](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/rajas/32/4393_2.png) [@rajas](https://discuss.dgraph.io/u/rajas)\
**Post date:** [February 3, 2021, 1:31pm UTC](https://discuss.dgraph.io/t/graphql-clean-schema-generation/12619/2 "2021-02-03T13:31:53Z")

</div>

Is there any specific reason that you want to remove dead code. Does Apollo Federation enforce any size limit on schema size ? We can look into removing dead code generation if there is a valid use case.

> [@Luscha](#):
>
> Disabling the `mutation` generation of a type, Dgraph still generates the input needed for the mutation, even if it won’t be used anywhere in the Schema.

This is not true. We do have checks inside code which don’t generate unwanted `Payload` and `Input`. Can you share a small schema with example where this is happening.

Example where generate directive prevents writing of `Input` and `Payload` types:  
The [input schema](https://github.com/dgraph-io/dgraph/blob/master/graphql/schema/testdata/schemagen/input/generate-directive.graphql) does not generate `AddPersonInput` and `AddPersonPayload` in [output schema](https://github.com/dgraph-io/dgraph/blob/master/graphql/schema/testdata/schemagen/output/generate-directive.graphql) as it has been disabled using generate directive.

---

<div class="post-metadata">

**Author:** ![rajas](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/rajas/32/4393_2.png) [@rajas](https://discuss.dgraph.io/u/rajas)\
**Post date:** [February 3, 2021, 1:41pm UTC](https://discuss.dgraph.io/t/graphql-clean-schema-generation/12619/3 "2021-02-03T13:41:46Z")

</div>

> [@Luscha](#):
>
> Dgraph to serve it thought an Apollo server, is there a better way to fetch a `ready-to-apollo` schema? Maybe using the /admin endpoint?

The generated GraphQL schema can be queried using the following query on `/admin` endpoint.

```auto
query{
  getGQLSchema{
    generatedSchema
  }
}

```

---

<div class="post-metadata">

**Author:** ![Luscha](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/luscha/32/3588_2.png) [@Luscha](https://discuss.dgraph.io/u/Luscha)\
**Post date:** [February 3, 2021, 5:22pm UTC](https://discuss.dgraph.io/t/graphql-clean-schema-generation/12619/4 "2021-02-03T17:22:39Z")

</div>

@rajas Thank you for the suggestion, using the Dgraph admin endpoint i was able to pull a clean schema.  
It seems that graphql-js/utils generates some garbage (all input \*\*Ref types for example) and fetches the directives as well.

`Querying /admin directly is possible to fetch a ready-to-apollo schema`

Regarding the first answer, no there is not an Apollo costraint which limits the schema size, but since The apolllo Server has to add some directives (`@cost`, `@ratelimits`) to protect dgraph, i’m still thinking of the best way to handle and keep synced this 2 schemas (one coming from Dgraph, and the second served by Apollo)… And having thousand of lines of useless inputs was not helping at all.

---

<div class="post-metadata">

**Author:** ![Luscha](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/luscha/32/3588_2.png) [@Luscha](https://discuss.dgraph.io/u/Luscha)\
**Post date:** [February 3, 2021, 5:33pm UTC](https://discuss.dgraph.io/t/graphql-clean-schema-generation/12619/5 "2021-02-03T17:33:10Z")

</div>

EDIT 1  
Hitting the Admin endpoint, Dgraph returns the schema still tagged with the Dgraph specific directives (`@generate`, `@search`, …) making it not usable in apollo without manual work;

---

<div class="post-metadata">

**Author:** ![rajas](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/rajas/32/4393_2.png) [@rajas](https://discuss.dgraph.io/u/rajas)\
**Post date:** [February 4, 2021, 5:23am UTC](https://discuss.dgraph.io/t/graphql-clean-schema-generation/12619/6 "2021-02-04T05:23:57Z")

</div>

Yes, the generated schema will contain Dgraph directives like `@generate` and `@search` .

Why do you need to remove Dgraph directives like `@search` and `@generate`. I do understand that they are Dgraph specific and may not add value while using the schema with other tools. But, my understanding is that they are harmless and don’t need to be removed while using with other tools like Apollo Federation.

We can look into having an endpoint with removed Dgraph specific directives if there is a valid use case for it.

Also linking a somewhat [related post](http://discuss.hypermode.com/t/dgraph-directives-reference-for-other-tools/12055) for reference.

---

<div class="post-metadata">

**Author:** ![Luscha](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/luscha/32/3588_2.png) [@Luscha](https://discuss.dgraph.io/u/Luscha)\
**Post date:** [February 4, 2021, 1:58pm UTC](https://discuss.dgraph.io/t/graphql-clean-schema-generation/12619/7 "2021-02-04T13:58:34Z")

</div>

The problem is that Apollo Federation requires all federated services to implement the same set of directives.

This generates quite a lot of manual work and a non-maintainable environment for Apollo Federation since each federated service has to implement - or at least declare- the digraph directives in their own schema.

Secondly, it seems that Apollo Federation itself, which seems to not be production ready, doesn’t like directives declaration using non-scalar types as parameters (like `@custom` which uses CustomHTTP type) and simply rejects the schema.  
^ This issue is not Dgraph fault, but still, it is blocking

---

<div class="post-metadata">

**Author:** ![trka](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/trka/32/5749_2.png) [@trka](https://discuss.dgraph.io/u/trka)\
**Post date:** [February 4, 2021, 3:23pm UTC](https://discuss.dgraph.io/t/graphql-clean-schema-generation/12619/8 "2021-02-04T15:23:31Z")

</div>

Can you compare with the steps in the recap at [Dgraph Directives reference (for other tools)? - #4 by trka](http://discuss.hypermode.com/t/dgraph-directives-reference-for-other-tools/12055/4)?

What that returns for me is spotless - no directives at all, only types and fields from my model. It’s possible that we have a version mismatch or something, of course, but it’s worth a double-check

---

<div class="post-metadata">

**Author:** ![rajas](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/rajas/32/4393_2.png) [@rajas](https://discuss.dgraph.io/u/rajas)\
**Post date:** [February 12, 2021, 11:23am UTC](https://discuss.dgraph.io/t/graphql-clean-schema-generation/12619/9 "2021-02-12T11:23:27Z")

</div>

@Luscha, 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,

```auto
query {
    _service{
        sdl
    }
}

```

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

You may find example in the `TestApolloServiceResolver` test of the following code commit, [feat(GraphQL): Extend Support For Apollo Federation (#7275) · dgraph-io/dgraph@1e6af7e · GitHub](https://github.com/dgraph-io/dgraph/commit/1e6af7edc0e8cb63528244070695a17c38ebae37) .