MERN stack
In my app, you can follow users and when those users make a post, you should get a notification.
Currently, my User model has an array that lists all the users they're following as well as users who are following them:
users_you_follow: [ <object_ids>... ],
users_who_follow_you: [ <object_ids>... ]
My current idea looks something like this:
When a user makes a post in the frontend, we pass in the array of users_who_follow_you as well as the post details into the backend.
Then, using mongoose, parse the users_who_follow_you and find the users with the same ID's.
Finally, within that User model, I would store the post details along with some other metadata.
Then in the frontend, I would have a setInterval call to check if there are any new notifications.
This method although might work seems very server intense with all the API calls to check notifications. Is there a better way around this?
I currently don't know how to start on this process. From my research, some people said to use websockets while others say web workers.
What would be the best way to achieve something like this?
A very similar system to compare it to would be StackOverflows inbox thing. If a user comments on your post, the header/navbar shows a notification without having you to refresh your screen.
Thank you.
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.
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.
I am trying to retrieve nest thermostat schedules. However i get back the object which doesn't contain the thermostat schedules in it.
Is there an api that nest has which i can use to retrieve the thermostat schedules
As far as I know it is not possible to get the schedules. I think it is for security reasons.
But maybe it is possible.
For other persons it is better if you show some of the code and data. So we understand what you are doing. So like Holger Just said: "What kind of calls do you make, and what kind of data do you get back?"