`runHttpQuery` alternative for non HTTP Frameworks? (ApolloServer RSocket Integration)

I’m working on a ApolloServer implementation to support an accompanying terminating ApolloLink for the RSocket protocol, and am looking for some help to determine the best way to leverage existing apollo-server-core APIs.

RSocket GraphQL Interop

RSocket is a streaming binary protocol that supports several interaction models, and these interaction models align well with the interaction models required for GraphQL:

  • RSocket RequestResponse → GraphQL Query/Mutation
  • RSocket RequestStream → GraphQL Subscription

ApolloServerBase & apollo-server-core APIs

While I have found that the ApolloServerBase and apollo-server-core APIS are sufficient for implementing basic support for Query/Mutation operations over RSocket, these APIs appear best suited for HTTP and as such are a bit awkward to use outside of an HTTP context.

For instance, the runHttpQuery API appears to be the easiest way to process an incoming “request”, even when that request is not produced from a HTTP context.

In RSocket, we have the concept of a “payload” which represents an event that the server has received. Given a payload, we can construct the arguments required for the runHttpQuery, but some of the inputs are entirely faked and are only provided to satisfy the runHttpQuery API.

const { data } = payload;
const decoded = data.toString();
const deserialized = JSON.parse(decoded);

const { graphqlResponse } = await runHttpQuery([], {
  method: "POST",
  options: () => {
    return this.createGraphQLServerOptions(payload);
  query: deserialized,
  request: new Request("/graphql", {
    headers: new Headers(),
    method: "POST",


For framework integrations which do not handle HTTP requests, is there a better API than runHttpQuery for processing a GraphQL Query/Mutation operation?


Hi! We’re actually reworking the whole API right now as part of Apollo Server 4, which you can follow along on the version-4 branch or the milestone or the roadmap.

As part of this we’re getting rid of the old standalone functions like runHttpQuery which date back to Apollo Server 1 when there wasn’t even an ApolloServer object at all. ApolloServer should end up with two main entry points: one which is “execute this HTTP request” and one which is “execute this parsed operation”. The latter will be basically like today’s executeOperation method which right now is largely for testing but which I think can be a bit better connected to the main flow in the new API.

I think executeOperation is likely your best bet for doing non-HTTP-based operation execution in AS3 today, and I hope it’ll be even more natural in AS4.

1 Like

Just looping back around to this topic now that we’ve published a draft PR for our Apollo integration in RSocket-JS. I’ll need to look a bit more into executeOperation for the time being, but also looking forward to Apollo Server 4 if it will make this type of non-HTTP interaction more natural.

Thanks for the response & guidance!