manage api calls when using vuex - vue.js

I am currently working on an asset manager for network/server infrastructure in vue.js.
I am also using vuetify for the look and feel since the goal is to create a progressive web app. Engineers can use their phone to scan tags on company assets to request details.
Currently all data is loaded into the app using a rest api. I am using vuex for state management in the application.
I would like some insights in to when to launch these api requests.
So there is some data i currently load at the start of the web app just after logging in when the main core view is loaded. This is impacting performance. Some examples of loaded data:
-> asset types,vendors,suppliers,...
This data is used in a lot of places in the application. (forms,filters,...)
I prefer not to call the vuex actions to perform the api request form inside a specific component since this could lead to unnecessary request when browsing the app.
The only exception to this being the assets them self since this is a lot of data to load at the start.
The problem i am facing is that on mobile platforms loading the data each time at the start of the app is a waste of data connection. It is possible that the engineer is using the app without actually needing the data.
I know this is kind of an abstract question, i am not looking for the one final awnser. Just some insight or recommendations from the community.


Correct me if I misunderstood but it sounds like you are prefetching a lot of non critical information all at start up. You should really focus on when that data is actually needed and reach out and retrieve it only when its actually needed. A common case of this is on route change, so if you have multiple pages within your app an admin page is likely going to need data that your home screen doesn't need. Wait until you navigate to that page before you retrieve information specific to that page. This is commonly done within the beforeRouteEnter router hook or created life cycle hook. Now to build on this, it may take some time to download that new data after a route change - the page could render before all of its necessary data has been made available. You can use a library like Vue-Promised to handle that intermediate state for sections that require data that is still loading. This allows you to let the page render quickly without having to wait on all of its data.
A couple other tips to further optimize things:
If you data that doesn't change often, sometimes it doesn't hurt to persist that data within the browser, either using the Cache-Control http header when making your http calls or by using something like the browsers LocalStorage or one of the hard persistence methods available within the browser. Theres a number of Vuex plugins that make this really easy, ex. vuex-persist. On startup you can load this data from storage which is faster than making a network call, your app will be able to respond faster and you can even go and make that network request in the background to refresh that data after the page has rendered.
If retrieving large sets of data is an issue then you can page the data to retrieve it in smaller chunks and only retrieve additional "pages" fo data when the user needs it. In tables this is commonly done using pagination buttons or infinite scrolling. Theres a number of libraries that do both of these as well, pagination would likely be built into the vuetify libraries table component.

Related

How to access private data in Nuxt?

So I have my nuxt 2 app where I want to fetch company reviews from an API on a single page. The API does not allow requests from the browser/client so I need to use a server for this call.
So I was using asyncData() with if (process.server) but now I have the issue that the data is only being fetched on the initial page load of the specific page. So if I switch routes in my app to the page where the review data is loaded, I am getting an error, since the review data can only be loaded server side.
I think I have a little comprehension issue here on how to solve this issue. Is there a best practice on how I should fetch my review data in order to access it on this specific page even if this page was not loaded initially?
I am using static site generation for my nuxt app.

If you can have all of the data set at build time (full static mode), you could get it without any extra step.
Here, I guess that this is dynamic and you need more flexibility. So, there is no magic sauce here: you cannot have a server-side call made on each client-side navigation (like SSR Next.js does). Nuxt will stay isomorphic and be client-side only after the initial render (done on the server).
You could have a serverMiddleware into your Nuxt2 app but it's pretty tricky overall and not really worth the effort IMO: https://stackoverflow.com/a/72102209/8816585
(quite easier with Nuxt3)
Solution: use an external server middleware (could be an edge/serverless function) to fetch the private data and send it back to Nuxt.

Optimise a heavy response on the client side

"What would you do in order to optimise a request with a heavyweight response of 10mb only on client side?"
I would like to state that this question was available on glassdoor.
It got me interested in knowing the solution.

I think I know from where you found this question:), anyway below is the answer of your question(as per my understanding).
If you are getting heaving data from backend then first you need to improve your code at backend side so that you will get the data is lesser time, If you can't improve the code/performance at backend side then you can use any of the below technique at frontend side -
Make your application PWA(Progressive Web Application): Here the person(Interviewer) specifically wanted to know whether you have understanding about PWA or not, now a days people are making their application PWA, so that they can increase the load time of their application, reuse the same code/files like common css & js files, common images etc in their application and people can access their application in slow bandwidth as well.
Use Lazy Loading: When user required the data then load it only (For example Medium websites you can check)
Minification your application
Use Hex code icons or Fontawesome rather then to use images for icons also you can use image compressor plugin as well

Packing all dynamic data into a single Vuex store

I'm working on a web application which consists of various pages that rely on ajax calls (via AXIOS) for either fetching data from the server or communicating data back to the server. However, the data that is fetched from the server is 99% of times intact during the lifecycle of a session meaning that it will not be changed (i.e. only displayed to user while involving very low update frequency). Moreover, this data, is just pure text including links to contents, formatted as a JSON Object.
I have just found about Vuex, and I have been thinking about packing all these get Ajax requests scattered across different components and centralize them in a Vuex Store in a way that, when the application loads, all required data would be fetched from the server so that no more communication with the server to get such data during the lifecycle of the session would be needed (while only getting the contents such as images, audio, etc via links).
Is Vuex appropriate for this purpose? Is this a good idea at all (based on the concept of speeding up navigations)?

