Skip to content

Architectural Decision Records (ADRs)

Jump to bottom
Nick Battam edited this page Mar 27, 2019 · 21 revisions

This page provides all the architectural decisions for the system - this may be decisions where there are multiple valid choices but for certain reasons one option is chosen over the others.

This list of ADRs also retains historical decisions to show how decisions have changed over time and the reason for that change - this prevents cyclical decisions due to knowledge being lost.

Possible status values are proposed, accepted, rejected, deprecated, superseded.

ADRs

1. The frontend technology will be React

Status: accepted

Context: There are multiple frontend technologies available; React, Vue or Angular - one of them needs to be chosen to write the DAaaS frontend and its plugins in.

Decision: React will be the chosen technology for the frontend as it is best suited to large scale apps, has the most community support and combines well with other technologies allowing it to stay current.

Consequences: The DAaaS frontend and any plugins centrally developed will be developed using React.

2. The frontend will be developed with Typescript

Status: accepted

Context: Javascript is an dynamically typed language. Typescript is an extension to the the ECMAScript language specification that strongly types the language.

Decision: We have decided to adopt the Typescript for frontend development. This will add additional development and compile time checks to the code.

Consequences: Additional development overhead.

3. Redux for React App State Store

Status: accepted

Context: Building a complex web application brings challenges around how to manage state.

Decision: We have decided to adopt the Redux architecture to provide a clean separation between our views, actions and state store.

Consequences: No foreseen consequences of this choice.

4. The frontend will use Material-UI components

Status: accepted

Context: There are multiple UI widget libraries available:

Decision: Material-UI will be used for a standard component library.

Consequences: The library

  • implements Google's material design,
  • offers a wide range of standard widgets,
  • has very good online documentation,
  • is actively supported,
  • npm libraries available that offer integration with Redux react-redux
  • is a de-facto industry standard for React UIs

5. Micro-frontends

Status: accepted

Context: The application must support a plugin architecture supporting site-specific front end components. A micro-frontend architecture supports this model bringing in UI elements from local files or remotely hosted sites.

Decision: We have decided to adopt a micro-frontend architecture using the single-spa library.

Consequences: All UI plugins must include a set of hooks defined in the single-spa model:

  • mount
  • unmount
  • bootstrap.
Clone this wiki locally