@sgf AP is almost designed to make decoupling hard because of what I've been thinking of as the "layer conflation" problem: the munging of the data model, the API, and the API's protocol. Also that it does not scale out of the box except for simple use cases.
ATproto separates this with the separation of components baked into the design (e.g., the app layer) and the explicit declaration of subdialects (lexicons).
I'm not doubting that the queue is coupled to the cache, but I have a suspicion that there is a specific example you are referring to that I probably am not aware of.
What queue (or part of the queue) is coupled to the cache?
You can separate them and run separate redis instances, but the default install uses redis for caching, in-flight processing, streaming, and queuing and they require different configurations to be efficient at any of them
Which you can even do and get away with, but it limits your ability to be flexible based on the needs of your project—or set up things for test—because Redis is a "datastore that can be used as a queue" more than it is a queue itself
@manlycoffee So to compare what I have in mind, what if you used redis (or memcached) for caching and queuing was communicated over a dedicated queuing protocol with multiple implementations, like STOMP or AMQP?
Now it is easy to configure these separately, spin up a lighter weight queue for test, etc.
It's minor compared to separating the web interface, but it also gives you so much more flexibility for building systems and swapping out pieces basically "out of the box."
Add comment