Redis thoughts in future troggle database

This commit is contained in:
Philip Sargent 2022-10-18 23:17:39 +03:00
parent dac52645f8
commit d4276c2b6b

View File

@ -123,6 +123,16 @@ but doesn't really change anything from the perspective of our need to stop user
everything in in-memory dictionaries we may need to write our own asyncio python to do that synchronization. That would be a Bad Thing as everything in in-memory dictionaries we may need to write our own asyncio python to do that synchronization. That would be a Bad Thing as
we are trying to make future maintenance easier, not harder. But it looks like Redis could be the solution for us. we are trying to make future maintenance easier, not harder. But it looks like Redis could be the solution for us.
<p style = "margin-left: 5em; margin-right: 3em"> [ Redis does multi-user concurrency (which is what we need), but most people don't use it like that.
Nearly everyone who uses Redis with Django uses it as a page cache, not as the fundamental store. So public
experience is likely to be less useful than we may hope. Learning to use Redis would probably also mean getting to grips with
Django's <a href="https://docs.djangoproject.com/en/dev/topics/cache/#redis">existing cache system</a>,
which is complex and which we don't use.
<br>
NB We do cache one page per expedition, but explictly in our own python code. So this is a per-process cache which is good for one
person's intensive use, much like Django's
<a href="https://docs.djangoproject.com/en/dev/topics/cache/#local-memory-caching">Local-memory caching</a> ]</p>
<h3>Things that could be a bit sticky 2 - front-end code</h3> <h3>Things that could be a bit sticky 2 - front-end code</h3>
<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 <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 effort to (we managed to remove all the jQuery by using recent HTML5 capabilities). Flask looks interesting