a-type / dgraphql Goto Github PK

func really just seems like the primary filter. Perhaps we could make things easier by automatically using the first filter as the func unless the user requests a specific one.

Perhaps the queries could be broken down in a way that allows multiple sections of the final query to be run in parallel. I bet a clever use of storing variables could help run multiple edges as top-level query blocks...

It's currently mandated that the user pass a typeName as part of the return of their resolver info function. This seems pretty unnecessary.

The library could be evolved to include a built-in sense of 'labeled' nodes, i.e. that certain nodes match certain defined GraphQL types. These nodes could automatically be managed by the library itself, but only after mutations are added.

Until then, users could define a predicate which determines the 'label' for each type just once during library initialization, instead of passing it every time.

Aliasing predicates is a pain right now. You have to define a whole dgraphql query resolver just for one field. A more terse form would be welcome.

Probably my least favorite requirement so far. I'd rather not force the user to pass their resolvers back into dgraphql in order to understand which resolvers correspond to which fields in the schema.

Unfortunately, since Apollo at least wraps resolvers, I can't use the original plan of attaching function ids to the schema resolvers and reading them back at resolve time.

I don't have any good ideas for this one. It's a little nice-to-have.