Skip to content
Leif Johansson edited this page Apr 29, 2019 · 4 revisions

Plans for 1.0.0

From the inception of the project pyFF has always been a traditional monolithic web application. With the involvement of pyFF in the RA21 project and the interest to bringing the pyFF discovery architecture to a wider audience in the form of a general discovery service, it makes sense to re-think the pyFF software design a bit.

Modern web applications almost invariably follow some version of the following architecture:

  • backend business logic is implemented by a RESTful API - sometimes using a microservice architecture
  • frontend presentation logic is implemented by (sometimes single-page) HTML5 applications using JavaScript to call the backend API

Starting with 0.11 pyFF is embarking on a process to transform from a monolithic to a modern web application optimized for container-based packaging. At the same time pyFF will transition to semantic versioning starting with the release of 1.0.0 which will mark the end of the transition and the beginning of the new face of pyFF.

FAQ

What will pyFF 1.0.0 look like?

  • The 1.0.0 release of pyFF will most likely not be shipped with any HTML frontend. Instead pyFF will come with a sample docker compose file that will launch the pyFF core along with a frontend management and discovery service application.
  • pyFF 1.0.0 will probably use apscheduler to provide a more consistent way to handle background tasks.

What does the path to 1.0.0 look like?

In the short term the following will happend

  1. merge documentation PR from Hannah Sebuliba (thx!)
  2. merge the api-refactory branch which includes a pyramids-based API
  3. tag and release the last monolothic version of pyFF: 0.11. This version is a stepping stone and a way to preview the new API which will become the standard pyFF core in 1.0.0.

What happens next?

  1. all frontend code (old discovery, management web app) will be removed
  2. a new frontend HTML application that allows browsing and display of an MDQ server will be created. This app will try to stay pyFF-independent, only relying on MDQ and possibly the .well-known/webfinger extension implemented by pyFF.
  3. a docker-compose.yaml that starts the pyff api core (API), frontend app and possibly a DS will be created
  4. tag and release 1.0.0

Future plans

There are several ideas for pyFF that have been languishing in part because of the complexity of the current software architecture:

  • new redis/#nosql backends
  • work on reducing memory footprint
  • pubsub for notifications between MDQ servers
  • more instrumentation & monitoring
  • adaptive aggregation for large-scale deployments
  • elastic search
  • management APIs for integrated editing of local metadata
  • OIDC
  • generating offline MDQ directory structures (cf scripts/mirror-mdq.sh)
Clone this wiki locally