Within my app there are multiple pages that display a drop down of "clients". The select options are loading via an GET call made in Axios. Every time a page is displayed it makes that get call.
I'm curious if it's better to store those clients in Vuex, and then just load them that way so I don't make a call every time? The only thing I am concerned about is when a new "client" is added the best way to tell the app it needs to make a new get call to update the data in Vuex.
There are many possible solutions to this.
You could use a cache in back-end suchlike Redis, or as you said, cache it in the front-end.
You can abstract this caching with a get function which will check a maximum threshold of cache age.
For example, you can set it to last for 15 minutes. If another request is made before it you could answer with the last obtained data, else it will request the data to the server again.
Related
I'm designing a website with a REST API using Django Rest Framework and Vue for the front end and I'm trying to work out what the proper way to do filtering is.
As far as I can see, I can either:-
a) Allow filtering via the API by using URL parameters like /?foo=bar
or
b) Do all the filtering on the Vue side by only displaying the items that are returned that have foo=bar
Are there any strong reasons for doing one over the other?
The real answer to this question is "it depends".
Here are a few questions to ask yourself to help determine what the best approach is:
How much data will be returned if I don't filter at the API level?
If you're returning just a few records, there won't be a noticeable performance hit when the query runs. If you're returning thousands, you'll likely want to consider server side querying/paging.
If you're building an application where the amount of data will grow over time, it's best to build the server side querying from the get-go.
What do I want the front-end experience to be like?
For API calls that return small amounts of data, the user experience will be much more responsive if you return all records up front and do client-side filtering. That way if users change filters or click through paged data, the UI can update almost instantaneously.
Will any other applications be consuming my API?
If you plan to build other apps that consume the API, you may want to build the filtering at the API level so you don't need to recreate front-end filtering logic in every consuming application.
Hopefully these questions can help guide you to the best answer for your use case.
Whenever I come across this issue I ask myself just one question: How many items are you working with? If you're only returning a few items from the API you can easily do the filtering on the front-end side and save yourself a bunch of requests whenever the results are filtered. Also, if the result set is quite small, it's a lot faster to do it this way rather than sending off a request every time the filters change.
However, if you're working with a very large number of items, it's probably best to just filter them out in the API, or even via your database query if that's what you're working with. This will save you from returning a large number of results to the front-end. Also, filtering large numbers of items on the front-end can significantly impact performance since it usually involves looping over a collection.
I have an app and its going to have these features in it :
SCREENS :
Home { Show recent posts from all categories (API provides 30 posts per page)}
Categories {Show all Categories List }
By-Category {Show recent posts by category (API provides 30 posts per page)}
Post {Show Post Details with Comments }
User-Profile {Show User Profile with their recent posts (API provides 30 posts per page)}
Profile-Setting {Show updatable Fields and Update Button}
Now, Where i am confused :
Should I fill the whole store with API in the starting or should I
make API calls for each screen when they are opened ?
And for updating, like If user likes post then should I show a
spinner or something till API completes OR should I update the local
store value instantly and then call the API ?
There could be many approaches to solve this. mine is:
1) I would create a model/manager to handle the API requests that also have access to the same store. so for example when the screen did mount use Home.Manager.getNextPage(); and it will know already to handle the api request and also know how to handle the paging.
So all the calcs will be in the manager. and when it get the data it will update the store with it.
2) When I built an app that contained likes I have used local data as well. My approach was to set time out of 10 seconds from last like so in case the user liked more than one post I could send a bulk. so the server won't need to handle multiple tcp connection but one with multiple likes data.
The point was first store it locally(for incase the user kill the app before we update the server) and then wait for 10 s' if got new like add it to the data array and wait for another 10 s' if not just send the data to the server. do not clean this local data until server return that it saved on your db
This way you can display animation first without letting the user to wait for a feedback from the server..
The best practice is to make small API calls for each component.
You should load each screen with a loading, then call the API in
componentDidMount after receiving the response shows the data.
enter code here
For this kind of action, first, make the API call, make the like button disable, update the store after successful API call.
Disable the button because of some user double-tap. This kink of APIs is usually fast, so loading does not have a good UX. The loading will be removed before full animation. Always update store data on the response, not the request because you need to revert the store changes if the API calls failed.
Lets say we have a set of items, that is thousands of entries long.
It would not be practical to load all of them on page-load and have it in the store. How exactly would you deal with this?
Would you just add items to the store, that are actually requested?
What is the best practice here, if an item is not yet in the local store?
Lets say you are 'requesting' an item that is not yet in the local store (but would be available from the api), would you automatically try to retrieve it from the api before returning empty/an error?
Is there any best practice on how to implement this? It seems to be a pretty common use case.
Our should you just try to always load the whole data-set (or at least a minimal version) of it?
Also: what if the items change all the time (other users). Is there even a point in having those items in the store locally, if you need to request it again everytime you want to see its details to not get an outdated version?
Thanks
I have 50K+ records in my db,I want to add search filter without affecting performance of the application .Please suggest me what approach I should adopt to search the large data.
I am calling api to fetch data from server. And used react native search functionality. But due to large data i have implemented pagination at server side so each time new api being called and new data fetched from server. Now issue is it will search only from fetched page records and i want to search from all 50K+ records. And i want to search for each character typed. So I think it is not fissible to call api at each character typed.
So what is the best approch?
I have a quote finder app which holds 400k quotes on mongodb and I am using Node JS as backend. In my point of view if you are going to search more than 100 items in your front end lets say you are going to use flatlist you can create your searching algoritms in front-end side, than you can dynamically render your list according to search results. 100 items are not a specific limit it is just my idea. Because in lists more data than that would look ugly.
For 50k search you definitely have to come up with search algorithms on server-side. After you get your search data you can use
https://github.com/UnPourTous/react-native-search-list
And if your specific aim is to search on server-side I would recommend elastic-search.
But for 50k data it is better you implement your own algoritms. When you send fetch request let your server run the search and in response get the data you want.
You can use redux for this situation. When you start your application get all records(50+K) from server it will take time(You can get records in splashscreen) based on your server and store all records in redux store. Now you can search data from your redux store so don't need to call API on every search.
Make sure your server send only those data in response which you required to show in mobile application. So for getting records it will reduce response time.
You can use redux-search for this.
I want to make a REST API that does spellchecking on text that is passed in, without storing any of the text on the server.
The call would probably look something like `example.com/api/v1/spelling/mistakes', with optional query param for locale and an list of the mistakes as return value.
What would be the best HTTP method to use, given that the text passed in would be too large for a GET. Neither POST, PUT nor PATCH seem to reasonably map to the intended purpose and there don't seem to be any other suitable matches in the less commonly used methods either.
What is the best HTTP method to use for a "translation"-like REST API service, taking and returning large amounts of data?
I would say this is a POST. But it could have been a GET if the data was previously posted. The reason it is not a GET is because you are passing all the data in this API call, as you mentioned. For example, if the data was 'posted' somewhere else previously, then the GET can be used where the address (URI) of the location, or ID, of that 'posted' data is passed to the API as a param in the GET. But because we are both 'posting' the data and retrieving information about that in the same call, I would say then that this is a POST. Grant it the data being posted has a short life span, it is still being posted. If the data being posted was instead a customer order, then it would still be a POST but the data would be persisted somewhere. The difference here is the the short period of time that the data will exist for. And in future iterations of your API, you might actually want to keep that data and refer back to it with some ID. So by using POST you allow for future enhancements also.
By the way, as a precaution, be careful with the memory footprint of these calls. I can see this as being very memory intensive if the data being passed grows large and the API becomes very popular. Not a show stopped but something to consider when designing it.
Hope that helps alleviate what I call REST anxiety when designing an API.