Git Product home page Git Product logo

Comments (21)

kbrandwijk avatar kbrandwijk commented on March 28, 2024 1

I have just released an Express body-parser that supports the application/graphql MIME type. It can be used as a drop-in replacement for the JSON body-parser. https://www.npmjs.com/package/body-parser-graphql 🎉

from apollo-server.

stubailo avatar stubailo commented on March 28, 2024

As far as I know, application/graphql is not a thing people usually do - why not use application/json?

from apollo-server.

nevir avatar nevir commented on March 28, 2024

I was playing around w/ a few modules, one of which expected it to be supported (graphql-tester)

from apollo-server.

stubailo avatar stubailo commented on March 28, 2024

Yeah, that seems super weird to be honest. I don't think it's to anyone's advantage to introduce new MIME types? It's nowhere in the spec or any implementations that I'm aware of.

from apollo-server.

nevir avatar nevir commented on March 28, 2024

express-graphql does support it

from apollo-server.

helfer avatar helfer commented on March 28, 2024

@nevir Which version of apollo-server did you use? The current release uses express-graphql under the hood, so I find it hard to believe that it wouldn't work. The release candidate doesn't parse queries automatically, so you'd have to do that yourself by telling body-parser to parse application/graphql.

from apollo-server.

nevir avatar nevir commented on March 28, 2024

I was on 0.1.5 at the time - haven't tried since (we have no good use case for application/graphql now that we understand what's going on :P)

from apollo-server.

helfer avatar helfer commented on March 28, 2024

Hm, that's strange. It should definitely work because 0.1.5 passes the same tests as express-graphql.

from apollo-server.

tony19 avatar tony19 commented on March 28, 2024

The current release uses express-graphql under the hood, so I find it hard to believe that it wouldn't work.

Hmm. I didn't find any reference to express-graphql in graphql-server-express's code/manifest.

@helfer I can confirm that graphql-server-express 0.4.3 (used by the frontpage-server demo) does not support Content-Type: application/graphql.

application/json works:

$ curl -X POST http://localhost:8080/graphql -d '{"query": "query test { posts { title } }" }' -H 'Content-Type: application/json' 
{"data":{"posts":[{"title":"Introduction to GraphQL"},{"title":"GraphQL Rocks"},{"title":"Advanced GraphQL"}]}}%

but not application/graphql:

$ curl -X POST http://localhost:8080/graphql -d '{ posts { title } }' -H 'Content-Type: application/graphql' 
{"errors":[{"message":"Cannot read property 'definitions' of undefined"}]}% 

It was an easy switch to express-graphql to get that header to work, and its simpler interface is a bonus.

from apollo-server.

stubailo avatar stubailo commented on March 28, 2024

Content type application/graphql isn't great because it doesn't support variables. I would suggest just not using it.

from apollo-server.

tony19 avatar tony19 commented on March 28, 2024

@stubailo Can you clarify? Variables work for me.

from apollo-server.

stubailo avatar stubailo commented on March 28, 2024

How do you pass them, as query parameters?

from apollo-server.

tony19 avatar tony19 commented on March 28, 2024

Sorry, I misunderstood what GraphQL variables were until I read the docs.

from apollo-server.

stubailo avatar stubailo commented on March 28, 2024

Right - variables are a critical part of the GraphQL specification, so it's really surprising that the "official" HTTP server middleware supports a transport that doesn't have any ability to use them.

from apollo-server.

jsamr avatar jsamr commented on March 28, 2024

application/graphql is mentioned in the official guide

from apollo-server.

helfer avatar helfer commented on March 28, 2024

@sveinburne I would find it interesting to know why they recommend supporting those two use-cases. If there's a good reason for it, I wouldn't be opposed to adding the same functionality in graphql-server.

Right now I think it was a mistake to come up with "application/graphql", thus I don't think graphql-server should support it. After all, Lee Byron said himself that when you're thinking of adding something but you're not sure you'll need it, then "you ain't gonna need it". So far I haven't heard a convincing argument for why anybody needs "application/graphql". I'd like to be enlightened though, so if someone knows, please tell me!

from apollo-server.

stubailo avatar stubailo commented on March 28, 2024

Yeah there was a discussion on some graphql.org issue about removing that recommendation and I didn't find any concrete arguments for why it exists.

from apollo-server.

hulkish avatar hulkish commented on March 28, 2024

Would really appreciate this somehow being sought through. Personally, I think it's better if they just pick one... Only reason I suppose this is a value use case - is for GET requests, - since you can'tt send a post body with that request method?

from apollo-server.

sleepycat avatar sleepycat commented on March 28, 2024

@helfer maybe need is a strong word for application/graphql but I think it's a nice developer experience for testing and when using curl.
An example test:

describe('Server', () => {
  it('has GraphQL middleware mounted at /graphql', async () => {
    let server = new Server()
    let response = await request(server)
      .post('/graphql')
      .set('Content-Type', 'application/graphql; charset=utf-8')
      .send(`{ hello }`)

    expect(response.status).toEqual(200)
  })
})

and curl:

curl -v -H "Content-Type: application/graphql" -d "{ hello }"  "localhost:3000/graphql"

JSON is clunky for those simple cases and readability suffers. This obviously isn't a big thing, but it's still nice to have IMO.

from apollo-server.

stubailo avatar stubailo commented on March 28, 2024

If you want to run a GraphQL proxy, or handle requests in the middleware chain, multiple ways to send queries can be a big downside. You pretty much need both GET and POST, but the application/graphql method is more optional. You could always add an extra middleware to the chain to attach stuff to the request body to add support for other transports.

from apollo-server.

btilford avatar btilford commented on March 28, 2024

Shouldn't the content type be something like application/graphql+json? I've got a situation where graphql is only going to be used in specific scenarios so application/json isn't specific enough.

from apollo-server.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.