I've just started working on the financial web app which was implemented a few years ago in AngularJS with .NET API as a backend. The app contains a number forms collecting data from the user, then recalculating the result after each change and displaying the results on the screen. This has to happen without clicking the save button. At the moment the data is one large object which is sent to the API after each field change and once the save is completed it runs 3 requests to get the new calculations. I'm trying to optimize it and improve performance and I was wondering if there is any standard/best practice for this kind of systems?
Related
how can I add an auto-update my code in a flutter? I am creating an app to check the market rate or wholesale rate of chicken, mutton, and seafood (all Alive) so I don't want to waste my time on copy-pasting the price every day. I want something that extracts data from a website and inserts it to my flutter app. that changes the price in all as thee prie on website changes. I also want to upload it to the play store.
Use an API to extract the data from whatever website you like and you can either set a timer which at regular intervals checks if the price has changed and updates if necessary or using an API will reload prices when the app is closed and opened again anyway.
So i am working on a IoT SaaS project in React.
The user selects a sensor and a time range and receives data visualized in charts with a resolution about 5 minutes.
My question is regarding best practices when handling fetching and saving of this data on the front-end.
I have tried always fetching which works fine, but makes the system kind of slow.
This is especially true while users are quickly switching back and forth between sensors.
I have also tried saving the data, just as a json in the react state.
This significantly increase performance, but has a lot of other problems.
The browser starts complaining about ram uses and can sometimes get out of memory errors.
There is also a lot of needed data handling as saving several non continuous data-ranges for the same sensor, locating and merging date-range overlaps etc...
So i am wondering what is the best practice here, should i always fetch or save on front-end? are there any frameworks i could use helping me with the data handling front-end or do i have to do this manually.
Saving all data in front end is an antipattern. Because of memory and out-of-sync issues. To make your system work seemingly faster and use backend data you can try following:
Optimistic response. This technique uses some simplified parts of backend logic in front end, while doing actual request. So user will see result before backend data reaches browser. Lets say you are doing +1 operation on backend. User sends number 2 to perform this operation. So in your front end you can use something const optimisticResponse = (userData) => userData + 1. And then when you get data from backend you can overwrite value, of needed
GraphQL allows you reduce overhead by asking backend only for data you need.
I have a form that is four pages. The user clicks next and this leads them to the next page of the form. On the fourth page the form is complete.
What is the best practice?
Do I do a POST after each page, so 4 different times, or should I do one big POST on the last and final page pushing all the user data to the database?
Each page posts to a different endpoint.
My form is created using redux-form and react.
Either works, the main advantages I see are:
Sending one complete form - advantages:
No database pollution
Less network overhead
Sending 4 partial forms - advantages:
You can see where each user stopped - this may be useful data if they
are purchasing a service or signing up for an account. Do a lot of
people fill out the first two sections only to see the third and
navigate away?
You can use this to save the form server-side for people to complete
later. You can also do this with Redux / Local Storage for session /
browser storage, but you may want the functionality of a user
starting a form on one device and completing it on another, requiring
server-side storage of the form.
If you don't plan to implement the functionality of server-side storage, and if you don't need the extra analytic data of where they stop on the form - just go right ahead and send it all at once. I would suggest at a minimum, you try to save the form to Local Storage to make it easy for the user to pick up where they left off.
I want to say it depends on your database model and the data you are fetching from the form. It may be that the data retrieved from the first form is enough to do a desired database modification; in that case, it may be nicer to immediately send the POST data. However, if that data may be needed in a future query, it might be better to send it all at the end to avoid re-sending old data. Some may also argue that doing multiple posts is worse in terms of network usage
Note: most importantly try to avoid sending duplicate data
I have a table having millions of records. I am using Sails js as my server side code , React js to render data in view and Mysql as my DBMS. So what is the best method to retrieve the data in faster manner.
Like the end user does not feel like getting a huge amount of data which affects UI as well.
Shall I bring only 50 records first and show the pagination in bottom using pagination logic and then using socket.io fetch the rest in background ?
Or any good way of handling it ?
This really depends on how you expect your user to go through the data.
You will probably want an API call for getting only the first page of data (likely in such a way that you can fetch any page: api/my-data/<pagesize>/<pagenumber>).
Then it depends on what you expect your user to do. Is he going to click through every page to see all the data? In that case, it seems ok to load all the others as well as you mentioned. This seems unlikely to me, however.
If you expect your user to only view a few pages, you could load the data for the next page in the background (api/my-data/<pagesize>/<currentpage+1>), and then load the next page every time the user navigates.
Then you probably still need to support jumping to a certain page number, where you will need to check if you have the data or not, and then show a loading state (or nothing) while the data is being fetched.
All this said I don't see why you would need socket.io instead of normal requests (you really only need socket.io if the server needs to be abled to make 'requests' to the client so to speak)
Well, as technology progresses, issues we solved long ago crop up again.
Back in the dark ages, when PHP and ASP were considered awesome, we always had a problem with view states. If you had a page with say a dozen select combo boxes on it, your user chooses some combination and hits next, then realizes they screwed up and hit the back button on the browser, the combo boxes would be back in the default state, usually with option[0] selected. In order to prevent this, we had to write boatloads of boilerplate code that would save the state of those combo boxes to a cookie, or session variable, or something so that when the user hits the back button, we can reload the combo boxes back to the state they were in when they left.
This problem was compounded even further if you had a datagrid on the screen. Because then you would have to come up with some slick way of saving that grid somewhere to prevent from having to hit the database again.
Then came the light. Browser developers realized that most web developers were on the verge of going back to writing terminal programs in Cobol due to this issue and added UI caching to the browsers. This allowed us webdevs to not have to worry about this anymore except in odd situations.
So, life was good. Then someone came up with the bright idea of trying to replicate GWT without all the hassle and the web explodes with all these javascript frameworks. The one im dealing with specifically at the moment is AngularJS 1.2.10 with Angular-UI. I have until Friday (most likely wednesday tho) to make an initial assessment on if this technology is a viable alternative to our current standard (thats pretty much universally hated) JSF.
So, i follow some guides, pound my head against the desk a few times, and I have an angular app with 3 actual HTML pages, each HTML page with 2 views.
Before you go there, understand we can't use it unless we can do multi-page JS apps. Some of the applications that this will be worked into have been in development for a decade or more and its simply not financially practical to scrap an the entire UI and start over again. We would instead be doing things like taking these 50 struts pages and converting them to angular/rest and linking them seamlessly back into the remaining 800 struts pages of the application.
So in my exercise of playing with this, I encounter my old nemesis. Back button view state issues.
I have been playing with the UI-route system. The fact that I can deep link using the route system solves part of my problems. But, if say I have a search page like this:
view-search
combo: search type [member,nonmember]
combo: result type [detail,summary]
combo: search state {all the states]
textbox: contract number
etc etc etc
And various combinations of combo box selections and text entries comes up with a list of 1000 people. Now the user selects one of those people on the data grid and it takes you to view-detail. Well the fact that you can use routing to do something like index.html#detail/bob is cool, but if the user realizes thats the wrong bob and hits the back button, they get a blank search screen again and they have to enter everything over and worse yet, send another search to the database to rebuild the datagrid. Some of these screens have 50 or more options to choose from when searching for data so trying to put all of them into the URL routing sounds completely impractical to me.
Now in my research I found this post:
Preserve state with Angular UI-Router
And that has promise mainly because I have a view state object that I can store into a Redis database or a session EJB for cases when the user actually jumps out of angular and into the legacy Struts application, then back buttons back into the angular application, but the fact still remains that on some of these pages, that is a huge amount of boilerplate code that we would have to write in order to make it work.
I don't really mind the idea of having to manually save off the view state object and read it back in from a Redis server or something anytime a user enters or leaves an HTML page in the system. What i'm really looking for is a way to automatically generate the object that is to be saved without having to write volumes of boiler code.
Is this possible? I keep reading the ui-route documentation but it doesn't look like this is addressed, at least not that i've translated yet.
If this is possible, what controls should I be looking at?
thanks
-------------- Edit
I just thought of something. There is one central scope to each of the single page applications. (Im basically going to be building a multiple single page apps and hooking them together) So if i use a naming convention, something like this
$scope.viewstate.view-search.searchType
$scope.viewstate.view-search.resultType
$scope.viewstate.view-search.searchState
Then the viewstate object should simply be a js array and when I create a function to move to struts.do, i can simply save that array off to the Redis server as a nested map object. Then when my user back buttons back into the angular app, i can capture that using the route system and retrieve that viewstate object from Redis and insert it back into my scope, thereby rebuilding the scope for the entire single page app in one shot.
Would that work?
I believe that you have a very complicated issue of trying to keep the view states between your varying pages with the amount of data in your pages. I think that the only real effective way to do this is to write an angular service that you can then pass to your various pages. as You already know the service is a singleton that you can use in various controllers and could be utilized to maintain the view state as you described. here take a look that this link and see if it will help: http://txt.fliglio.com/2013/05/angularjs-state-management-with-ui-router/
After some thought what you suggest in your edit might work, but I would still use a service to retrieve that array of data, as it would make it easier to reinsert in to angular scope
I am exploring something similar for an Angular app that I am writing. Keeping a user login during a page refresh is easy. Displaying the state on the page after a refresh is an entirely different problem.
How long must the state be persisted? I'm evaluating two possibilities.
First, saving the state (current form values or whatever) to the database. As the page changes, incrementally save the state to the database. On a browser refresh check the database for saved values.
Second is to use local browser storage. This is 5 megs of storage. 5 megs is a lot of text. Again this data would incrementally be saved into storage. When the browser refreshed, simply load data from localStorage.