Well, firstly, that's the only option in released code.

Secondly, GraphQL's schema grammar doesn't have a place to specify any logic; that fits ok with the JavaScript RI, where a single function is responsible for everything, but in Lacinia, you provide the necessary resolvers as function callbacks.

In addition, we at Walmart, but also others using Lacinia, have seen great benefit in building up the schema procedurally, using standard Clojure data manipulations. Our experience with Clojure leads us to solutions that can be done as much as possible inside Clojure ... and testable at the REPL.

The next Lacinia release will include the ability to parse a schema file into Lacinia's format ... but you'll still have the ability to manipulate that structure before compiling it for execution.

I personally think that EDN rocks. Been there for the past few months writing 3 different projets using Lacinia and EDN fits perfectly. Very modular and easily interpreted to inject stuff on needs.

Yeah I’m loving that it’s in EDN, been doing some crazy stuff with going from datomic schemas to lacinia EDN, and vice versa.. It’s a breeze

thanks, I can definitely see the value in being able to manipulate a schema in EDN.

I think that just having some process (even a separate compiler) to do schema->EDN would be really great

our company is currently working on defining a huge project using GraphQL and I'm keeping my eye on lacinia/pedestal, but a lot of work will be done just in defining the schema

having the ability to define that schema and then convert it to EDN would help a lot, rather than having to re-write it by hand

Well, the intent on compiling the schema from the GraphQL grammar is to make it easier to share a schema across platforms.