Union of two libraries about server HOT 8 CLOSED

@deinok as there are no common "standards" yet I suppose the best way is to be compatible with how Apollo handles things as it seems to be the "most" popular.

from server.

@pekkah So, are you interested?

from server.

@deinok You're welcome to add contributions (in general, this org needs many more contributors). @pekkah has the "playground" component, which may be GraphiQL?

https://github.com/graphql-dotnet/server/tree/master/src/Ui.Playground

I'm not seeing all of the source for that in this repo.

from server.

@joemcbride Also I think that we should talk with other GraphQL lib providers and Facebook.
Seems like there is no standard about serving GraphQL over HTTP, only conventions.
For example:
In case of GraphQL error -> HTTP 200 or HTTP 5XX

The Spec only talks about the part that is solved in the lexer and in the core.

from server.

Yeah that's not part of the spec. I've been trying to follow what the graphql-js projects have done. We can look to the express-graphql project for some guidance.

https://github.com/graphql/express-graphql/blob/master/src/index.js

That project does 500 errors and a number of 400 errors. It would probably be pretty safe to follow what they are doing.

I'm in a Slack group with all of the maintainers of the major libraries if we need to reach out to them.

from server.

Hey @deinok help would be surely appreciated :) If you want to make an PR for the GraphiQL middleware similar to the Ui.Playground one already included that would be good start.

from server.

It would be nice to have a shared convention or spec for all the lib mantainers.
Probably we should start asking for it in https://github.com/facebook/graphql

from server.

GraphQL Playground is built on top of the GraphiQL so not sure if we need a separate middleware for it though. In any real world project I would go with customized GraphQL Playground or GraphiQL and only use the provided middlewares for demo/prototyping purposes.

from server.