Skip to main content

2. Local Stack choice

  • Date: 2022-01-03
  • Status: Accepted

Context​

The stack choice is made in consequence of requirements. One of those requirement are privacy and security. We would like to integrate with multiple services. Some are public API that can be consumed by other services, but some API are related to end-users. The latter requires that authentification information is handled with care and we do not want to keep this information in our system. This information will be kept private on the computer of the user.

Licensing also requires a local backend to access some kind of data. A good example is the nav data that requires a subscription. This data must be only accessible to the end-user and not shared to other users.

Interoperability is a good quality to keep in mind. Some flight simulators are available on multiple platforms.

Decision​

This requirement influences the architecture in a way that we cannot use a standard backend-frontend pair.

The proposed architecture will include a front-end and a backend, but the front-end will be coupled with a local backend. This local backend will be responsible of consuming directly the services for the end-user. Other public services will be consumed by our backend remotly.

Also, having something simple to develop like a website is a must. Rapid development with tooling are well mature in this kind of technical stack.

Consequences​

An Election application would help to resolve this. Local operations can be made by NodeJS services and a renderer (with React) would serve as a presentation client.

We can reserve fetching the general public information to React. Other services (with authentication) would require to be used by the NodeJS services.

The Onward Flight API serves as a remote endpoint the persist user data related to Onward Flight (as mentionned before, private data or user data of other third-party services must stay locally).