Export writeResponse and SubscriptionKey based delivery

[gitmodimo]

I am writting graphql server that is compatible with Apollo. I am also using rapidJSON. When handling response I need to copy the JSON response into Apollo transport message. Making writeResponse function publicly available would allow generation of the response in one go without copying.

graphql-ws Protocol

auto response=resolve(...);
rapidjson::StringBuffer buffer;
rapidjson::Writer<rapidjson::StringBuffer> writer(buffer);

writer.StartObject();
writer.Key("id");
writer.String(gql_ws.id.data());
writer.Key("type");
writer.String("next");
writer.Key("payload");

//copy
auto r=graphql::response::toJSON(std::move(response));
writer.RawValue(r.c_str(), r.size(), rapidjson::kObjectType);

//function not exported
// graphql::response::writeResponse(writer, std::move(response)); 

writer.EndObject();
return buffer.GetString();

[gitmodimo]

Going further. When implementing Subscriptions I noticed there is no possibility to deliver given SubscriptionKey. Looking at the code it should be pretty straight forward allow it.
This would allow implementer to handle updates based on touched leafs by registering listeners in NotifySubscribe and invoking deliver for affected SubscriptionKey-s.
In current implementation we can only deliver on root nodes of subscribe. Or am I missing something?

[wravery]

Interesting, I can see how those would help. The SubscriptionKey delivery mechanism seems like it would be more straightforward to implement. The rapidjson::Writer change would be a little more difficult since graphqljson is supposed to abstract the JSON parser implementation details for consumers. It could potentially export them as an extension, e.g. in an internal/RapidJSONResponse.h header or something, though. I'll need to think about how I can keep the ability to plug in a different JSON library, maybe even prototype a second one.

[gitmodimo]

I did proof of concept implementation in my fork.
Maybe the export of writeResponse should be dependent on buildtime option?

[wravery]

Keeping this open for now, I'm thinking of doing a v3.7.0 from the v3.x branch with any features I can backport from the pending v4.0.0 without breaking compatibility.

[wravery]

I backported the response::Writer change, but the support for returning std::shared_ptr<const response::Value> would have required splitting service::FieldResult into separate types for scalar types and service::Object sub-classes, or some new SFINAE template handling to handle both with service::FieldResult. It wasn't a clean backport.