[Discuss]: document an example of how PubSubEngine or a GraphbackCrudService can be used to achieve async / event bound tasks

[machi1990]

This builds on #1896 but can be documented separately.

With the crud Event emission mechanism we've in place, once can achieve so many event based operations e.g

If we take the Meter business model from an IOT world

""" 
@model
"""
type Meter {
  """
  @id
  """
  id: ID!
  address: String!
  latitude: String!
  longitude: String!
}

One usecase will be to send a notification once:

• a new meter is up ("created"),
• a meter is moved position "updated"
• or a meter goes down / removed "deleted".

On top of being able to subscribe to these changes via GraphQL subscriptions (on-call engineers would see these),
one would also like to perform other business related tasks e.g

• send an email to notify the admin or an on-call engineer (he might not be looking at the screen for the moment) etc etc

This can be achieved now by subscribing to the PubSub engine passed as an example but it requires one to have the knowledge of Graphback internals e.g

• topicName for each operation and type,
• the structure of the event/payload.

Code snippet:

interface Meter {
  id: number;
  address: string;
  latitude: string;
  longitude: string;
}

pubSubEngine.subscribe('CREATE_METER', (event: {
  newMeter: Meter
}) => {
  cons payload = event.newMeter
  // do business logic here after meter creation
})

pubSubEngine.subscribe('UPDATE_METER', (event: {
  updatedMeter: Meter
}) => {
  cons payload = event.updatedMeter
  // do business logic here after meter update
})

pubSubEngine.subscribe('DELETE_METER', (event: {
  deletedMeter: Meter
}) => {
  cons payload = event.deletedMeter
  // do business logic here after meter deletion
})

It will be useful to document the default topicName and especially the event structure things.

Optionally, we could provide a way to subscribe to these changes via the service.

services.Meter.subscribe('CREATE', (payload: Meter) => {
 // do business logic here
})

[machi1990]

/cc @craicoverflow, @wtrocki
Automatically generated comment to notify maintainers

[wtrocki]

If we move to streaming platform use case we will naturally diverge from topic being implementation detail and changing it being advanced feature (https://graphback.dev/docs/subscriptions/intro#changing-subscription-topics) to topic creation method being required for each model (or even schema based)

topicName for each operation and type

Solved by extracting topic creation process to template (this is hackend on datasync starter and will require changes in API (or completely different service probably)

the structure of the event/payload.

Solved by strongly typed Meter service

Optionally, we could provide a way to subscribe to these changes via the service.

For me that is not optional but natural requirement once we get into this phase.