Hi 👋 I have some concerns using

SuperTokens

with a

NestJS

app. 😦 Currently

SuperTokens

sdk is used as a

middleware

. This is also described in the

NestJS

integration documentation of

SuperTokens

. 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 configured

SuperTokens

routes just like below.

request -> middleware -> response

With that, some important aspects of the application might lose. 1. No

guards

called.

Guards

can be used to restrict ip address, or restrict geolocation. There will be no restrictions for

SuperTokens

routes. 2. 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. So, current

NestJS

integration with

middlewares

does not seem right to me. What do you think about the concerns? Are there any plans to enhance

NestJS

integration?

hey @mansuralikoroglu thanks for this question. @porcellus can help here

hi, you are right - our nestjs integration is not as good as it should be, and we do have plans on improving them although I'm not sure where they are on our roadmap

Maybe. I just tested it with some interceptors and guards and some other stuff put that in an example before posted that question and in all kind of requests (I sent from an html page + thunder client, did not check preflights.) all nestjs flow run.

it only reminates preflights. Anyway, I'll check this, but you could try to add the supertokens routes to a separate controller yourself, that'd solve the issue but it's a bit more involved than ideal.

I see 😦

you could create an issue about this on our github and track it via that. Or, you could even make a PR for this in our node SDK if that helps you

Maybe outsourcing main functionality from

sdk

and keeping that in a

base

that would be used with

sdk

and

NestJS

module can greatly reduce the maintenance burden. TBH I did not check current sdk's code. Maybe it's already like that.

you are correct, we'd need something similar, however quite a bit more complex since our exposed routes are different based on the enabled recipes/config.

I see. After some considerations I might contact you for your help. I don't really wanna take your time so even if this solutions temporarily works for us, I will try to handle stuff and just ask for your assistance.

ok, feel free to ping us 🙂

I also created an issue for further changes and enhancements to

NestJS

integration. https://github.com/supertokens/supertokens-node/issues/593

happy to help 🙂

Information on the topic For now we decided to go with middleware approach to avoid heavy workload just for a workaround and put a todo/warning comment about none of our analytics or security guards will work with /auth routes. We are tracking the github issue for better implementation for nestjs on supertokens side. Thanks a lot once again for your support. 🙂

Great. We will try and find some time in the coming months for this - but you should know that we have other more important priorities. In the meantime though, feel free to poke around our sdk code and see if you can figure it out yourself 🙂

🙂 👍