This week, Aurelia community member and author, Sean Hunter, shares a section from his book "Aurelia in Action".
To understand what kind of projects Aurelia works best with, this article (excerpted from Chapter 1 - Aurelia in Action ) looks at several web development models in the context of a sample application. With each model, we'll review the strengths and weaknesses, and see where Aurelia fits.
Let’s take a look at the types of projects where Aurelia really shines!
Imagine that you are tasked with building an ecommerce system: buy-stuff.com. This system consists of a set of the following distinct groups of functionalities:
- Blog: News and updates about new products or events. This needs to be searchable and is mainly a read-only system.
- Product List: A listing of all the products that your company has on offer.
- Administration: Administrators need to be able to add new products and view statistics of what users are doing on the site.
SPAs can be structured in several ways, but for our purposes, we can split these into the following four main categories:
- Client-side-rendered SPA
- Hybrid SPA
- Server-side-rendered SPA with client-side continuation.
*Figure 1 Server-side applications retrieve the entire page load as one rendered resource from the server (in addition to any CSS and JS that would typically be loaded separately).*
- The entire page load is rendered on the server, so scaling the server allows us to improve page load times without us needing to be concerned with the performance of the device used to render the page client side.
- Initial page load is generally fast. The user isn’t returned our page by the server until the page is ready to go.
- Though the initial page load time is relatively quick, subsequent interactions with the page also go through the same life-cycle of a full HTTP request to the server and re-render of the entirely new page in the browser. This is ok for the features such as the Blog and Product List but is not as ideal when the user needs to perform a set of interactions on the site and receive rapid feedback (such as commenting on a blog or creating a new product).
In contrast to the server-side application, the entire payload is loaded up front and returned to the browser in a single batch in a client-side SPA. This payload contains the application scripts and templates along with (optionally) some seed data required on the initial page load. In this case, the page is rendered on the client side rather than the server side. Traditionally, in this model, we’d have the entire e-commerce website returned when the user visited the initial page. Following this, as the user browsed through various pages such as products and blog entries, we’d re-render the page client side, based on AJAX data we’d received back from the server.
*Figure 2 Full client-side SPA. Entire application bundled and returned in one or two responses from the server and rendered in the browser. Subsequent Ajax requests completed to populate data are not required in the initial page load.*
- As the user clicks around, viewing products and comments on blog threads, the response times are lightning fast. The only time the client needs to talk to the server is when it needs data that the user hasn’t seen before. This is generally optional data that may not need to be loaded at all. In these cases, it’s generally easy to show a spinner or a similar indicator to give the user instant feedback that the data they want is being fetched, and then proceed to show them the re-rendered UI once the data has been received.
- After initial page load, you can also make the page feel more responsive by executing multiple concurrent asynchronous calls to the back-end API. When these asynchronous calls are completed you can provide the results to the user by re-rendering only the impacted DOM fragment. An example of this would be retrieving the list of products as JSON from an HTTP response and re-rendering only the product-list while leaving the rest of the page intact.
- Large response payload: Because we are loading the entire page in one request, users are forced to wait while the page loads. Typically, a spinner or a similar indicator would also be shown in this case. But with large applications, this can be time-consuming. Because 47% of users expect a website to load in 2 seconds or less, there is a risk that you may lose some of the visitors to your site if this initial application load exceeds this boundary.
Best of Both Worlds
A good option would be to split the application into several separate sites. The blog might still be done in the traditional server-side rendered style (mainly for SEO purposes). But, you could potentially develop the administrative site and shopping cart as separate micro-sites, providing the user with that rich interaction needed for this style of user interface.
The hybrid approach: server side SPA islands
Imagine a new set of requirements have come down from management. After great initial success, the company is looking to expand the use of the site and sell direct. As such, the site needs some interactive pieces like a shopping cart and order screen. Taking the hybrid approach, you’d create the following three new routes in the website:
*Figure 3 Hybrid SPA approach. In this model, the main content parts of the site would be done in the traditional server-side approach. The product-list and blog endpoints would return the relevant HTML rendered from the server. However, we’d then create multiple smaller SPAs to add rich interaction to the parts of the site that need it such as the store.*
Each of these new routes would host an entire SPA. This approach avoids the need to immediately re-write the entire site as an SPA, but still gives you the benefit of building the rich interactive parts of the site in a technology designed for that purpose. It also avoids the large payload size to some extent by splitting the SPA into smaller chunks that can be more quickly retrieved from the server and rendered.
- Resolves the SEO and unpredictable page-load issues while still providing an interactive experience.
- If you’ve already got a server-side application, you don’t need to re-write it as an SPA from the ground up, but instead can break out components of the application that are good candidates for SPA-style interaction over time.
- Added complexity: Managing application state and page navigation can get tricky when these concerns are dealt with both at the client-side and server-side levels. Each time a new feature is made, there is a cognitive burden of deciding where something would fit best. These styles of application can get messy if the team doesn’t establish some clear guidelines up front for how these decisions should be made.
The Aurelia team is working on a technology called Server Render. Like the name implies, the application is rendered on the server side before it’s returned to the browser. This technology resolves both the unpredictable page load times and crawler issues. This is not yet ready for production use but goes a long way toward expanding the set of applications that fall into Aurelia’s sweet spot. According to Ashley Grant (Aurelia community lead), at the time of writing, the Aurelia core team is working on this as a top priority, so I would expect to see a release very soon.
*Figure 4 In this server-side-rendered SPA model, the initial page render is done on the server side, but once the application has been loaded into the browser, the SPA framework takes over and subsequent interactions are done client side.*
In a way, this model gives us the best of both worlds. The initial render can be done server side, which resolves the issues of unpredictable page-load times and crawler accessibility, but still provides the rich interactive experience that users expect when the page is loaded.
At the time of writing this is still under development for Aurelia. There is also a possibility that this approach will add more complexity to the system architecture by requiring the setup of additional components on the server side.
So where does Aurelia sit?
At its heart, Aurelia is designed to manage your entire web application in the style of: client-side rendered SPA. Any web application where you need a high level of interaction from the user that goes beyond simple content consumption is a good fit for Aurelia. Some example applications that would be a great fit for Aurelia include:
- A messaging client
- A reporting/analytics portal for a website
- A CRUD (create, read, update, delete) application (like the typical invoice/invoice line example)
- An office style application (such as Google Docs)
- An admin portal for a website (like the WordPress admin panel)
What these have in common is a user interaction model that is more like a traditional desktop application than what you’d historically think of as a website. In our e-commerce example buy-stuff.com, a great candidate would be a separate side-kick site to the main website that would be used to handle the administrative operations. You might also use Aurelia to build the shopping cart or blog comment website components as modules of the larger site.
What makes Aurelia different?
With the substantial number of SPA frameworks available today, from the heavy hitters like Angular and React to up-and-comers like to Vue and Mithril, it’s important to consider what makes Aurelia different. What unique value does Aurelia provide that makes it a stand-out choice for building your web applications? I present you with the Aurelia cheat-sheet, four reasons that you can give to your teammates when they ask you this question.
1 - It gets out of your way
2 - Convention over Configuration
Aurelia is developed following the philosophy of Convention over Configuration (one of the key reasons why it’s clean and simple – see point 1). Convention over Configuration means having reasonable defaults rather than requiring developers to manually specify every option. But what if the convention doesn’t suit you? Aurelia makes it easy to override the default conventions when necessary.
3 - When it comes to web standards, Aurelia is a pro
While other frameworks may pay lip-service to web standards, Aurelia has them at its core—in its bones. Wherever possible, Aurelia adopts the standard browser implementation of a feature, rather than creating a framework specific abstraction. A simple example of this is Aurelia’s HTML templates, which come directly out of the Web Components Specifications (you can find out more about templates and the Web Components specifications on the Mozilla Developer Network ).
4 - When it comes to open source, community is king
Aurelia has a thriving open source community. With core team members, and other Aurelia aficionados available on Slack , Gitter (a Slack-like messaging tool for GitHub projects), StackOverflow, and GitHub, and with the recent addition of the Aurelia Discourse forum , you can always get the help you need to keep up the momentum while building your Aurelia applications.