You library is a great one. Cache is mainly adopted when performance matter.
It s ok to say to the readers that for educational purposes you will lock on the middleware so they are aware it should not be the case in real world. But in prodcution/real world your locked section should me as small as possible.
Locking it only when it needs to be locked is how you should do it.
For example, why would you block other requests if one request is writing a response to the client?
Imagine a slow http client that reads 10 bytes per second from your server, that would make a 100 bytes request stay in processing state for 10 seconds. Thus the lock is locked of 10 second and no other request can be processed.
Again, I want to say that your library is great, I'm just stating the fact that locking in the middleware is not the best thing to do.
You library is a great one. Cache is mainly adopted when performance matter.
It s ok to say to the readers that for educational purposes you will lock on the middleware so they are aware it should not be the case in real world. But in prodcution/real world your locked section should me as small as possible.
Locking it only when it needs to be locked is how you should do it.
For example, why would you block other requests if one request is writing a response to the client?
Imagine a slow http client that reads 10 bytes per second from your server, that would make a 100 bytes request stay in processing state for 10 seconds. Thus the lock is locked of 10 second and no other request can be processed.
Again, I want to say that your library is great, I'm just stating the fact that locking in the middleware is not the best thing to do.
Ah, great. Thanks for explaining! I understand what you’re saying 👍🏻
I've updated the project and the article so that the mutex is inside the cache 😊