| | 1 | = Sahana 4 = |
| | 2 | Sahana Eden was developed as 'S3': Sahana 3[[BR]] |
| | 3 | It was written using the technology choices available at the time.[[BR]] |
| | 4 | Those technologies are still working, however they are falling out of maintenance and are being eclipsed by more modern technologies. |
| | 5 | |
| | 6 | If we are to reimagine Sahana now, what would it look like? |
| | 7 | |
| | 8 | == async == |
| | 9 | I long imagined that a future Sahana would be developed using NodeJS...partly due to it's async, non-blocking design & also because it was the same language as the front-end: !JavaScript.[[BR]] |
| | 10 | However Python now sports great async options which can beat NodeJS performance and Python remains a nicer language to work in, with the great libraries available (& extensible via wrapped C/++ libraries). |
| | 11 | |
| | 12 | Options: |
| | 13 | * Django with Django REST Framework & Channels |
| | 14 | - Django has widespread support & Channels is great for adding WebSockets support, but isn't designed for high level concurrency of the REST API |
| | 15 | * Flask |
| | 16 | - the Quart variant works fully async, but is very bare bones |
| | 17 | * FastAPI |
| | 18 | - the self-documenting OpenAPI , like in DRF, is fantastic |
| | 19 | - fully async via Starlette & Uvicorn |
| | 20 | - can easily add GraphQL API for versionless (Strawberry looks better than Ariadne here) |
| | 21 | |
| | 22 | == reactive javascript == |
| | 23 | jQuery has been great, however is fast going out of fashion to be replaced by reactive frameworks. |
| | 24 | |
| | 25 | Options: |
| | 26 | * ReactJS |
| | 27 | * VueJS |
| | 28 | - use SFCs with Composition API |
| | 29 | |
| | 30 | == What do we need? == |
| | 31 | === Extensibility === |
| | 32 | Extensions should be able to be plugged-in easily & flexibly in languages/frameworks of the extender's choice (or plain HTML/JavaScript!) |
| | 33 | - currently it is a big barrier for 3rd-party developers to have to learn our full-stack framework, rather thsan being able to use the tools they know & love |
| | 34 | |
| | 35 | === Separation of Concerns === |
| | 36 | The full-stack MVC where our base UI is all generated from Python is great for us core developers, but makes 3rd-party extensibility harder.[[BR]] |
| | 37 | Separating into classic front-end & back-end makes development more scalable and flexible. |
| | 38 | |
| | 39 | === Security === |
| | 40 | We want to retain the great hierarchical entity realms that we have in S3, but also make it easier to provide per-record sharing (Evac has some progress in this area). |
| | 41 | |
| | 42 | === Fully Typed === |
| | 43 | * Core Python & !JavaScript should all be fully Type Annotated. |
| | 44 | * Extensions don't need to follow this rule. |
| | 45 | |
| | 46 | === Fully Tested === |
| | 47 | * Core Python & !JavaScript should have 100% Test coverage. |
| | 48 | * Extensions don't need to follow this rule. |
| | 49 | |
| | 50 | === CI / CD === |
| | 51 | * !GitLab runners to run Lint (Pyre for Python Type checking, ESLint for JS) & Testing (!PyTest for Python, Vitest for JS) |
| | 52 | * Options to update Deployed systems |
| | 53 | |
| | 54 | === Deployable via Docker === |
| | 55 | * App, nginx, Database as separate Imagesorechestrated via Compose |
