[IMPLEMENTED] GraphQL Subscriptions

Feature Concepts
1

This is not really a concept yet.

More a question to my friendly users. Our GraphQL implementation is very complete now. One big piece that is missing is subscriptions:

But so far I have problems to understand use cases. Is this something that is relevant for you? Do you you have other feature requests for the GraphQL part of Squidex?

2

@Sebastian

Subscriptions typically are like pubsub models that create streaming of data usecases, typically an ability to subscribe to a feed of data. e.g. Squidex can enable new usecases like

  • proprietary twitter like feed applications powered just by using headless CMS,
  • gaming content feeds for frontend apps(think of like news-ticker like content) by just using headless CMS or
  • proprietary facebook news timeline like functionality for publishing houses to drive micro personalisation of content using appropriate “follow” or “like” signals given by a user

Live Queries in production using GraphQL Subscriptions

I am not sure if I have made the right comment, but just wanted to share my opinion on the same :slight_smile:

2 Likes
3

I could see some usefulness out of it, particularly for user generated content. We actually have a middleware layer that calls the Squidex GraphQL in a separate API and then caches. We could utilize something like this to extend the cache time, but also update the cache as soon as data is updated.

Overall though, probably not a top feature request we’d have. If I’m not mistaken (been a bit), we could probably do something like this with some built in Squidex features to catch a data update as well.

4

You can better do this with normal rules.

The problem with GraphQL subscriptions is that there is afaik no semantic for catch up subscriptions. The idea is, that you get data as long as you subscribed. So you might loose the changes when you make a restart or so.

For Squidex cloud CDN I use the event consumer system (which is the base for rules) to invalidate cache entries, when a content has been changed.

1 Like
5

I am working on this at the moment.

One of the main use cases would be a better editorial experience. You can subscribe in your frontend to content changes and then refresh the page or component whenever an update has happened.

1 Like
6

I have implemented subscriptions and merged them into the master branch.