Framerail-based Architecture Plan

When initially conceived, Wikijump was quite literally a fork of Wikidot. It took the gabrys repository, got it to run, and hacked away at trying to iterate off of it. This was a sensible approach at the start since the state of the codebase was not yet fully clear, and bluesoul (who bootstrapped the repository) is experienced with PHP.

However now that we have been working off of this plan for some time, a few things are clear. The codebase is much more broken than expected, and is missing crucial core components. It, in some sense, works, but is missing so much of what present Wikidot has that we are better off making things untethered from Wikidot’s old base and writing things ourselves.

For instance, at present we have an unusual hybrid with PHP and node.JS, with an unusual routing and rendering stack. Particularly for the API, this has been difficult to iterate off of, requiring substantial amounts of boilerplate.

The new plan is to ignore the PHP and other legacy code, using them exclusively as a reference. As the respective parts of old Wikidot are re-implemented, their code will be deleted. The basic stack will be simplified, with the PHP reference denoting fewer and fewer core things to implement.

Instead of the Laravel/custom JS web server and frontend we currently have, we will create a new service which serves as both, built from the ground up. It will be called “Framerail”, thus the name of this page.

Stack

• Frontend / Web server: Svelte

• Database: PostgreSQL (unchanged)

• Backend / API server: DEEPWELL

Service Chart

Client (Framerail) ⇔ Web server (Framerail) ⇔ DEEPWELL ⇔ PostgreSQL

Developmental Changes

• PHP code will become reference-only, and will start to be removed as respective portions are reimplemented.

• The web/ directory will become a deprecated location.

  • Build and deployment scripts will need to be moved.

• Adjust local and development deploys to not create any PHP containers.

  • This will improve the local build and deployment processes.

  • Fixing dev deploys is also necessary around this time.

• DEEPWELL will need to be expanded to perform authentication and role verification functions, instead of providing a direct access API.

• External API will be recreated. No PHP intermediary, but instead directly extended from the web server.