FishFryMap 2.0 brainstorming

[gassc]

As an originator and long-time maintainer of this codebase, this issue contains some of my thoughts on where to take it as a project next.

Why

At this point, the code dates to a 2015 MapTime session.

It is reliable and has been through real world testing. However it is hard to maintain, because it is frameworkless. It is one big JavaScript file manipulating one big html file with jQuery (gasp).

What

The existing features are well loved, and there is a growing backlog of good ideas. So this effort may not be so much about a redesign of the user experience, but of the technical implementation of that UX.

How

Broadly, the approach to creating the next gen range from

• Recreate what is (but do it the way it should be done in 2023)

to

• re-vision it, evolve it, make something with a new UX.

Approach 1: changing the tires while the bus is moving

This approach keeps the current separated web map client / API server architecture in place, which allows for the map to be updated independently from the FishFryForm/Rest API.

1. A new map client can be built in parallel to the existing one, using the same ReST API from FishFryForm
2. Updates to the new FishFryForm to support new map features (e.g., additional filterable attributes)

Step one could happen at a CfP hack night (let the best map win).

After 2, queue up re-creation of the FishFryForm app (which faces some of the same project-level issues as this), using a batteries-included framework (e.g., GeoDjango).

Approach 2: Mirror the Food Access App architecture

It's doing similar things, has lessons learned, so

Approach 3: New monolith architecture

Something like GeoDjango (Python), Ruby on Rails (Ruby), F3 (PHP) is fair game as a way to consolidate the map and form/API. With a PostGIS database behind it we can do some fun things with filtering and queries (transit access, find the nearest fry, etc).

For apps like the Fish Fry Map, which are highly interactive single page sites, this approach can be work but requires a bit more thought/work to set up logistics for contributors. This is especially true when the front-end and back-end tech stacks (JS versus probably not JS, respectively) are different.

What else

Managing contributions and deployment

We don't currently implement any best practices for managing an open source repo with multiple contributors. The next version should have the project infrastructure geared towards quick onboarding from potential code contributors. This should include

• specifying process for contributions via branching
• push permissions via teams/roles managed by the CfP org
• dev environment setup scripts, auto-linting configurations, automated testing (would be nice), and other techie stuff to let folks contribute as quickly and consistently as possible

The FishFryForm and database

There is also the server-side web app, FishFryForm, used for managing the data and serving up the
geojson used by the map. It's a Python Flask app, with DynamoDB as the database. The two are connected via some custom query and serialization functions that make it tricky to update the data model.

Tech/considerations described in Approach 3: New monolith architecture_ above are good starts here.

[mhowe0422]

Github.io limits

• GitHub Pages is a static site hosting service that takes HTML, CSS, and JavaScript files
• GitHub Pages does not support server-side languages such as PHP, Ruby, or Python.