Querying/Mutating Linked Data with GraphQL

As previously mentioned I was interested in porting GraphQL to work with linked data. I forked the graphql javascript implementation and added rules to the parser to work with namespace prefixes. The working title is webql.

It completes namespace prefixes by using the namespaces in solid-namespace + additional namespaces that can be declared in a json file similar to how they’re declared in solid-namespace; the path to this file needs to be set in CUSTOM_NAMESPACES_PATH

The client that helps to load and patch linked data resources and makes them consumable by GraphQL is at webql-client

Apart from the changes made to the graphql vanilla implementation, i also forked (webql-nexus-schema) graphql-nexus-schema for an easier way to declare graphql schemas; it now also account for the namespace prefixes in the schema.

And if you are now curious how this can be used i built a small profile editor that exemplifies the functionalities: https://webql-demo.owntech.de (Source)

You can see in src/api/objects/person how a file structure can look like and how it can be used to declare types, mutations and queries. I also have some useful helpers in src/api/schema.ts that use react-query to transform operations into react hooks. In src/components/Profile.tsx you can see these operations in action.

As I am just finishing this in time for my uni exams I didn’t get to properly document it, but that will follow. So for now it is unfortunately all over the place :confused: However typescript should expose most of the api’s so if you are already somewhat familiar with graphql and you want to try it out, you already can. I also plan to implement graphql-codegen to work with the webql types, queries & mutations, to make it an even better developer experience.

Any feedback, opinions or issues are as always highly appreciated :confetti_ball::slight_smile:


You might be interested in the work that’s being done on GraphQL-LD by @rubensworks, @RubenVerborgh, and Miel Vander Sande.

@megoth yeah i already checked it out and while I respect their approach I think we are not really working with the same goal in mind. Porting graphql to work with ld resources was mainly about making front-end devs have an easier time when it comes to structuring and maintaining a data schema, queries and mutations, like they have done for “regular” front-end apps where they might have used something like the apollo or the prisma client.
It is not so much about enabling devs to do complex, rule-based sparql queries like it might be needed for a scientific endeavor, but more about building schemas that are reusable and doing simple queries that you expect to be typesafe for a production grade application.
I’m not an expert in GraphQL, but to me it seems like a “backwards-compatible” (it isn’t 100%) is the best approach if you want some compatibility with existing tools.
I can say from experience that a well maintained graphql schema is extremely helpful when adding features to an app and in the team that I am currently working in, it saves us a lot of nerves.


Excuse me if i drifted away a bit there, that opinion wasn’t directed at you i just wanted to elaborate on why i am not using graphql-ld. And i think it’s a great effort just not exactly what i was looking for. Thank you for reaching out :slight_smile:

1 Like