Investigate Splitting the React into Separate Food Seeker and Volunteer Applications.

[entrotech]

Overview

For reasons described below, we should investigate the possibility of splitting the client application into two separate applications:

• A Food Seeker app for people looking for pantries and meal programs, and
• A Volunteer app for Volunteers and Administrators to maintain listings.

Preliminary Pros and Cons

The potential benefits are:

• Possibly reduced hosting costs as described in Issue Investigate Options to Reduce Hosting Costs #1985
• Potential improvement in the Food Seeker experience, due to reduced bundle size and network traffic. Moreover, the client app could be deployed to a static file server like Amazon S3 (instead of an actual web server), and potentially exploit edge servers or CDNs to serve the app and data more quickly.
• A clear separation of UI design concerns for the Food Seekers vs Volunteer user experiences. This might make the app easier for UI Design, UX team members to design.
• On the developer side, the Food Seeker app would essentially be just a front-end React App, so any changes would be within the skill set of front-end developers with sufficient experience. The Volunteer app would be a full-stack app providing work for full-stack developers. The two applications are de-coupled enough that they could be maintained by two completely different teams.

One downside is that the Food Seeker app is precluded from adding new features that would require database access such as:

• Allowing Food Seeker users to be authenticated so they can represent a pantry and edit their own listing(s), publish news about their listings, like special events, etc.
• Allowing users to sign up for custom notifications of some sort (changes to pantries, special events, etc.)
• Allowing users to save their preferences (favorite pantries, search locations, search preferences, ratings, etc.)

Related Issues

• Investigate Options to Reduce Hosting Costs #1985

Action Items

• (To Be Determined)

Resources/Instructions

Concept Description

The Food Seeker features we have now do not update the database at all, and only connect to the database to download all the listings at once. This could be replaced by building a listings file into the code, or, probably better, downloading a file of listings from the cloud somewhere (like an AWS S3 bucket). The listings file would need to be updated by some sort of process driven by the Volunteer app. Then the Food Seeker react app could be hosted from a cheap static site server (again, S3 is one option), so it does not need a dynamic web site or database connection. This would preclude us from adding future features that require database access to the Food Seeker application, but potentially improve performance of the Food Seeker app by reducing the code size, and hence, initial load time, and possibly be served from a CDN, which the internet might cache closer to the clients' machine on the internet. The Food Seeker app should be optimized for slow network connections and mobile devices.

The Volunteer/Admin client still needs a database and uses a database connection, so it needs a Web API server to be hosted. This app is typically run on a desktop machine by Volunteers or Admins with good network bandwidth, so bundle size, network traffic and small devices aren't significant issues.