Lab #7 – SPA with Vue, Vue Router, Vuex Learning objectives
• Use a publisher-subscriber communication model with Redis
• Create and use Vue components
• Use Vuex to efficiently manage app data
• Use Vue Router to create an SPA
Requirements
This lab more than any other is an architectural lab, the way that you implement the functionality using the required tools is what is being graded, even more so than the functionality itself. Use Vuex, Vue Router, Vue components and Reddis in the expected ways discussed in- lecture to ensure you obtain full marks.
Manufacturing and other processes often involve an application receiving data from different sources and displaying the data in a dashboard that allows a user to monitor the state of the system and set of events that have occurred (often with analytics, warnings, etc.). We will be simulating this for a microbrewery process.
Create a NodeJS script called generator.js. When the script is run, every 1 second it should randomly generate and publish a message to your Redis database (using Pub/Sub). The script should do this indefinitely (i.e. until it is terminated). The messages should be published to one of three different channels, determined as part of the random generation of the message: mashing, boiling, fermentation. The messages should contain a JSON object structured as follows, populated with data as follows:
{“status”: randomly populate with either “valid”, “warning”, or “error”
,”message”: some randomly generated text
,”timestamp”: A timestamp, formatting of your choosing, that
includes both DD/MM/YYYY and HH/MM data (not randomly generated, use the actual time the message occured)
}
In this way, the generator script will simulate the creation and emission of log data from a microbrewery’s brewing process. Messages received via the mashing channel are considered “mashing messages” and so forth.
Create a NodeJS script called server.js that subscribes to the mashing, boiling and fermentation channels of your Redis database. This script should receive and store the messages it receives from these channels (they can be stored in memory, there’s no need for a database).
The server script should also listen for status updates sent via your SMS FaaS bot from Lab #4 and from your Slackbot from Lab #2, and these messages should be stored in memory as well. Assume that the user will send messages with a status of either valid, warning or error. Any message received via the Slackbot should be considered a mashing message, and any message received via the SMS FaaS bot should be considered a boiling message. You can re-use code from Lab #2 and Lab #4 to implement these aspects, but it all has to be implemented in server.js, there shouldn’t for example be any communication between your older lab solutions and this one (e.g. having server.js read your SQLite database from those solutions, or anything like that).
The server script should also serve your single page application (SPA) at the URL http://localhost:3000/.
The SPA it serves should have 4 pages: All, Mashing, Boiling, Fermentation.
The pages should be accessible via a navigation bar at the top of the page. Initially the user should be presented with the “All” page. Whichever page the user is on, that page should be highlighted in the
navigation bar, and the URL in the browser should be changed to reflect the page the user is on.
Each page should present a list of the relevant log data that the server has received… in the case of the “all” page it should display all messages, in the case of the “mashing” page it should display the mashing messages, and so forth. The list should highlight valid messages with a green background, warning messages with a yellow background, and error messages with a red background. The list should be presented chronologically based on the message timestamp, in order of most recent messages to least recent. Each page should provide user interface options that allow the user to filter the messages on that page for either: all, valid, warning or error messages.
When the application is first loaded by the user, any messages that the server has received since it has been running should be sent to the SPA and made available in the relevant pages. Any additional messages that the server receives should be immediately sent to the SPA and then immediately be made available in the relevant pages (how you do this is up to you, but WebSockets would make sense).
Use Vue Router to implement the SAP/routing aspects of the application. Use Vuex to manage the application data efficiently. Create and re-use Vue component(s) to implement the list functionality on each page.
Style the application nicely. You can use external styles. Do not use any other Vue libraries other than Vuex and Vue Router to implement the functionality in this lab.
Submission instructions
When you have completed the lab, put your source files in a folder called lab7.zip and submit it in the Dropbox.
Marking scheme
Marks are awarded for successfully using the technologies in the expected ways to implement the functionality.
Generator script
5
Server
5
Server-client communication
5
Redis pub/sub communication
20
Vue Router (SPA)
20
Vuex (data storage)
20
Vue components (list pages)
25
Total
/100
Reviews
There are no reviews yet.