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
With SuperTokens middleware it will work for configured SuperTokens routes just like below.
request -> middleware -> response
With that, some important aspects of the application might lose.
No guards called. Guards can be used to restrict ip address, or restrict geolocation. There will be no restrictions for SuperTokens routes.
No interceptors called. Interceptors can be used for metrics, all kind of analysis and logs. There will be no analysis about what Supertokens routes called with what frequency, in what times and many more.
To give an example, commonly used middlewares in NestJS are cors() and helmet() middlewares. They do not early terminate request so interceptors, guards and other middlewares also run. Note that cors() might not be the perfect example here.
So, current NestJS integration with middlewares does not seem right to me.
As an initial idea, what can be done is, creating a NestJS module with proper controllers to serve routes instead of middleware. With that, users can register the module into their apps and everything will be in the regular request-response cycle of NestJS.
However this can be a great maintenance burden for the team. Maybe outsourcing main functionality from sdk and keeping that in a base that would be used in sdk and NestJS module can greatly reduce the maintenance burden.
The text was updated successfully, but these errors were encountered:
From @porcellus - "right now my best recommendation is to add all the ST routes the recipes you use expose into a controller in your code and add just pass the necessary params into our middleware. This will basically make our middleware run in the appropriate phase. If this solution works for you, I'm happy to help make this work."
From @porcellus - "right now my best recommendation is to add all the ST routes the recipes you use expose into a controller in your code and add just pass the necessary params into our middleware. This will basically make our middleware run in the appropriate phase. If this solution works for you, I'm happy to help make this work."
I have some concerns using
SuperTokens
with aNestJS
app.Currently
SuperTokens
sdk is used as amiddleware
. This is also described in theNestJS
integration documentation ofSuperTokens
.However here is how
NestJS
request-response cycle works.request -> middleware -> guard -> interceptor (before) -> pipe -> controller -> service -> controller -> interceptor (after) -> filter (if applicable) -> response
With
SuperTokens
middleware it will work for configuredSuperTokens
routes just like below.request -> middleware -> response
With that, some important aspects of the application might lose.
guards
called.Guards
can be used to restrict ip address, or restrict geolocation. There will be no restrictions forSuperTokens
routes.interceptors
called.Interceptors
can be used for metrics, all kind of analysis and logs. There will be no analysis about whatSupertokens
routes called with what frequency, in what times and many more.To give an example, commonly used middlewares in
NestJS
arecors()
andhelmet()
middlewares. They do not early terminate request sointerceptors
,guards
and othermiddlewares
also run. Note thatcors()
might not be the perfect example here.So, current
NestJS
integration withmiddlewares
does not seem right to me.As an initial idea, what can be done is, creating a
NestJS
module with propercontrollers
to serve routes instead ofmiddleware
. With that, users can register themodule
into their apps and everything will be in the regular request-response cycle ofNestJS
.NestJS prometheus package can be inspected for inspiration https://github.com/willsoto/nestjs-prometheus
However this can be a great maintenance burden for the team. Maybe outsourcing main functionality from sdk and keeping that in a base that would be used in sdk and NestJS module can greatly reduce the maintenance burden.
The text was updated successfully, but these errors were encountered: