Functional business systems, and by that I mean systems that businesses depend on to run day-to-day, have a common tendency to lack creativity in functionality and usability, often mimicking the look and feel of their underlying database. As these systems move towards web technologies, the same trends occur with companies moving from old school spreadsheets to clunky web dashboards.
By looking at the incentives that encourage these companies to move away from legacy systems, some key points repeatedly stand out:
In this article, we’ll look into why a ReactJS SPA and a Laravel API make an excellent stack for building these systems and the benefits and drawbacks compared to alternatives. Although I specifically reference React and Laravel, the point should be made that any SPA technology or web framework suitable for web APIs would work just as well.
Whilst SPAs have remained a popular choice among developers, they are often used in websites that won’t benefit from the features they bring. . SPAs are front-heavy, doing the majority of the asset loading when the application is first loaded. In most websites, this is the opposite of what you would expect as you want your visitors to experience a swift initial load. However, in systems where your employees are going to load the system up at the beginning of the day and spend their whole day working in it, there is no demand for < 3 second initial load times. Even then, as these SPAs are often served as entirely static assets, with caching, that loading time is only going to be experienced the first time an employee uses the system and from then on, they’ll be able to benefit from loading the cached resources.
The real performance benefits of SPAs arrive beyond the initial load.
React.JS is able to make a copy of a page’s DOM in virtual memory, allowing smart comparisons to be made as components and contents update to replace small pieces of the DOM upon change. In standard web systems, any significant state change such as the submission of a form or switching to a new page requires a complete load of a new page. You’ll see this by the quick ‘flash’ when you navigate across a site.
With this virtual comparison, instead of reloading an entire page we can persist the common elements, such as the navigation that remains the same on all pages and switch out only the content that has been changed.
In a typical website, sections of data often have to be rendered server-side and are sent down as a large HTML file. More often than not this data is split up into modals or tabs that are always present, hidden away in the DOM.
With a supporting Laravel API, React components can be built to request their own data as they’re brought into the page. This means that data loaded by your users is small and specific so we remove the concern of bloat. The only data requested from your servers is what’s being used by your users at that moment; without any presumptions on how or why that data is being used.
Elegant data management solutions such as Redux can be used to keep hold of this data in memory so that any time the data is re-requested it’s instantly available to the user without having to send off another API request.
Many organisations now need business systems that are available to employees on the go; think field management systems. With many SPA frameworks coming up with native alternatives (e.g. React Native in the case of ReactJS) many web applications can be built as native mobile applications, sharing a significant portion of the codebase.
If we don’t need to leverage the native capabilities of mobile phones, the React web application can be built with a responsive design so it’s available for all devices. This isn’t anything new for web though.
By building the supporting backend as an API, the front-end can be considered a ‘client’ of the API and we can build as many other clients as we need to, broken down by platform or by use case (e.g. an admin system). They can all share the same API functionality without having to develop anything new.
Once any React application is ready for production, it can be compiled or built into a bunch of static content files that can be served as static web files. By leverage Amazon S3 we can create a new bucket to store these files and distribute them as a static website that has an infinitely scalable reach. We no longer have to worry about how many requests our servers can handle to serve this content up; it’s a managed service that AWS is happy to take care of.
The backend, however, will need a more sophisticated solution, still achievable all from within AWS. The API can be replicated across multiple servers sitting behind a load balancer that can distribute requests from your client between the servers. A shared session solution can be used to ensure that user session data can be persisted when moving between the various API servers. We can then set up auto-scaling groups to ensure the number of servers available at any given time can scale up or down dependent on demand.
React Single Page Apps supported with a Laravel API offer up the ability to create incredibly interactive systems with great performance and scalability. In large scale business systems that are shared by employees all across the company, the increased initial investment required for two code bases is grossly outweighed by the long term cost savings in scalable opportunities for growth.
User Acceptance Testing (UAT), also known as End-User, Application or Beta Testing, is the final phase of the testing process ahead of relea…
The importance of building security into system design from the outset…