Frameworks such as AngularJS, ReactJS, and Vue.js greatly simplify the design of modern Single Page Applications (SPA). In this tutorial, we will show you how to use these frameworks with the Barracuda App Server. The application we will develop is a Vue.js powered SPA; however, the focus is on how to use modern frameworks with the Barracuda App Server and not so much on the actual Vue.js implementation. You can apply the same development setup for all web frameworks that require a packaging system such as WebPack, including ReactJS and Angular.
The article A Modern Approach to Embedding a Web Server in a Device shows how to develop a Vue.js application for the Barracuda App Server by using a so called CDN repository. CDN is an acronym for Content Delivery Network and is an online service that stores static assets for various frameworks. Using a CDN is sufficient for simple applications and when the Barracuda App Server runs in an environment where the browser has access to the Internet for loading these static assets. However, using a CDN is not recommended for more advanced applications or for production mode.
There is a distinct difference between developer mode and production mode in any modern web framework.
When developing an SPA, the web framework components must be converted to a format understood by the browser on the fly.
Most modern web frameworks use a module bundler such as webpack, which is a program run at the command line. The job of the bundler is to take all the various widgets and framework components and produce assets that a browser can load. In other words, the bundler converts components the browser cannot understand into components the browser can understand.
In developer mode, the conversion is typically performed automatically and as soon as you save any of the web components that are part of your SPA.
WebPack and other tools needed during development are designed for Node.js, thus Node.js is required during the development. The Node.js environment can be installed on a standard desktop computer and the Barracuda App Server can be running on the same computer or an embedded device.
Although the developer setup in Figure 2 may initially look inconvenient, you will find, when getting started, that it is a very efficient way to develop SPA applications. An SPA has more in common with a standard desktop application than a traditional web application. By separating the front end development from the back end development, things are conceptually easier to understand. This is especially true if the Barracuda App Server is running on an embedded device and when using a front end developer team and a back end developer team. The front end team can develop the SPA using their desktop computer and communicate with a Barracuda App Server running in the device.
When the SPA application has been completed, a module builder such as webpack is run at the command line to produce the released assets. These assets can then be moved over to the Barracuda App Server, preferably as a deployed Barracuda App Server application -- i.e. deployed as a ZIP file.
You may use any available web technology for the SPA to Barracuda App Server communication; however, we recommend using WebSockets for all communication since SPA and WebSockets go hand in hand. In its most basic form, an SPA is a browser-based application that does not refresh as the user interacts with the page and the WebSocket connection provides a persistent connection.
Learn how to quickly design a full-fledged web application by using ready to use dashboard templates.
You may still think AJAX and REST are the best technology since sliced bread; however, in point of fact, the entire AJAX protocol can easily be built using Websockets technology. This makes Websockets literally a superset of AJAX so it makes sense that we standardize all communication using WebSockets. In fact, we have a tutorial that shows how easy it is to run AJAX over WebSockets .
The example we have prepared, which can be downloaded from GitHub, indirectly uses WebSockets via the SMQ protocol. The reason we use SMQ and not directly WebSockets is to get the benefits a publish/subscribe protocol provides to reactive multiuser applications. This is particularly useful in embedded devices, where multiple users may simultaneously work with the same hardware -- in other words, multiple users working with a shared resource. In such a setup AJAX will not suffice since a response to an action must be replicated across all connected browsers. The article A Modern Approach to Embedding a Web Server in a Device explains this concept in details.
We left out authentication and authorization in the above tutorial, however, a real application would typically require authentication as a minimum requirement.
As we mentioned above, our recommendation is to use WebSockets for all server communication since a WebSocket connection is persistent and an SPA persists in the browser until the browser window is closed. For this reason an SPA has much in common with a standard desktop application, with the exception of being distributed; one part runs in the browser and the other part runs on the server. The services provided by the server typically require some kind of authentication before being accessed.
The example application (link above) uses the SMQ protocol for server communication. SMQ includes authentication as an option and you may use the SMQ authentication mechanism. However, if you are using a raw WebSocket connection or if you use SMQ but prefer another type of authentication, you have two options:
Depending on the type of web server being used, you may have an option to authenticate the user when loading the SPA assets. An authentication token can be created when loading the assets and this token can be used when establishing the WebSocket connection. For example, when using the Barracuda App Server, the standard login mechanism may be applied and activated when loading the SPA assets. The server creates an authentication token in the form of a cookie and this cookie is sent by the browser to the server if the WebSocket connection is to the origin server -- i.e. to the server from where the assets were loaded. The server side can then simply check if the user is authenticated when the WebSocket request is registered by server side LSP code.
Note that a cookie based authentication token should only be used over a secure connection, a TLS protected connection.
The second option is to implement an authentication protocol that communicates over WebSockets. The SMQ authentication option uses this concept, however, SMQ can also use a cookie based authentication token as explained above.
Implementing your own authentication over the WebSockets protocol is not difficult, but there are a few things to consider. Our SPA reference example for the Minnow Server includes a WebSocket based authentication protocol that is secure even on a non TLS protected connection. For more information on this protocol, navigate to the Minnow Server Reference Platform Specification and scroll down to section Authentication and Password Management.