Skip to content

Design guidelines

How FlatTrack must be built.

Project

The project must be:

  • community driven: all efforts are for the community and be the community
  • freely* available and freely* licensed: code and artwork
  • collaborative: all apps in FlatTrack are for collaboration and should grow the interactions between those who use them
  • useful: the features provided should be exactly what people need
  • reliable: it must be built for strong-reliablity
  • secure: it must be secure by default; there must be large security focus
  • private: it must not communicate with third-parties for app resources and functions (exception for optional things like authentication via OAuth); information in the attached database must not leave where it resides
  • accessible: there must be many ways to run it or get an instance
  • portable: it must be easy to pick up an instance and take it somewhere else
  • conformant: no matter where it runs, it should be expected to be the same
  • tested: it should be well-tested and audited for quality and consistency

API

The API must be:

  • stateless: it doesn't have any moving parts; nothing is stored in memory which is unique to the instance - so it can scale
  • dependency: it should live out of the database
  • performant: it must be built to be fast
  • declarative: all resources (accounts, shopping lists, etc...) must read and write mostly the same data (expect credentials and secrets)
  • structured: it must respond and accept JSON data
  • split up into packages: each feature or area of FlatTrack must be split up in package for easy reuse and testing

Frontend

The frontend must be:

  • reactive: the UI adjusts to fit on various screen sizes
  • highly configurable: it should enable advanced settings
  • simple, easy to use, and intuitive: it should be obvious how each action should be done
  • dependency on the API: it should only talk the API from the same source and nothing else; all requests reference the same origin

Packaging

The packaging must be:

  • minimal: contain only the app and nothing more (expect various stateless configuration files)

Deployment

The deployments, in production, should be:

  • highly available: downtime should not be expected

Artwork

The artwork must be:

  • friendly and inviting: it must be a delightful experience

*free as in freedom