As mentioned in the comments, Vuex is meant to manage complexity and in your case you are planning to fetch 99% of the data at the beginning for your app. So, in client-server aspect, you totally don't need it. Keeping your data structured would be enough.
However, you have also the notion mutation in Vuex. The idea is that you can update the core data only using mutations. In this way, you are protected from unwanted changes and you have a better insight how/in which order your data is changing. So, if you have complex operations on your data (fetched from server and also your apps logic), Vuex would be a good choice.
There are also another interesting features for different kind of apps. Note that is just another trending way to keep your data structured. There are also another strategies but since Vuex is regularly maintained by Vue core team (and it seems to be also in the future), I would suggest it. Especially, if your app keep growing, you will love it more and more. After reading core concepts of Vuex (or better its logic behind Vuex: FLUX), you will have better insight about it.

How inspectlet and other services store user video sessions?

I was wondering how the services like http://www.inspectlet.com/ does store the video sessions. By the looks I don't think it's a webRTC implementation. What i was able to figure out that there is active express socket which is making communication but in that case they will have to store the page and track all the events from DOM. Just wanted to confirm that this is the approach they are following.

Looking at the event listeners on the page, it looks like there are a lot of bindings. For example, the <body> has scroll, keyup, and change events bound to a function. I'm sure it also has mousemove, mouseclick, etc. All of this is likely stored in a Javascript variable (object, probably) and then AJAXed every so often to http://hn.inspectlet.com/adddata with the data parameters. Here is a sample of what is being sent:
http://hn.inspectlet.com/adddata?d=mr,212941,46,337,46,1277)mr,213248,163,498,163,1438)mr,213560,144,567,144,1507)mr,213873,138,240,138,1180)mr,214188,169,184,169,1124)mr,214504,158,520,158,1460)mr,214816,231,487,231,1427)mr,215130,329,197,329,1137)mr,215444,894,289,894,1229)mr,215755,903,295,903,735)s,215755,440,0)&w=259769975&r=494850609&sd=1707&sid=1660474937&pad=3&dn=dn&fadd=false&oid=99731212&lpt=212629

As suggested in Adam's answer, they track many events in the page and send them either via a websocket or post/get request (XHR) to their servers.
I am not sure what inspectlet does specifically, but in general, such a solution will need to follow the below general steps:
When the page is fully loaded (hook on DOMContentLoaded probably) they will send the page data to the server. Then they also hook on MutationObserver in order to track all changes to the DOM in the page, so when something changes dynamically, the tracking script can 'record' it and send it to the server.
The SaaS application in turn, will have a player that will parse all this raw data and then play it back, this will usually require using some virtual file system for assests (images, css, scripts) and handling js scripts to not post back again (replay xhr will have bad results for tracked websites) but play back the mutations as they were captured (recorded)
In regards of data HTML pages compress really well, especially when you can make assumptions about the data (since you know its html) - so yes, they actually cache a lot (similar to what google does in that regards, but google does it for the entire web, not just 'customers')
The DOM Mutations will need to be stored as well. This is up to the algorithm, it can either be stored as plain text or using a smarter data model, storing them in plain text is obviously not the cost effective solution.
The above is an abstraction, there are many edge cases to handle in order to implement such a solution as well as a lot of mathematical and algorithmic thinking in regards of heatmaps to make them accurate.

So after a long search was able to find a new promising solution on the block, which solves all the complex parts in building such service. It is still under development but it solves the problem. Below is the link to it,
https://www.rrweb.io/
https://github.com/rrweb-io/rrweb

Mvc 4 single page application view navigation to different sections of site

I'm embarking in my first spa mvc 4 app and I've watched the Steve Sanderson talk which was great but his final delivery tracker app ends up with 3 views that are all declared in the same view page. This is fine for a small app but how do you manage this on a larger scale when you have different sections of the site that have different data. The site I want to build needs to remain on a single page because I want to keep a chat window open similar to the Facebook style chat and i am going to be using SignalR to push data to the client in fixed sections within the app. Do I just use the #Ajax.actions to load up completely different sections of my site much as I would if I was just creating a non spa site? The plan is to keep the user in a specific section of the I site for a majority of the time, but I will want settings pages and user profile management pages that are defined in separate views.
Any good sample code would be greatly appreciated I'm planning to just use the bog standard spa with knockout and nav.js unless someone can suggest a more mature spa technology for mvc/entity framework that's got some good documentation and is popular.

What I do is poor mans SPA, which is basically make my site like a standard ASP.NET MVC app so I have multiple views, multiple controllers and actions and I have a shell page with a container div which I use as the container for the whole site to load my views into with Ajax calls, so I have lots and lots of jQuery ajax calls, I've somewhat tried to refactor my client side JS and make a generic navigate to Javascript method (among other things) in my shell page, which I then invoke from the child views, so a click on a certain ActionLink in a particular child view and I would call my generic JS page loader:
GoToPage(controller, action, query)
which will use jQuery Ajax to lad the destination controller/action/view into the container div in shell.cshtml. For navigation I use Ben Alman's hashchange plugin to detect hash change events and load the appropriate views into my container div. There are obvious downsides to this approach as you're rally not building a real SPA, you're making a server side app with a SPA facade, and actually the performance difference between this and a proper spa which only gets data from the server (not HTML) is slightly noticeable, however if you're a traditional ASP.NET MVC developer this saves you from having to take up new libraries like Sammy.js and knockout etc. The biggest downside of this is that you'll be writing a lot of repetitive wiring javascript which can quickly become a tangled mess, especially if you have a lot of forms. Though you can take certain steps to re-factor and reuse common code. So in summary generating views server side and retrieving them with Ajax probably isn't the most optimal SPA solution, but for me it had the least learning curve (none actually lol). I've recently been looking at Durandal and I think it finally provides a very viable solution to creating SPAs, I specially like how unlike Sammy.js you don't have to load all views on the initial page load, even if the user isn't going to visit those pages. A nice getting started tutorial is provided here.