FIT3077 Full Lambda Assignment 2
Please mark Assignment 2 stage 2 from the last commit of Thursday 25th May
- Student email: email@example.com
- Student ID: 26898187
- Student email: firstname.lastname@example.org
- Student ID: 26029391
- Yarn (Optional but highly recommended): Depedency management software that typically outperforms npm at installation speed.
- Windows 10 Home (OS Build 14393.1066)
- OS X El Captain 10.11.6
- Google Chrome +58.0.3029.110 (64-bit)
- Firefox +53.0.3
- Make sure Node.js is installed.
- Open up a terminal.
cdto desired folder.
git clone https://github.com/Monash-University-FIT3077/fulllambda-Assignments.git
npm install. If you have yarn installed you can use
yarn install. Wait for all the node packages to finish downloading.
npm run backend-start. Wait for the the 'Webpack configuration complete' message to be printed to the console.
- Open up another terminal.
npm run frontend-start. Wait for Webpack to finish again.
- Open a browser.
- Type into the URL bar: 'localhost:3000'.
Note: You MUST wait for the backend's compilation to finish before running
npm run frontend-start. This is an issue with having two Webpack builds running at the same time in the same folder with similar configurations. It is assumed that a solution to this problem is out of scope for this assignment.
The report resides in the repository with the file name: FIT3077_Assignment2_Stage2_Report_26029391_26898187_FullLambda.
Why do we have a backend server
We use Node.js to provide our own API to frontend applications, as opposed to the frontend application communicating with the SOAP client directly. Despite the added latency, there are a plethora of reasons for doing this:
- Removes frontend polling all-together: Polling is inefficient and poorly scales with high frequency polling (a potential change to the requirements in stage 2). By rolling our own API, we are able to leverage WebSocket which removes the need for frontend clients to poll all together. This is far more efficient compared to high frequency polling.
- Minimizes traffic directed at the SOAP service: One of the objectives of assignment was to "minimize the network traffic generated by your system: don't access the web service more than is absolutely necessary". Our server acts as a cache for the SOAP service's data, allowing users of frontend clients to retrieve data witout the need to retrieve data from the SOAP service at all. This means that the amount of traffic directed at the SOAP service is independent of the number of frontend cleints. Real world APIs also often have a limit on the number of requests that can be made to their service per hour. Our implementation circumnavigates this issue.
- Changes are invisible to the client: Changes in the
WeatherClientare transparent to frontend clients. This is particularly useful when constantly switching between
- Potentially less computationally intensive for poor-performing devices: Less logic on the frontend means that simpler devices can use the application without lag.
Engineering philosophies and patterns used
- The observer pattern: The observer pattern was used for on click events and in the
SessionMonitoringManager. Our observer pattern mimics the Android SDK's implementation of the observer pattern.
- Factory pattern: We use the factory pattern to allow the
FullLambdaWeatherServiceto create a
WeatherClientFactoryso that the service does not need to know the underlying steps to create the client. Retry-client-creation functionality will be written into the
FullLambdaWeatherServiceas an example of using the pre-existing factory code to potentially build multiple
- Seperate GUI and logic: We almost totally avoid any logic on the frontend of our project. This allows us to provide functionality that is independant of the user's interface. In fact, the only frontend class that performs limited controller functionality is the
WeatherPageContainerwhich links the view to the socket.io API. All other frontend classes concern themselves with rendering the DOM in a particular way.
- MVC (Model, view, controller): The model, view and controller (as previously discussed) are seperated. The
WeatherPageContainerdetermines how inputs are interpreted, all other
React.Components serve as view type classes. All business type logic is handled by the backend server.
- Use dependency injection: Gregory Kick's Java Dagger 2 video explains dependency injection quite well. As an example of the benefits of dependency injection in our own code;
WeatherClientis passed into the
FullLambdaWeatherService's constructor. This allows us to swap out the
TestWeatherClientwhich allows for easier debugging.
- Composition over inheritance: Self explanatory. This mentality is typically considered to enable more flexibility in code. An example of this was our choice to compose the
GenericListItemrather than inheriting from it.
- Design guidelines: Material Design
- Linters: TSLint
- Git patterns: See Git guidelines
- Language: American English
- Sequence diagram guidelines: IBM Sequence diagram
Current loggin guidelines
- Green text: successful
- Red text: error information
- Cyan text: important information
- Purple text: parameterized information
- White text: General/other
The development-master pattern is used in conjuction with feature branches. Code is merged (usually) via pull requests.
master: The development branch should be merged into this branch whenever a new version/set of features, ideally bug free, have been completed.
development: Features should be merged into this branch once implemented. This branch should maintain transpilability and compilability. Known bugs are allowed to be merged into this branch. Developers can work on the development branch for minor changes to the codebase.
Feature branches: Feature branches contain major refactored code or implementations of new functionality. Code from feature branches should be merged into the development via pull requests.
Other cool things our product does
Our product can handle multiple sessions from different browsers/tabs. Each will have it's own set of clickable buttons to add and remove rainfall and temperature data. We also cache the weather data so new sessions can be served ASAP.
It also has a google map which can be used to toggle location pins for a weather service.
Location pins represent the intensity of rainfall, with greater rainfall resulting in a deep blue and less rainfall in a light blue pin. If rainfall is not selected it defaults to red. If rainfall in not a valid number it defaults to grey.
Around each marker is a circle representing the intensity of temperature, the hotter it is the more red the circle. Likewise if temperature is not selected it defaults to a greyish-blue and if temperature is not a valid number it defaults to gery.
Hovering over the pins displays more information about the area.
Languages & syntax choices
Differences to Java
- Interfaces can have variables. These variables are passed onto the implementer of the interface.
- Optional parameters are supported in TypeScript. This renders the Builder pattern somewhat redundent and is thus not used in our code base.
readonlyis supported in TypeScript. We use this
public readonlyover accessor methods, in all 'model data' type objects.
JSX harmony is a language primarily built for React. The language was primarily used to make React components easier to read and faster to write.