2018 Overview

Target release3.0

This document is in progress


Goals

  • Break admin functionality out of the nominations app and into its own dashboard
  • Make revisions and improvements to the existing nominations app
  • Launch a new site that allows the public to browse and select wish lists to fulfill. 
  • Refactor the backend to use NestJS and TypeScript. 
  • Remove Flow from the existing front end. Build out new front end applications with new, reusable modules, and use TypeScript on all new projects. Only convert the existing nominations system to TypeScript if someone really wants to.
  • Upgrade the authentication and session engine to restrict application access, and add app-specific permissions.

Background and strategic fit

For 2018 we're building on the success of migrating to a split-stack application in 2017 by introducing new applications to improve reliability and reduce user experience complexity. Additionally we'll be introducing the ability for the public to browse wish lists and select children to sponsor. 

Application breakdown:

This year we're looking to expand to three separate front end applications that will be broken down as follows:

Nominations SystemAdministration SystemPublic-facing sponsorship system

Register as a nominator

Browse, review, edit, and add nominations

List and select children / households available to sponsor.

Add / Edit own nominationsReportingVolunteer registration
Edit ProfileManage usersAbout

List affiliations (CMS, CMPD, etc)

Donation Tracking (question)

Warehouse management tools (question)

Items marked as a (question) are wishlist items that may be pushed to 2019.

Application modules

For 2018 we're adopting a more modular application architecture. Front-end applications will be comprised of modules that can be shared between them to promote reusability and project delegation. 

For example: components and their logic such as our implementation of bootstrap-data-table can be placed in a "components" module that gets loaded into all three applications instead of built and maintained three separate times. We use Lerna and Yarn Workspaces to accomplish this development of several Node modules in a single repository (monorepository).