is it ok to have two different interceptors
about (in memory) database, one for a "table" X and other for "table" Y?
@leandrotk100, I’ll hesitantly say yes but I don’t know your use case
I have a in-memory database:
{:users [...]
:connections [...]}
I implemented a simple CRUD to the users, and I used a db-interceptor
specific for the users
Now I was thinking about the connections
and (maybe) another db-interceptor
, something like db-connection-interceptor
In general, I implement an interceptor to create/get a connection and make it available on the context for other interceptors
I may also implement an interceptor which fetches an entity from the db and makes it available on the context/request as well.
In general, I think it’s good practice to limit handlers to response formatting and push data retrieval to interceptors