It is already October and some time has passed since our great 25th anniversary party – inPULSE. Everyone who was there for sure still remembers this great event, be it the great location, Imaginata in Jena, the inspiring speech by Anders Indset or the parties in the evenings.
On the first day we had a session in the technical track about our new REST based storefront project. So for everyone who was not able to attend I just want to give a short overview about the project and what was presented.
First of all we gave a short overview of the different approaches of classical web applications and single page applications to get everyone on the same page.
What is a single page application?
A single page application, or SPA in short, is a web app that can fit on one HTML page and provide users with a more fluid and responsive experience.
The page updates, but never reloads throughout the whole process, and control is never transferred to a separate page, unlike a traditional storefront, where each user interaction typically results in a new html page that is being sent by the server.
Instead communication with the server happens just via AJAX requests and the response is some JSON containing just the needed data for state transition but not the complete html.
Data that is transferred is much less compared to the traditional approach as few information is needed by the application to perform a page transition.
Single page applications have a number of benefits in different areas and for different stakeholders which brings me to my next point:
Why building a single page storefront application?
First of all, there is the end user of the storefront, our customer. As we have seen the data that is being transferred is much less compared to the traditional approach, it will result in better page performance. This is especially true for mobile devices with limited bandwidth. As only data is transferred and not the complete html markup, page response times are much faster. With data held in the browsers context even page transitions that do not require server communication are possible, including offline support of your site.
There is one important exception where performance is typically worse than in the traditional scenario which is the initial page request. As the whole rendering is done by javascript within the browser, this javascript must first be transferred to the client, then be interpreted by the browser and only then the rendering of the page starts.
To overcome this challenge, nearly all modern javascript frameworks provide a solution for server-side rendering of Javascript. Since we are using Angular, Angular Universal is our choice to solve this problem. So with Angular Universal the first page request is answered with a fully rendered HTML page instead of just the skeleton HTML. After transferring the initial page, the javascript of the application is loaded and takes over from there on. This approach not only improves performance for the initial page request but also allows for better indexing by search engines that still have a lot of trouble indexing content of single page applications.
The next benefit is more important to our next group of stakeholders, the Web Developers. As a Web Developer you want to be up to date and work with the newest and coolest technologies and the latest architectural concepts. There’s much going on in this area with SPA’s, Progressive Web Apps, REST API‘s, etc. With our decision to work on a REST based Storefront we allow Web Developers to use all that. Since we utilize technologies that are widely accepted within the developer community new developers can build on their existing knowledge and it will be easier to find a developer that can build intershop applications compared to the past.
Maybe the greatest benefit of all however might be the clear separation of client and server responsibilities. Due to the architectural concept, the server is now responsible for persistence and business logic, the client for rendering. This enforces a clear separation of concerns and hence a clear API that can be better maintained and reused for different applications, not only web-based but also for native mobile apps or other devices.
This results at the end in lower costs for Ecommerce Managers and allows for constantly updating within the cloud.
Outlook
While we also talked about the overall architecture, tooling, how we selected our framework and how the new artifacts map to existing Intershop artifacts, I do not want to repeat all of that in this post as it might become too long for a single blog post. We are going write about more specific topics in later posts to keep you up to date.