fix: options and observeHeadersSent flag

[tomcatmwi]

The problem:
Currently, ExpressMiddleware will attempt to end the Express request after executing a GraphQL request by calling res.end(). If the request was already closed, or headers were sent earlier, an exception is thrown.

Why is this a problem?
Sometimes a GraphQL request may trigger a long server-side process, and we want to respond in some other way than a simple HTTP response. In the project I'm working on, some requests are received as a GraphQL request, but the response is sent as a Server Sent Event, sometimes up to a minute later.

In such a case, the GraphQL request should be responded immediately with just a HTTP code 200, or a simple response. However, if we do that, ExpressMiddleware will attempt to send another response when the process ends. This is undesirable.

What is the suggestion?
The simplest would be to simply skip sending a response if res.headersSent is true. However, this may also introduce unwanted side effects.

My suggestion introduces an options object alongside context. It currently has only one value, observeHeadersSent. If this flag is true, the middleware will not try to send a HTTP response if headers were already sent.

The options object can be extended later with other options, as needed.

[apollo-cla]

@tomcatmwi: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Apollo Contributor License Agreement here: https://contribute.apollographql.com/

[netlify]

👷 Deploy request for apollo-server-docs pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	6cdbf0b

[trevor-scheer]

@tomcatmwi what's the use case for the SSE in this context? Are you trying to implement subscriptions?

Depending on your needs, you might find the approach I took in this PR helpful.

I don't think that adding fields to the default context object is the right approach for this integration, but if you feel that's necessary for your use case you can absolutely write your own wrapper to accommodate your needs. It's pretty straightforward to integrate with AS4!

[trevor-scheer]

I'm going to close this PR since I'm fairly certain this is not the direction we want, but happy to continue discussion here and possibly entertain a different, agreed-upon approach if we can think of one.