Next-auth: DynamoDB adapter

[r03]

Summary of proposed feature
Create a new adapter that supports DynamoDB

Purpose of proposed feature
I think DynamoDB is a better fit for serverless.
Maybe also faster for getting sessions but with JWT this is not really a problem.

Detail about proposed feature
I think this could be done with a custom adapter?
https://next-auth.js.org/schemas/adapters#custom-adapters
This would also avoid the TypeORM dependency.

Potential problems
If there is an adapter for DynamoDB, requests for other NoSQL will follow.

Describe any alternatives you've considered
I could also just use the callbacks: https://next-auth.js.org/configuration/callbacks
With JWT and without the email provider this might be the best choice

Please indicate if you are willing and able to help implement the proposed feature.
Maybe I could create this if this would be useful for others.

[iaincollins]

Absolutely, you could write an Adapter for DynamoDB.

Here are some other options specific to AWS that may worth be considering first:

• Amazon DocumentDB is MongoDB compatible
• Amazon Aurora Serverless is also compatible with MySQL and Postgres
• Amazon also offer traditional MySQL, MariaDB and Postgres compatible databases

All of these should work with NextAuth.js and are great with Serverless - and in some cases explicitly designed for Serverless.

We probably won't be removing TypeORM anytime soon - maybe in future, if something like Prisma becomes a viable replacement at any point - but custom Adapters are there to support doing that that.

As DynamoDB has a very specific and unique approach and is designed to solves some specific problems - and can be harder to wrangle and in practice leads to more vendor lock-in other solutions - it might not be the first choice for a lot of folks, but I'd welcome including an Adapter that implements it.

[r03]

I'm new to all this, but I'm not sure if TypeORM is ready for serverless.
The problem is the connection handling.
For mysql there is serverless-mysql
In Aurora serverless there is the Data API but I think you have to use the AWS SDK for that?

But I agree with you that DynamoDB has the risk of vendor lock-in.
Not sure if it is a very specific because if you deploy NextJS with Vercel you get an AWS Lambda per API. DynamoDB could be a good fit,

I'll go with mysql for now. Probably better for my current application.

Thanks for this library!

[ibrahimcesar]

Hi,

I would like to reopen this enhancement issue and give a try.

My use case for DynamoDB first than other AWS options is to leverage better our serverless infrastructure in there since RDBS even Aurora are really expensive and requires provisioning that with DynamoDB you can tweak a long of the way and it will be cheaper and a better fit with lambda functions without the overhead of dealing with dangling connections and so on. Also, is a more cost effective approach than Cognito for the AWS workload.

I'll look at the MongoDB adapter since I think it is the most similar and, I know, is an opinionated approach but I'm thinking of following a single table pattern.

Any ideas / advice / approaches?

Thanks in advance,

[iaincollins]

@ibrahimcesar Sure, happy to re-open this!

I think probably the easiest adapter to crib from would be the FaunaDB adapter, as the adapter that supports MongoDB is the TypeORM adapter, which also supports SQL databases so has some fancy logic in there (TypeORM has some support for MonogoDB, otherwise it too would have been a totally separate adapter).

The TypeORM adapter also has some fancy connection reuse-retry logic you wouldn't need for DynamoDB so I think it might just be a bit confusing, though looking at the queries in both should help! Supporting the debug option to spit out stuff might be helpful.

I think the only thing that might be important for a DynamoDB adapter would be to avoid including the AWS SDK and DynamoDB as dependancy if we wanted to ship support for DynamoDB built into NextAuth.js, as the DynamoDB module alone is bigger than NextAuth.js.

Note: This is akin to how the Default adapter does not include mysql, postgres, mssql or mongodb driver directly, but merely loads it if present, based on the database type defined in the connection string or arguments.

If you are able to get some sort of DynamoDB adapter work, I'd be very happy to help flesh and to work on some of the functions if how they should work is not clear - e.g. for linking / unlinking accounts or session handling.

If we can get something working, we can always look at how the default adapter could be abstracted to automatically load the DynamoDB adapter instead of using the TypeORM logic if a dynamoDB connection string / config object is passed.

[r03]

I don’t use this library anymore but single table pattern is the best and recommended way for dynamodb

[ibrahimcesar]

Hello @iaincollins ,

Started work in the integration and was able to save on DynamoDB already but I need more help with sessions handling.
But first, what I done so far:

• I'm using AWS SDK and DynamoDB as a dependency in my Next Auth application and just passing the instance to my adapter.
• As happen with other integrations, it will be necessary to create a "seed" to create the Table, I'm creating a SAM yml to help with that

Now my questions:

1. I was not able to in the workflows create session be invoked without turn JWT to false. I was planning to do both, as I think is possible using other databases... I did not find on the code how to trigger this, without touch in logic in other areas (I'm besides several console logs, working only in code on the adapter itself. There's a way to do this? So far I did not find:

https://github.com/nextauthjs/next-auth/blob/5126f4e3428f2b4b8ebdd38b10066edfdd4ea2fa/src/server/lib/callback-handler.js#L99

1. When I tried to manage the sessions with jwt as false I found out that: https://github.com/nextauthjs/next-auth/blob/5126f4e3428f2b4b8ebdd38b10066edfdd4ea2fa/src/server/lib/callback-handler.js#L52

else {
        session = await getSession(sessionToken)
        if (session && session.userId) {
          user = await getUser(session.userId)
          isSignedIn = !!user
        }
      }

After getSession return the value, makes another call to getUser, since DynamoDB price model is based on write/reads, I always try to optimize the access patterns, and in this case I would do two calls to get a information I can get in only one call, using index and sort keys.

Great work on the documentation and the code! I just need a little help to navigate the workflows!

Thanks in advance,