Reading the AppSync documentation, it seems that AppSync Subscriptions only work by attaching a subscription to a mutation.
But what if I need a subscription that is independent of a mutation? That is fired on some internal state change? For example if a new resource is available?
Is that possible in AppSync?
This is not possible without mutations. I had the same problem months ago and my solution was to create a mutation with None Data Source just to trigger the subscription. This way every time an event was triggered, my Lambda calls the none mutation.
Related
Does anyone know what happens to existing cloud functions while a new version is being deployed? Is there going to be some (even if it is small) outage of service for our app while we deploy a new version of cloud functions?
This is particularly important for Firestore triggers where certain logic depends on a trigger to be run in response to some action in Firestore documents. An outage of cloud functions could leave the database in an unexpected state if some triggers where not run for a period of time.
Calls will keep being routes to the existing functions until the new version is deployed. At that point, new calls will be routed to the latest deployed version.
Since you seem concerned with data consistency, keep in mind that:
Background functions are invoked at least once. ... The system might, in rare circumstances, invoke a background function more than once in order to ensure delivery of the event.
From the Cloud Functions documentation on execution guarantees.
My flutter app allows users to schedule events and needs to notify them when the time comes. These events involve multiple users and may be deleted. I am looking for the best way to trigger the notifications.
So far, I have found 2 packages that may be able to achieve this: firebase_messaging and flutter_local_notifications.
With firebase_messaging, I thought of creating a cloud function that would be triggered when an event was created in firestore, which schedules another cloud function to be run during the event, checking whether the event still exists in firestore, and triggering notifications accordingly. However, I am unsure of whether it is possible to schedule a cloud function from within another.
With flutter_local_notifications, my issue is that user B may create events involving user A or the event may be deleted whilst user A's app remains terminated. As such, the scheduled notifications for user A have no way of being adjusted accordingly.
What do you think is the best approach?
If you need to involve multiple people , flutter local notifications isnt for you. It is not build for that.
When I append a new subscription in ORION, it automatically evaluates the condition and it invoques the designed end-point for that. I want that the new subscription affects only entities appended later.
Is there any way to avoid it or I have to control this at end-point level?
Related to this, is there any batch option to create several subscriptions at same time for a initial load of the platform?
Orion Version: 1.2.0
Regarding initial notification:
No, it isn't.
We understand that for some uses cases this is not convenient. However, behaving in the opossite way ruins another uses cases which need to know the "inicial state" before starting getting notifications corresponding to actual changes. The best solution to make everybody happy is to make this configurable, so each client can chose what it prefers. This feature is currently in our roadmap (see this issue in github.com).
While this gets implemented in Orion, in your case maybe a possible workaround is just ignore the first received nofitication belonging to a subscription (you can identify the subscription to which one notification belongs by the subscriptionId field in the notification payload). All the following notifications beloning to that subscription will correspond to actual changes.
Regarding batch option to create several subscriptions
No, there isn't any operation like that.
EDIT: the posibility of avoiding initial notification has been finally implemented at Orion. Details are at this section of the documentation. It is now in the master branch (so if you use fiware/orion:latest docker you will get it) and will be include in next Orion version (2.2.0).
In my setup I have one application that should subscribe to a specific kind of context change.
The application currently perform subscription at startup time. However if I restart the application, the subscription is duplicated. To overcome this issue I started to keep track of subscriptions in a database, so that I have an association between my application id and the latest subscription id.
Is there any way to achieve similar result in Orion (let's call it like "named subscriptions"), without using an external database?
There is a planned subscription "browsing" operation in Orion development roadmap (see operation ID 45 in this document) that could help in your case.
However, while this operation get implemented, one alternative to the one you mention (i.e. to keep subscription info in an external DB) would be to access to the Orion DB itself to get the subscription information. The datamodel (described here) is pretty simple and getting the info is quite easy if you are familiar with MongoDB. Note that this solution requires access to the Orion DB (i.e. it is feasible if you control your own instance of Orion).
EDIT: Given that different subscriptions may use the same reference, I'd recommend to use _id field to identify each subscription (_id field values are unique). NGSI doesn't include metadata in subscription, but you may associated subscription IDs with application using Orion itself, e.g. SubscriptionAssociation entities with two attributes, one for the application name and another for the subscription ID being associated
EDIT: since Orion 0.25.0, the GET /v2/subscriptions operation allows you to browse existing subscriptions.
According to http://cre8ivethought.com/blog/2009/11/12/cqrs--la-greg-young the component responsible for publishing events using an event publisher is the repository.
My question simply is: Why is that?
In this blog post we are told that:
The domain repository is responsible for publishing the events, this would normally be inside a single transaction together with storing the events in the event store.
I would have expected this as a task of the event store: Once an event (or multiple events) has been stored, it's published.
So why is it on the repository?
Your domain model is unaware of the storing mechanism. On the other hand it must make sure that the appropriate events will be published, no matter if you use an event store, a classical SQL store, or any other means of persistence.
If you rely on the event store to publish the events you'd have a tight coupling to the storage mechanism.
Storing and publishing the event must an atomic instruction because if one of both actions fails, the listeners of this event will be out of sync with the producer of the event.
There is a another (more expensive) solution, compared to publishing the event from the event store, which is to use 2pc transactions (two-phases commit).
you can find some more intereting information here: https://cqrs.wordpress.com/documents/building-event-storage/