After drafting the initial architecture for the web portal itself and figuring out the biggest technological issues with the architecture, mainly how to get the different single page applications work together, the actual implementation phase began in March 2019. The implementation process covered the creation of the SPA Portal -application – show in figure 3.1, the configuration of the existing applications, the creation of the top level navi-gation and the utilization of the design system described in the chapter 4.
5.2.1 Top level web portal application
As shown in figure 3.1 in section 3.3 the architectural base of the whole web portal is one single page application which encapsulates or more precisely holds a reference to all other underlying single page applications. The top level web portal application uses or implements thesingle-spa –framework and its required configurations and functions.
The most basic implementation could be achieved with only two files, one HTML file and one JavaScript file. The HTML file would provide the mounting point for the
single-spa –framework and the JavaScript file would define the configuration and initiate the framework instance by executing the start -function of the framework when the file is read. With this kind of setup the framework would run, but nothing would show in the browser as the framework does not provide any user interface.
i m p o r t ∗ as s i n g l e S p a from ’ s i n g l e−spa ’ ;
What thesingle-spa–framework requires in the means of configuration is that the frame-work needs to know what applications it should be using and where those applications can be found and additionally when those applications should be used or shown in the user interface. Configuring the applications used by the framework is defined with frame-work’sregisterApplication-function, example of which is shown above. This function takes three required parameters, the name of the application to be registered, a loading function or an application object, and an activity function. The loading function or appli-cation object should both provide thesingle-spa–framework the information it needs for loading the application, and for activating and deactivating the application. These three actions are done by implementing three API methods of the framework in the application which is to be registered. The activity function is what the framework uses to determine if the application should be active or not. The activity function gets the current browser URL or location as parameter, which can be used to determine the activity of the application.
Alternatively the application can also be always active, which can be useful.
5.2.2 Configuring the underlying applications
Forsingle-spa–framework to be able to manage other single page applications, the ap-plications need to implement three interface methods. These methods are the counter-parts of the loading function’s content mentioned in section 5.2.1. The three methods are bootstrap, mount and unmount. The first is used by the framework to import the appli-cation in to the framework appliappli-cation. The second and third methods are used by the framework to show and hide the application from view. Implementing these methods is merely a trivial task because of the existing packages, which allow a developer to imple-ment these with a single stateimple-ment. The packages are provided for React, Angular, Vue and several other JavaScript frameworks. Example implementation of these methods with Vue shown below.
In addition to creating the API methods required by single-spa –framework, there are other changes that needed to be made to the applications that are going to be part of the web portal. One alteration that is needed, is including all the required files as part of the application bundle. The application registered tosingle-spa–framework is no longer going to have its own HTML file as a mounting point and with that, there is no longer the possibility of including files and other dependencies through the HTML file. To overcome this, the files need to be either loaded as module to get them to be part of the JavaScript application, or they need to be dynamically added to the DOM after the application is loaded by thesingle-spa–framework.
As part of the requirements set for the web portal implementation, it was required that the applications that would be a part of the web portal should also work as standalone
applications. This requirement creates the need for creating separate configurations for the web portal and the standalone versions of the application. Because of the previously mentioned requirements dictated by the single-spa–framework, the web portal version of the application and the standalone version need to have separate entry points in the applications build process. The entry point is simply a single JavaScript file from the build is planned to start. The separate entry point is required because of thesingle-spa –framework methods and the application instance need to be enclosed in a single object.
Additionally the build process of the standalone application needs to produce a HTML file which can be used as the mounting point of the standalone application. The requirement for the application working both as part of the web portal and as standalone application also is aligned with the idea of microservices, as previously stated in section 2.4. The requirement also supports the development process of the individual projects, as they can be developed completely separate from each other and the developers can take full advantage of the developer tools provided by many of the JavaScript frameworks, like React and Vue. This advantage is lost if the application development is done through the web portal application.
Because all of the applications which will form the web portal are separate projects and need to be also standalone applications, they also are all hosted in different locations.
This raises a challenge as to how the applications can form a single-page application that does not require any extra browser loading screens. This is a challenge which the single-spa –framework does not solve on its own, it just trusts that the application is available when it needs it. Fortunately thesingle-spa–framework allows the loading function of the application to be asynchronous. This in mind, it is possible to load the wanted application via HTTP request. To ease the application loading process an externalSystemJslibrary is used, which is designed for a such purpose [35].
5.2.3 Managing navigation
To manage navigation between all the single page applications, which are part of the web portal an extra application was created addition to the existing applications as shown in figure 3.1 in section 3.3 namedSPA Portal. To be able to navigate from one application to another, theSPA Portal application needs to know what is the root route of every other application part of the web portal. The more specific routing is left for the underlying applications to manage.
Because all of the applications are served from the same domain, the root routes of the applications need to be unique, or there is a great possibility of conflicting routes.
For example, if two different applications share the same root route and both appli-cations have a user information page, it is likely they both have completely identical route of ’https://domain.com/<rootroute>/userinfo’. In this kind situation the single-spa –framework will activate both applications. This feature can be in some cases be useful, but primarily this is not wanted and will cause the user interface to break as two different
applications try to take the whole available view for themselves.
To enable the top level navigation in all of the applications the feature of showing mul-tiple applications at the same time can be utilized. The single-spa –framework allows displaying multiple applications simultaneously, if the applications do not share the same DOM element. So using separate DOM elements for the application managing top level navigation and for every other application, and defining the activity function of the naviga-tion applicanaviga-tion to always return a true value, is all that is required to enable the top level navigation in the whole portal.
5.2.4 Utilizing the design system
The design system, of which planning and implementation process was described in chapter 4, was applied to two of the existing applications, in addition of the web portal’s SPA Portal -application that was created as a part of this thesis. The utilization of the design system in the third existing application was left outside of the scope of this thesis, as it will also require extensive changes related to the application level architecture.
The utilization process of the design system required an extensive amount of work hours, because it caused changes through out the two applications it was applied to. In the views of the applications, in addition of renaming different style classes, it was required to alter the whole structure of the HTML templates used in the Vue applications. In many cases the better designed classes of the design system allowed removing of multiple un-necessary HTML tags, which reduced the amount of nested tags and made the templates more readable.
While applying the design system to the applications, there were deficiencies and places of improvement discovered. For instance, there was an issue with a layout element that overflowed only in one of the applications, which needed to be sorted out. Another issue was caused by the application specific styles, which in certain state caused the element to be displayed in an unexpected way. Also an additional shared component was created due to realizing the fact that a similar state change in the user interface was differently between the application. All in all the utilization process of the design system was sur-prisingly labour intensive, but absolutely necessary to do at this point of the web portal’s development.
6 EVALUATION
After carefully planning the architecture for the web portal and implementing the core parts of the portal it is time to revisit the requirements set for the portal. After evaluating the requirements, sights can be set to the future and possible improvements discussed.