We have begun trying to add supertokens to our application and ran into a hiccup. We run our application stack on Cloudflare (CF) workers infrastructure. While they do have a nodejs compatability mode, they do not support all of nodejs apis. https://developers.cloudflare.com/workers/runtime-apis/nodejs/ The nodejs software you provide has dependencies for which they don't have support, like zlib (we didn't get too deep into a full list). Is there any chance of getting a library that is cloudflare compatible?

Hey @kingmesal we will be working on this, this week. Please stay tuned.

@kingmesal Most Auth recipes are functional in Cloudflare Workers using

supertokens-node

. The only known issue is OAuth compatibility with Apple. We're actively working on determining the best approach for full Cloudflare Workers support. We will keep you updated.

Our primary application in Cloudflare uses React.

Oh i mean on the backend APIs. Are you using cloudflare workers?

The backend is all in workers / pages. If you are not familiar with the pages architecture, they effectivley provide a light wrapper around the worker similar to itty-router (could be itty-router or hono under the covers).

I see.

we have been able to do a LOT with their architecture. The main thing is, as long as it isn't a dependency on the node runtime, everything works.

gotcha

Hopefully it isn't too much effort 🤞

hopefully!

When going through, I was trying to adapt the awsLambda framework within supertokens-node. Looking through the code, it looked like it wouldn’t be such a crazy lift to make it cloudflare compatible. There were only a few instances of node specific libraries being used which looked easy enough to convert. The inflate lib that gets called uses zlib which might be a little tricky. If it’s helpful I could set up a minimal repro for you

@at_supertokens would a repo from @landturn be helpful? Or do you already have something setup for this?

here is a repro: https://github.com/landonturner/supertokens-cloudflare

thanks @landturn

yeah importing supertokens-node really

right i see.

@at_supertokens in your testing, since you got it to work (other than apple login), i wonder why importing supertokens-node didn't show you this error.

np. let me know how i can be of assistance

Hi @landturn! The errors you're encountering stem from a misconfiguration of node_compat. To address this, modify the dev:start command as follows:

"dev:start": "wrangler pages dev static --node-compat"

This would fix the error but the job is not done yet.

supertokens-node

provides an API to support custom framework that can be utilized to support CF workers. If you are okay with using Hono then I already have a working for you [here](https://github.com/anku255/t4-app/tree/supertokens-auth/packages/api/src). If Hono isn't your choice, you can either implement a similar solution or reach out for assistance.

we do not use hono

In terms of not using hono, thats not an issue. We can work with any alternative you have. Let us finish an example with hono, and then you can easily adapt it to work with anything else.

so cloudflare pages uses a directory structure style of routing. you can kind of get a feel for it by looking at the following directory structure

~/src/gitlab.com/leed-ai/Services/cms/apps/backend/functions
> tree
.
└── api
    ├── _middleware.ts
    ├── assets
    │   ├── [assetId].ts
    │   ├── create.ts
    │   ├── favicon.ts
    │   └── index.ts
    ├── company
    │   ├── [companyId]
    │   │   └── provision.ts
    │   └── index.ts
    ├── debug.ts
    ├── invite
    │   └── [inviteId].ts
    ├── labels
    │   ├── [labelId].ts
    │   └── index.ts
    ├── notifications
    │   └── index.ts
    ├── page
    │   ├── [pageId]
    │   │   ├── comment.ts
    │   │   ├── contentHtml.ts
    │   │   └── index.ts
    │   └── index.ts
    ├── pagetypes
    │   ├── [pageTypeId].ts
    │   └── index.ts
    ├── schedule
    │   └── index.ts
    ├── stats
    │   └── index.ts
    ├── templates
    │   ├── [templatePath].ts
    │   └── index.ts
    └── user
        ├── [userId].ts
        ├── index.ts
        ├── invite
        │   └── [inviteId].ts
        ├── login.ts
        ├── me.ts
        └── session.ts

17 directories, 34 files

yea, we just have to figure out how the superokens middleware would be added to this. It's just like a traditional middleware, so it should be fine. The one thing is that the middleware we have reads from the request object and writes to the response as well, so the req and res provided to it need to conform to a certain interface. But that should be fine

yeah will probably be fine. there are a couple ways to do middleware, stick functions in the

_middleware.ts

file, or provide specialized functions that you chain together like this https://github.com/landonturner/supertokens-cloudflare/blob/d744982b0c7dc577758a7d1ec506c983d0e67539/functions/api/test.ts#L30. https://developers.cloudflare.com/pages/platform/functions/middleware/

Hey @landturn , we have updated the node sdk to be fully compatible with cloudflare now (As long as you use the node runtime). We are also very close to having finished an example app with Honojs, which you can take inspiration from in order to add our backend SDK to your cloudflare worker.

In case it is helpful: https://developers.cloudflare.com/pages/platform/functions/plugins/ The model is quite simple:

/functions
    /endpoint1
    /endpoint2

Each endpoint can use the pages middleware model that works like this:

javascript
export const requestHandler = async (context: EventContext<Env, string, SessionData>): Promise<Response> => {
    const response = await context.env.FUNCTIONS.fetch(context.request);
    return response;
};

export const onRequestPost = [authProvider, corsCheck, requestHandler];
export const onRequestOptions = [authProvider, corsCheck];

Then cloudflare pages uses the onRequest* to build the router.

Gotcha. Here is an example (with hono) on how to add our middleware: https://github.com/timothymiller/t4-app/blob/266b423a2b314ce9f165b9a3f747691f559b87d6/packages/api/src/supertokens/middleware.ts (this is still WIP). The basic idea is that you first create an instance of

PreParsedRequest

as shown here ( https://github.com/timothymiller/t4-app/blob/266b423a2b314ce9f165b9a3f747691f559b87d6/packages/api/src/supertokens/middleware.ts#L30C1-L30C1). You need to map the functions from

context

to the respective functions required to create an instance of

PreParsedRequest

. You then create a

CollectingResponse

instance (line 39). Then you call the supertokens middleware (line 43) which either returns an error or a boolean (handled). If error, then you essentially propagate that to your app's error handler. Else, if handled, it means our middleware handled the request and created a response (the response body, headers are in the instance of

CollectingResponse

). This can happen if you call an API that our middleware exposes (like sign in, sign out etc). In this case, you have to create a response object as understood by your framework and transfer the body, headers, status code and cookies (line 50-54) In case not handled, it means that it's a request to one of your APIs, and you pass it on to your other APIs, or return a 401 (i think in your case, it should be 401 since the auth middleware will only run if you query /auth/* anyway.

Did you guys done creating that example app with honojs?

@at_supertokens might have the example app link

Oh sorry I didn't see that

Hi @James ! You can use [this](https://github.com/timothymiller/t4-app/tree/supertokens-auth/packages/api) repo as an example for using supertokens with HonoJS.