I have a webhook designed in Node.js for API.ai that interacts with multiple API's to gather information and give response to user.
Since, I am interacting with multiple API's the response time taken is more than 5 secs which is causing the API.ai request to timeout.
To overcome this, I am trying to implement caching into the node.js webhook which saves the response from API's until a certain amount of time. This will remove timeout until the max-age header time is reached.
Edit: What is the best node module that I can use to cache the API responses for subsequest requests.
Note: I am using request node module for http requests but it doesnt seem to provide a way to cache the response.
All of the answers given are reasonable for tackling the cache problem on the request side. But since you specified API.AI and Actions, you might also be able to, or need to, store information while the conversation is in progress. You can do this using an API.AI context.
It may even be that if you limit it to just one remote call for each response from the user, you might be able to fit it in the timeframe.
For example, if you were having a conversation about movie times and ticket ordering, the conversation may go something like:
User: "I want to see a movie."
[You use an API to lookup the nearest theater, store the theater's location in a context and reply] "Your nearest theater is the Mall Megaplex. Are you interested in one there?"
User: "Sure"
[You now already have the theater, so you query for what it is playing with another API call and store it in a context] "There are seven different movies playing, including Star Wars and Jaws. Do those sound interesting?"
User: "No"
[You already have the data in the context, so you don't need another call.] "How about Rocky or..."
In this way you're making the same number of calls (generally), but storing the user's results in the session as you go as opposed to collecting all the information for the user, or all the possible results, and then narrowing them.
Finally decided to use the below module:
https://www.npmjs.com/package/memory-cache
This served my scenario better. Might try using Redis soon when i get some time.
Related
I am planning to create a mobile application for android and ios users, i think i will take a try with xamarin since i will be alone on this project and i don't have a lots of time.
I want that the mobile app for both platform get datas from the api, then if there is new datas available we notify the user by a notification.
How the mobile will work in that kind of project? I mean should i make a background service then check every x seconds/minutes by http request? In that case which time interval? Should i use websockets instead for this case?
The app might be used by many people, so i would to know the scenario in this kind of project: Getting very fast changes, without overload the server due to too many connects or whatever else.
I'm confused about this and i need some lights around, any mobile application/server experiences related would be apprecied!
EDIT:
As suggered by an user, here additional infos:
The api is homemade, restful using JWT made in NodeJS.
Each users on their device should get messages from server asap, even when the app is in background/closed.
Maybe in the future a way to send messages between users themselves.
You have to implement push notification.
It is quite easy to implement this in xamarin. just send the push notification to the device and on the notification received call back send the API request to retrieve the updated data.
Here is the document for sending push notification from custom API.
https://learn.microsoft.com/en-us/appcenter/push/pushapi
I'm not a mobile developer, so take this with a grain of salt.
The answer to this really depends on what you're doing, which informs how often to check the API. If it's a messaging app, for example, you could have it check every couple minutes to see if there are undelivered messages, then check more frequently for the next X minutes (to facilitate a conversation in real time).
If it's a GPS navigation app to be used while driving, you'd need much more frequent requests.
As for the API, that also depends on what type of API and the number of requests you can make to it. Is it a commercial API that you get x number of calls per hour on? Is it an API that you built? Etc.
Basically, you need to give more information in order to get more specific answers.
English is not my native language and i don't understand difference between query and request.
What is the difference between words and how to use them correctly on the web
Request means ask for something and it shall be given. You need that thing.
Query means ask whether or not something is true/ available or false/not available, you may not get that thing back but you'll get the status, state or info.
Request means ask to collect that object.
Query means ask to confirm the state of an object ex. Availability, true/false,
Can I have some food to eat? You are requesting for food.
Is that way good? This is a Query:
A request is like when I ask you to go to the supermarket. Here, I’m requesting you to leave your current place, go to the supermarket to bring one or many items and come back. Now, you can go to the supermarket but once you arrive you will ask yourself, what should I bring? In order to make your visit to the supermarket successful, I should give you a list of things that you need to bring or do at the supermarket, give you a description for the items and tell you in which aisle or department you can find them. This list now is representing your query.
So, if your client needs to fetch some data for example from a remote server, you will need to make a request. This request has a type, like ‘GET’ to fetch resources or data back, or ‘POST’ to do an operation like creating a new user account.
For the request to do its job, you have to specify what data or resources you need this request to fetch and where to find it. It’s like what items do you need to buy from the supermarket and from which aisle can you find them. For example, your request can have a query to return a specific user’s data based on his id. But you need to know to whom should you send the request with this query in order to get the user’s data back based on the passed id.
In order to make a request, you need to send it to your backend’s application that you can access using an IP or a domain mapped to it. Something like: “http://www.mywebsite.com”. But to fetch specific type of data, like the user’s data you need to tell your backend application what are you searching for. This is specified by something called the “path”. For example: “http://www.mywebsite.com/users”. The path here is the “/users” part. The query works when you submit to this domain with the path one or more query parameters, like the user’s id. So, you will make a GET request to “http://www.mywebsite.com/users/1234”, where “1234” here is representing the user’s id that you need to fetch its data. It’s like telling you to go to the supermarket named “mywebsite.com”, go to the “users” isle or department and grab the item with the id “1234”.
I hope that I managed to simplify the concepts a little bit for you.
Mohammed's answer above is great and very detailed. In summary:
First of all, query and request can both be nouns and verbs. E.g:
I requested a refund.
We received a request for a refund.
I queried the price.
We received a query about the price.
To request something is to ask for something, an object or a favour etc. A request is a polite demand. To query is to ask about something i.e. you are wanting information. A query is a question.
Also, QUERY is an inquiry(Query and inquiry are synonyms)
They are both requests but the difference is that the QUERY is a precise request. In informatics, if you need information about something you need to send a specific request with precise information.
"I queried information about user account Maxim Pavlov" = "I need to know about this website users. In particular, I need to know if there is any Maxim Pavlov registered on this site".
If you are Arabic, best translations in Arabic would be, request = طلب and query = إستعلام)
I thought about this question and I think the Ahmed's answer is misleading to say the least.
When web developers talk about request, they usually mean request done via HTTP. There are other protocols, but HTTP is certainly the most common. Request tend to be fourfold: get, post, put and delete. A request is almost always associated with an endpoint. A request is more than just ask for something. For instance, a put request is basically either add information or a file stored on a web server or update it. On the other hand, a query, in the language of a web developer, typically means some information he would like to extract from the database where a certain condition needs to be met.
I will give you an example. When building an API, you may have just two endpoints which are mapping to a post request and a get request. When you hit the endpoint associated with the get request, by design it will always return the "current time" which requires no query in a database. Meanwhile, when you hit the endpoint associated with the post request, by design it will always get the leap years between, say, 1900 and 2000 which are all stored in the database and requires a database query to fetch that information back to you.
The Abdullatif's answer is by and large correct though.
The Square documentation for updating webhook events shows this URL format: PUT /v1/{location_id}/webhooks. However, creating a webhook event listener for every merchant location could be a lot of separate API requests, and it would be far easier to use the merchant_id instead of the location_id (even though this is not documented) and make one request for each merchant.
Attempting to do this actually works - when I PUT /v1/{merchant_id}/webhooks the webhook is saved in Square and transactions for any of that merchant's locations successfully send the webhook.
My question is, since this is undocumented (although it works) is it safe to rely on this approach?
While it may work currently, since it's undocumented, the behavior may change in the future and cause unintended side-effects. I strongly encourage you to follow the current documentation for subscribing to webhooks.
My fulfillment needs to do a lot of processing after receiving a certain request from Google Action/API.AI and the default response timeout is 5s.
https://developers.google.com/actions/components/fulfillment#nodejs
Is there any way I could send a delayed response or send a POST request after the results are ready?
The short answer is no - you must respond within 5 seconds, and there is no way to send a notification back through the Assistant at this time.
The slightly longer answer is that we know notifications are coming - but we don't know if there will be an API for them. There have been rumors about other ways that may be coming that allow us to work around the 5 second limit.
The even longer answer is that, if you are using Action Transactions (ie - allowing the user to purchase or reserve something) you can send updates after the fact. However, Transactions are still in developer preview and don't work on all surfaces (they don't work on Google Home at all, for example).
The native application doesn't show all the activity, only the most recent.
Therefore I lose 70-90% of my notifications overnight. There must be a way to get all that historical data.
I told you can't, but, thinking.. you can. :)
The API don't provide that facility.. You can check all endpoints here: http://instagram.com/developer/endpoints/
But you can iterate over all your medias an get all comments and likes. If you store it locally, after, will be possible to request API again and check your new unseen interactions.
It will work for likes and comments.