Feature request (new System Handle): GraphQL integration

[fkromer]

Would be great if one could integrate via ROS2-Integration-Service and soss with GraphQL. What do you guys think? From a high level view it should be possible to integrate GraphQL Mutations/Queries <-> ROS2 parameter server, GraphQL client (Mutation) -> ROS2 service and ROS2 service client -> GraphQL server (Mutation).

[mxgrey]

Our stance on this is effectively the same as what I mentioned here, although based on a quick glance it looks like GraphQL might be considerably more tricky to adapt into soss than MQTT. I'm not saying that to discourage the idea or the effort, though.

[fkromer]

Same from our side here as well:

Sure. I've created this issue because we will probably be interested in cooperation (e.g. funding based source code contribution). However if we can do that is in clarification ATM.

[fkromer]

... although based on a quick glance it looks like GraphQL might be considerably more tricky to adapt into soss than MQTT.

@mxgrey I agree. I've some high level design ideas about this. Dependent on if development could be implemented in the open community context one should discuss on discourse.ros.org of course.

[fkromer]

According to your comment in another issue #31 (comment)

The REST model does not have a clearly generalized way to integrate with the pub/sub models that SOSS been targeting so far. It seems like a lot of semantic understanding of a REST API is required in order to weave it into a pub/sub system.

It seems like soss is suited primarily to map w.r.t. the pub/sub communication paradigm. Is it possible to integrate other systems via soss with ROS2 parameters and ROS2 service servers/clients at all?

[koonpeng]

Let me share some of the challenges in implementing a protocol like REST/graphql into soss.

Pub/Sub

Often, for protocols that does not have native pub/sub mechanisms it is possible to emulate it in some form, using http long polling in rest for example. However, you will most likely need to define some wrapping layers to support this emulation. In the case of rest for example, a strictly HTTP client will not understand the long polling mechanism that you employed, as such you will need a specialized client (and server) that supports such features. In the case of graphql, it might be the case that such an "extension" will not be supported by generic graphql clients and servers so it starts to be less of a graphql middleware and more of a "my custom protocol built upon graphql" middleware.

Data Types

Payloads for graphql are commonly JSON, JSON's type system is designed to be simple and that poses some problems when translating it to SOSS. For example, JSON has no binary types, no separation of signed/unsigned integers, differentiation between int and float, no fixed size int, no 16bit wstring, etc. On the other side of the spectrum, ROS2 does not have "null" type, heterogenous arrays etc.

Type System / Schema-less vs Schema-ful

JSON is dynamically typed, it doesn't use a schema to describe the format of the data, all information is available from the payload. In constrast, ROS2 is a schema-ful system, you need the types defined in .msg file and build the typesupport for it. This means that a JSON based middleware can send payloads with different format based on the context, a ROS2 middleware will not be able to understand those dynamic messages.

Encoding

As an example ROS2 only allows alpha numeric and underscores as the topic/service name, a hypothetical graphqlendpoint's "topic name" may be the url, which has a different set of restriction and has a spec which defines a way to encode normally unsupported characters. A graphql endpoint that uses encodings not supported by the other middleware will not be able to communicate with it.

Conclusion

All of these problems is combined with the fact that SOSS is designed to be a "specification-less", "N-to-N" bridge. That means that there is no way for a REST or graphql middleware to know what are the limitations of the other party and to know what kind of workarounds it needs to perform. There is also a "whose fault is it" problem, should the graphql middleware workaround ROS2's spec? Or should the ROS2 middleware workaround graphql? From the point of view of both middleware, they are both "SOSS compatible" as SOSS does not specify any requirements, but in practice, they can't communicate with each other because of all these incompatibilities.