We are using Elastic Beanstalk to serve a REST API. Now, I want to develop an endpoint that serves notifications from an SNS-topic in an asynchronous way.
In order to receive those notifications, I need to subscribe the API-servers to the SNS-topic. How could I do this, with the scenario in mind that the EBS application can scale up to multiple servers and scale down again? I don't want a lot of dead links subscribed to the SNS-topic...
In spring world we have a #PostConstruct which gets called on server startup, where you can subscribe "this.server" url to a given topic (you may need to build a proper working subscription url --using InetAddress et el).
Hence there is the working subscribe url using #RestController which confirms such an subscription instantaneously causes sns endpoint to be registered. Any new servers will do the same aka getting registered themselves (when new stack is created). We also need additional code for the consumption of notification messages subsequently and do something when confirmed subscription endpoints receive one.
The way AWS wants you to use SNS is not by directly subscribing to it. Any notification which need to trigger something in a component should buffer notifications with an SQS queue. For this reason we chose to do Pub-Sub with a variable/scalable group of Subs using the Amazon managed Redis distribution.
Related
I'm a newbie to DialogFlow and I don't event know if what I want to achieve is possible.
I'm trying to create a DialogFlow intent that would make an HTTP request from the user device after receiving a given command. I know how to do this with webhooks, but problem is that webhooks HTTP requests come from Google servers, and not the user device.
The reason why I want the request to come from user device is that the receiver will only listen to local network (it's a web server running in an internet router). So this will only work if the HTTP request comes from a device connected to the router.
A workaround could be to create a public tunnel to the router (with softs like ngrok), but my application aims at real users, so I would prefer to avoid this complex setup.
Is it possible to do local requests with DialogFlow? Or is there another Google-Assistant API I could use for this purpose, like Google IoT solution?
Thanks
You could do this, but you wouldn't necessarily do it like a regular Dialogflow project. Here are the steps:
Build your Action through Dialogflow and add web fulfillment
Add a way to push a notification of some sort to your local device
This could listening to a database, polling, push notifications, etc.
When your device gets that notification, it performs the action locally
If you want this local action response to be sent back, you could update the webhook through an HTTP response (if making an HTTP call) or updating a field in a cloud-based database.
Actions do have a timeout of around 5 seconds to get a response, so be aware of that limit if you want to do this
I have a Firestore database which I want to populate with data that is delivered by a live sports event API. This API offers to push the data, so I get new values every time some event happen in a selected game - so we don't have to pull new updates all the time.
However, the delivery method is a websocket which means, that we should open a web socket to a certain endpoint, and then we'll get the data updates.
How could we do this in Firebase? If it was just a simple webhook with an HTTP call, it would be easy to make a firebase functon that could receive the posted data.
But is it possible to do something similar with a web socket? I guess that keeping a Firebase Cloud Function running 24/7 with the web socket is not a good idea at all.
What you're describing is not supported by any Firebase products, and definitely not Cloud Functions. Cloud Functions doesn't support websockets at all, nor does it support any streaming. On top of that, the max lifetime of a function is 9 minutes.
If you absolutely need websockets, consider a different backend infrastructure instead, such as App Engine.
When attaching a topic to a SNS application's "Endpoint updated" configurable topic I'm experiencing some unexpected behavior. Per AWS's documentation on SNS Application Events, I should receive an event on my configured topic when a platform endpoint has been updated to disabled or it's token changed.
In my case I have a lambda function subscribed to this topic that then retrieves the platform endpoint's attributes via a call to AWS's javascript sdk SNS.getEndpointAttributes so that I can check what attribute have changed to either delete the endpoint or update the associated token in my persistent storage. This call however is returning the endpoints as Enabled = true which then prevents me from taking the corrective actions. However if I look in the AWS SNS console I can see the endpoint has been disabled as Enabled = false.
Have others experienced similar inconsistencies and if so what's the best practice to get around them? Thanks for any input!
I was also facing the similar problem when amazon notified me sns application events via http. To work around this problem i actually delayed the execution of code that sync these endpoint updates with my database. To achieve this i scheduled a job for my background queue worker and delayed its execution after 30 seconds from the time amazon notified via http. I don't know whether it is a best practice or not but it is working in my scenario.
In an interesting blogpost about 'Firebase Authentication with the Firebase 3.0 SDK and Auth0 Integration', it is stated that:
You can even have Firebase communicate with Webtask!
Now I can imagine the (web)client triggering a Firebase operation and subsequently a Webtask, but not the other way around. Or am I missing something?
Firebase can run as a serverless app, but it can also run on the server. You can even have Firebase communicate with Webtask! (sic!)
I think that paragraph is misleadingly phrased, perhaps it was just added at the last minute to spark interest. You can have a webtask communicate with Firebase, not the other way around. You don't "run Firebase" on your server either.
TL;DR: A client application may call a webtask with an HTTP request, and that task can read/write the database, but not in any other order.
Here's a quick and dirty reality check as of Nov. 2016:
The Realtime Database by itself does not provide you with a way of executing code. This includes responding to database changes and user requests, handling fan-in and fan-out operations, etc. There is no support for webhooks either.
Which means you have to provide your own execution environment for such logic on a custom server, or you can try to cram as much as possible into the client code. This is a pretty exhaustive topic by itself.
Webtasks are short-lived functions that respond to HTTP requests. Their lifecycle always starts with a request, so they are not fit for continuously watching the database for changes. But they are perfectly valid for handling requests coming in from your client application.
As you can store "secrets" for the webtasks, you can authenticate the task on an admin access level. This gives you the possibility to verify client tokens – which should be sent along with the request –; perform complex authorization and validation, and perform RTDB write operations you wouldn't trust the clients with.
Or trigger external services securely. The possibilities are close to endless.
I need to azure service bus to notify an end point (Rest - POST) whenever a message comes to a particular topic.
In AWS, it is done this way
AWS llink
What is the equivalent in Azure.
Note: I dont want to write code that will receive the message and then call the end point.
Azure Service Bus is a messaging service, not a Notifications service. As such, it deals solely with messaging, and doesn't create notifications for you.
AWS combines SQS (Simple Queuing Service) with SNS (Simple Notification Service) behind the scenes to allow you the functionality you're describing. This is to allow SQS to have a behaviour of events. Azure Service Bus has a native support for Topics and Subscriptions (if that's what you're looking for). I.e. rather than just sending messages to a queue, the message is sent to a topic and appropriate subscriber(s) will get it.
So the short answer to this question in case you don't want to receive the message and trigger a notification is "no".
Saying that, if you're OK with "serverless" functions (similar to AWS Lambdas), you could use Azure Functions to achieve this goal.
Looks like finally azure released Azure Event Grid which kinds of does this out of the box.. very similar to AWS SQS + AWS SNS combo
https://learn.microsoft.com/en-us/azure/event-grid/overview