We plan to have a REST API exposed by Apigee Edge. The client-facing endpoints will be managed by Apigee. Another REST service will be hosted behind the Apigee. When the Apigee endpoint is invoked, we plan to store the request in Kafka so that it can be processed asynchronously. After the server has processed it, we intend to Push a message to the client application that made the request.
Is this a common practice?
Does Apigee have a feature to remember the client such as its websocket so that the notification can be pushed?
First and foremost, Apigee is a Gateway for synchroneous APIs. There is no default way to do "come back" to a request that has been processed earlier. So: No, this is not common practice.
A more common practice would be to add an asynchroneous callout to "another REST service behind Apigee", meaning that Apigee returns a response immediately without waiting for the target to complete. That backend service would then implement the callback on its own, possibly via some other Apigee proxy.
In your specific case, the pattern you're implementing is basically a message queue, utilizing Kafka as the message broker. In such patterns, it's best practice to have the message receiver send a reply message as soon as it finished its work.
Regarding websockets, Apigee doesn't support it at the moment (see https://community.apigee.com/questions/60513/apigee-as-websocket-proxy.html).
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 want to send message from Amazon Simple Notification Service(SNS) to the http endpoint. There is no proper solid documentation on how to do that. Though I had read Amazon SNS documentation still I could not get entire picture.
Can anyone give me simple example on how Amazon SNS and http endpoint work together?
There good documentation for what you asking: http://docs.aws.amazon.com/sns/latest/dg/sns-dg.pdf
Look at the page #147, it describes what steps you need to do for sending messages to HTTP(s) endpoint.
Also check this example which describes how to create topic, subscribe endpoint, confirm subscription and start to receive notification messages from SNS (uses Java SDK): https://github.com/mfine/AmazonSNSExample
General picture is:
On the publisher side:
create topic and subscribe some endpoint to receive messages. After subscribing endpoint to topic, the endpoint will receive SubscriptionConfirmation message.
start publish to topic so your endpoints will receive notification messages
On the subscriber side (your endpoint should be able to handle at least confirm subscription request and notification messages):
confirm subscription: make HTTP GET request to the "SubscribeURL" URL which comes inside the body of the confirm subscription request. Before you confirm subscription your endpoint will not receive any messages from SNS
receive notification messages and do what you want
I have a couple of questions on Firebase. I went through their documentation on their site, and the tutorial. I've never used anything like this before, so it's a bit confusing:
I see there is a REST API and a Javascript API. Is the main difference that the REST API is more like a traditional API and requires polling, whereas the Javascript API allows you to receive deltas from Firebase itself?
I want to create a service that receives these deltas and stores them in my own database. But I don't understand how Firebase can keep a connection open for so long. I'm assuming there must be a connection open that Firebase pushes the data through back to my service. Is there a time limit? Or if the connection gets closed is the best practice to detect this error and re-login?
There are many differences between the Firebase REST API and its client libraries. The biggest difference is indeed that most REST clients don't use a persistent connection. But REST clients can listen for changes too, using Firebase's SSE based REST Streaming.
Firebase uses web sockets to establish a persistent connection from the client to the server. On browser platforms where web sockets are not available, the client falls back to HTTP long-polling.
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.
We're running an ASP.net MVC4.5 web app, and we have this api end point that does the following:
Send Email using SendGrid (normal sync code)
Send Notification using Azure Notification Services (normal sync code)
Trigger another endpoint in a 3rd party soap service (we're using azure storage queues here and a workrole, because the 3rd party endpoint is unpredictable and i might need to retry the call)
My question is, would it be an overkill to use azure storage queues for (1) and (2), I'm having second thoughts because, SendGrid for example, when sending an email using their SDK, I suspect that the email sending action happens instantaneously when im calling their email send endpoint, they are probably using some sort of queues as well and polling from it to send the messages.
This goes for the notification hubs for example, the message is added to their queues as well, so would it make sense to implement azure queues for those?