expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2026-02-25 13:45:20 +00:00
Code Issues Packages Projects Releases Wiki Activity

Documenting troggle reports & fix url refs

Browse Source
This commit is contained in:
Philip Sargent
2022-02-19 21:00:28 +00:00
parent a196791178
commit e3fc406f80
9 changed files with 127 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
handbook/troggle/trog2030.html
View File

@@ -60,7 +60,8 @@ and has stopped breaking so much with every new release.
<p>A real architectural option would be to move to <a href="https://redis.io/">Redis</a> as an in-memory database
instead of using MariaDB. We don't need a fully-fledged database and these new frameworks are less closely tied to
having a SQL database and object-request broker (ORM) than Django is. This ties in neatly which Option 2 above:
reduce our use of the database functions within Django to vanishing point.
reduce our use of the database functions within Django to vanishing point. [Oops. That would be a mistake. It is the SQL database that handles
all the multi-user non-interference, not Django. So unless we want to roll our own real-time software synchronisation.. Better not go there.]
<p>ASGI, which Dango supports from v3.2 too, has the interesting effect that we no longer need a webserver like Apache or nginx to buffer requests. We can use very lightweight <a href="https://www.uvicorn.org/">uvicorn</a> instead.
<h3>Option Zero</h2>
@@ -91,7 +92,7 @@ everything in in-memory dictionaries we may need to write our own asyncio python
we are trying to make future maintenance easier, not harder. But it looks like Redis could be the solution for us.
<h3>Things that could be a bit sticky 2 - front-end code</h3>
<p>There is not yet a front-end (javascript) framework on the client, i.e. a phone app or webpage, which is stable enough for us to commit
<p>There is not yet a front-end (javascript or <a href="https://en.wikipedia.org/wiki/WebAssembly">WebAssembly</a>) framework on the client, i.e. a phone app or webpage, which is stable enough for us to commit
effort to (we managed to remove all the jQuery by using recent HTML5 capabilities). Flask looks interesting
(but <a href="https://adamj.eu/tech/2019/04/03/django-versus-flask-with-single-file-applications/">maybe is only simpler when
starting a new project and doesn't scale to complexity</a> the way Django does, but maybe in 2025 we