Let me summarise what it does since the docs are still in progress: In order to avoid DDOSsing the main database server, Flows attempts to either use a readonly, slave database or an asynchronous one (see https://github.com/nmeri17/Tilwa/issues/20), and has some modes about what kind the outgoing request is. The idea is to store outgoing request, then after responding to the current request, we visit IDs in that payload in anticipation of user's next request.
I suspect some developers may not be receptive to this, so in meta Flow fashion, let me preemptively ask: Can this concept be repurposed towards another end? Something the existing code can be adapted to. Please feel free to peruse https://github.com/nmeri17/Tilwa/tree/close-route-queue/nmeri/tilwa/tests/Integration/Flows to get a tentative idea of how they operate in real life (sans an actual redis queue). They are closest to what that section of the docs will look like.
If, on the other hand, you're absolutely on board with it, awesome! In that case, I have a few questions:
Can you suggest additional ways to improve the component as a whole?
The flows for each user is extracted, updated and stored again. Will you use redis tags, instead, to update the cache whenever a resource bearing that tag is updated? I couldn't come around this implementation detail but something tells me tags can be used to update caches in memory
Let me summarise what it does since the docs are still in progress: In order to avoid DDOSsing the main database server, Flows attempts to either use a readonly, slave database or an asynchronous one (see https://github.com/nmeri17/Tilwa/issues/20), and has some modes about what kind the outgoing request is. The idea is to store outgoing request, then after responding to the current request, we visit IDs in that payload in anticipation of user's next request.
I suspect some developers may not be receptive to this, so in meta Flow fashion, let me preemptively ask: Can this concept be repurposed towards another end? Something the existing code can be adapted to. Please feel free to peruse https://github.com/nmeri17/Tilwa/tree/close-route-queue/nmeri/tilwa/tests/Integration/Flows to get a tentative idea of how they operate in real life (sans an actual redis queue). They are closest to what that section of the docs will look like.
If, on the other hand, you're absolutely on board with it, awesome! In that case, I have a few questions:
The flows for each user is extracted, updated and stored again. Will you use redis tags, instead, to update the cache whenever a resource bearing that tag is updated? I couldn't come around this implementation detail but something tells me tags can be used to update caches in memory