You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have multiple types of document with different data in them that have different middleware requirements.
The solution I would like
The ability to set up different middleware routes based on the HTTP path of the original request, query parameters etc.
Alternatives I have considered
Running separate HocusPocus instances for each document type. We do this in some places but this puts more strain on the rest of our deployment infrastructure and is less flexible for taking advantage of our existing resources.
Branching inside middleware blocks but its messy and error prone, everything constantly has to filter the type of document before it can do anything with it.
Additional context
There's some thought to be had around how this would work with multiplexing and subdocuments as they are likely to be documents of different types and may have different storage needs etc.
Some of our views have access to documents of multiple types and it would be nice if they can benefit from multiplexing also.
The text was updated successfully, but these errors were encountered:
@georeith I'm not sure I understand what you mean by middleware 🤔 Are you talking about onChange etc. hooks that need to run for certain documents only (e.g. those prefixed like article.123)?
@georeith I'm not sure I understand what you mean by middleware 🤔 Are you talking about onChange etc. hooks that need to run for certain documents only (e.g. those prefixed like article.123)?
Yes by middleware I mean extensions really. E.g., something like this on setup:
The problem I am facing
We have multiple types of document with different data in them that have different middleware requirements.
The solution I would like
The ability to set up different middleware routes based on the HTTP path of the original request, query parameters etc.
Alternatives I have considered
Running separate HocusPocus instances for each document type. We do this in some places but this puts more strain on the rest of our deployment infrastructure and is less flexible for taking advantage of our existing resources.
Branching inside middleware blocks but its messy and error prone, everything constantly has to filter the type of document before it can do anything with it.
Additional context
There's some thought to be had around how this would work with multiplexing and subdocuments as they are likely to be documents of different types and may have different storage needs etc.
Some of our views have access to documents of multiple types and it would be nice if they can benefit from multiplexing also.
The text was updated successfully, but these errors were encountered: