Web2py refactoring

[jrosindell]

We have for some time discussed removal of Web2py and at the same time refactoring parts of the codebase into more clearly distinct parts that ought to be easier to maintain (whether or not they sit in different repos). The remit of treebuilt is out of scope as it's already refactored and in a separate repo and does not use web2py.

Clearly separable sections:

1. Tree viewer

Use: main tree viewer
Languages: JS (using Typescript or similar) possibly also HTML depending on scope
Frameworks: React, Next or Dash for the GUI part of the HTML pages in the longer term (not for the tree / canvas)?
Questions: Make this a JS library only or JS with HTML pages for the tree viewer (main version, expert version, MD version). Might we someday want the tree viewer to be hosted on a separate domain compared to our organisation's website. www.treeoflifeexplorer.com for instance is ours and could be used - feels appropriate.

2. Tree data server

Use: serves data about the tree, taxonomy and species, which could be used for any purpose
Languages: Python
Frameworks: TBD - could use FastAPI and PyDAL
Questions: Is this a possible first candidate for the removal of web2py as it's more easily separated out from the rest? Does this include tour data?

3. Sponsorships and organisation website

Use: Databases, APIs and pages related to sponoring and maintaining the sponsorships, broader organsiation website
Languages: Python, SQL, HTML certainly
Framworks: Django, Pyflask?
Questions: Is it a good idea to separate out sponsorships from the rest (I think not but could be persuaded), where would the tour creator codebase sit - I guess here as well?

[lentinj]

Frameworks: React, Next or Dash for the GUI part of the HTML pages in the longer term (not for the tree / canvas)?

Rebuilding the UI in react is worth considering, but not part of this work I don't think. I'm assuming that the JS is part of this is just a lift-and-shift.

Frameworks: TBD - could use FastAPI and PyDAL

I think we should skip the PyDAL stage now and go all out to SQLAlchemy. I was assuming Flask, but not averse to FastAPI.

Is this a possible first candidate for the removal of web2py as it's more easily separated out from the rest?

A bunch of reasons:

• Very few web2py features are actually used (and more often than not we fight against them), unlike the website.
• This is the main part most developers would be interested in, so not having to set-up web2py would make life easier for all
• It's the most visible part of the site, so going to be hit hardest performance-wise
• It's the part that it makes most sense for. For the website I'd think hard about whether wordpress/static hosting is more appropriate first.

Does this include tour data?

Dunno. I think it depends on the long-term strategy with user generated tours. But it makes sense to use the same user DB for both.

Is it a good idea to separate out sponsorships from the rest?

• Mix-and-match-ing: A development tree server or local museum display can point to the main sponsors.onezoom.org. Or we could have multiple tree server instances with different setups sharing the sponsors.
• Allows us to consider using Django here vs. FastAPI. Otherwise we're stuck with one for both.
• A pipe dream I have is the tree server database is a sqlite file, simplifying tree server deployment & tree-build. Splitting the 2 halves would be a step towards this.