What is the recommended method of getting CategoryIds. I understand Foursquare provides this list: https://developer.foursquare.com/categorytree. My question is should I just use this list and hard-code the values or fetch the Ids on first opening of the app and caching these results?
From the venues/categories API documentation:
When designing client applications, please download this list only once per session, but also avoid caching this data for longer than a week to avoid stale information.
So fetch on app launch and cache for the current session to insure the hierarchy is always up-to-date.
Related
I am integrating elastic search with my Nest application. positing my workflow and question below.
flow:
front-end updating one entity, so in back-end updates the primary storage MYSQL and cache storage elastic search.
Immediately front-end hit the get request to get the updated entity, so the back-end fetches the entity from elastic-search and sends a response to the front-end.
Now the issue is sometimes elastic search giving not updated data due to index not refreshed.
Solutions:
We can use the refresh:'wait-for' config in the update API.
We can trigger the refresh API to refresh the indices
The question is, after the update API, if we trigger the refresh API without waiting for the result. in meantime, if the front-end requested the data what will happen, the elastic search will wait for the refresh indices operation completion or will it serve old data?
As you already know Elasticsearch provides near real time searches, and if you are making a search call, as soon as document is indexed to Elasticsearch, it will not be available unless refresh happened on the index.
Now, As you mentioned, you can solve the issue by using the wait_for with your index/update operation, only downside is that its resource intensive and if you do it frequently on a large index, it can cause severe performance issues in your cluster.
Your second option will not work, as you can still query the Elasticsearch from FE before refresh finishes and you will get obsolete data.
I am creating a Nodejs app that consumes APIs of multiple servers in a sequential manner as the next request depends on results from previous requests.
For instance, user registration is done at our platform in PostgreSQL database. User feeds, chats, posts are stored at getStream servers. User roles and permissions are managed through CMS. If in a page we want to display a list of user followers with some buttons as per the user permissions then first I need to find list of my current user's followers from getStream then enrich them with my PostgreSQL DB then fetch their permissions from CMS. Since one request has to wait for another it takes long time to give response.
I need to serve all that data in a certain format. I have used Promise.all() where requests were not depending on each other.
I thought of a way to store pre-processed data that is ready to be served but I am not sure how to do that. What is the best way to solve this problem?
sequential manner as the next request depends on results from previous requests
you could try using async/await so that each request will run in a sequential manner.
As the title suggest. I'm trying to figure out where I should cache data in my node.js application.
I'm using a express.js and controllers to handle the routes in the application. The controller for a particular route will get data via the model layer using REST API and then it uses handlebars for the view rendering on the server.
For this particular route, I'm displaying a menu and the data I have got for this has been done in the model and a remote REST call.
When the user select different items in the menu, I do not want to make a new REST call to get the same data for the menu again, I just need to get the data for this menu once since it will never change.
I need to find out a way to cache it, but do not know where I should implement it?
Best Regards
You could just cache the response from the REST API or DB lookup using a memory-store like Redis or Memcached, both have good modules available on npm - (Redis, memcached).
You would need to attempt to fetch the data from the memory-store (in your controller), if no matching data was found, you would make the request to the API or database to get the data, and then store it in your chosen memory-store so future requests will hit the cache.
note: There are also some pure JavaScript caches available such as memory-cache or lru-cache if you don't want to add an additional application.
I am working on an iPhone app which allows users to search Foursquare. I am using the venues/explore endpoint for the search which works great, but the results don't include the images for a place or the priceTier.
Right now I am calling /venues/VENUE_ID for each of the returned results, which is generating a lot of API calls. Is there a better way to get this info in a single call?
Related question: If I use the multi endpoint to batch these requests, does that count as a single request towards the limit or as multiple requests?
Sounds like you're worried about limits more than network latency? If you're worried that making the extra call to details will make you hit rate limits faster, this is actually why we generally ask developers to cache details such as prices or photos :) A single multi request is not a single API call; it counts as how many requests are bundled into one.
There is a little help with photos though—if you pass in the venuePhotos=1 param as part of an explore request, you ought to get back photos in the response.
I want to use the spotify api to create a webapp. Without going into too much detail about the project, I want to clear up whether it would be against the terms and conditions or not.
After reading the terms and conditions, i read this line under things NOT to do: "aggregate Metadata to create data bases, or any other compilations of Metadata".
I don't plan to do any automated requests, for example, hammering the service with different queries to build a database... I'm just wondering whether I can store results from users who have performed searches via my application to the api, so that I can build content from my database on other parts of the application.
Thanks
I'm not a lawyer, so you'll need to have a lawyer confirm this (contracts, including ToS contracts, are important), but the general gist is that if you cache the results of user-generated requests to create features then you're ok. If you start caching stuff not generated by a user, you're in muddy water.
Good:
Other users who searched for "Madonna" in MyAwesomeApp also searched for "Backstreet Boys"!
Bad:
Here's a list of all the blue cover arts on Spotify: [list]
To generate the first example you can cache and work with searches explicitly done by users of your application. The second would require scraping all of the coverart in the service, which isn't allowed.