Serverless: A community case study

[flexdinesh]

Hey everyone! We’re noticing an increasing amount of interest and chatter about Serverless Keystone in our community slack, GitHub issues and discussions. Serverless support is in our roadmap and we have already started experimenting with a few ideas. We’re hoping to use this discussion to get feedback from the community on what serverless means for you and what your expectations are when you think about serverless support for Keystone.

We’d appreciate your thoughts on the serverless problem space and how Keystone fits into the mental model. Here are a few questions to kick start the discussion.

1. Why do you intend to run Keystone on serverless environments?
Eg. Save hosting cost, etc.

2. What does your end-to-end stack look like?
Eg. Keystone Server and Next.js frontend, Keystone server within Next.js routes, I only use Keystone as an API, etc.

3. Where do you host your database?
Eg. Provisioned database provider like Heroku/DO, in VPC closer to my server, etc.

4. How do you intend to keep your database latency low when you are running Keystone in serverless environments?
Eg. By using a managed database from the same serverless provider (Lambda and RDS).

5. How do you plan to manage the database connection problems of serverless runtimes?
Eg. By using prisma dataproxy, etc.

[kerbe]

Nice to see that this goes forward, and has received attention! Here are some answers to those questions listed:

1. Why do you intend to run Keystone on serverless environments?
   Saving in costs is one aspect, but actually not even main thing for me.
   In my plans, Keystone in serverless environment is possibly increasing security, as ideally it isn't running constantly, and not accessible by all automated worms scanning the internet. At same time there is less stress to keep everything up-to-date, compared for example some WP installation with tons of plugins.

2. What does your end-to-end stack look like?
   I am building stack where Keystone is doing CMS backend role, and frontend is either 11ty or Next. Websites/applications that don't need constant tweaking and not highly customized business logic in frontend is my main intention in using Keystone.

3. Where do you host your database?
   Same place where serverless keystone would be running, most likely. Currently using MongoDB Atlas on many projects.

4. How do you intend to keep your database latency low when you are running Keystone in serverless environments?
   AWS Lambda & AWS RDS PostgreSQL indeed.

5. How do you plan to manage the database connection problems of serverless runtimes?
   I haven't ran into any serious database connection problems with my current projects that utilize AWS Lambda & MongoDB Atlas. If for some reason AWS Lambda & AWS RDS PostgreSQL would have more problems, that's bridge I'd have to cross at that time.

So in my use cases and intended uses Keystone wouldn't be something that is accessed on daily basis, most likely not even weekly. All that times when there is no use, it could be sleeping, saving costs and reducing attack vector for site/application.

[jlarmstrongiv]

1. Why do you intend to run Keystone on serverless environments?
Scalability, save hosting costs, match the rest of our microservices stack, ease of spinning up new dev/staging environments, etc. I really liked the now-deprecated experimental Node API because I could import it into other microservices if needed.

2. What does your end-to-end stack look like?
KeystoneJS Server and Admin UI

3. Where do you host your database?
Managed PostgresQL from Digital Ocean, Neon, and AWS RDS and Aurora.

4. How do you intend to keep your database latency low when you are running Keystone in serverless environments?
Only a problem in cold starts. Can be mitigated by appropriate lambda memory size, provisioned concurrency, and lambda best practices like reusing db connections. If I were able to bundle @keystone-6/core to avoid Container Images, that’d help latency a lot.

5. How do you plan to manage the database connection problems of serverless runtimes?
The only thing you need is a database connection pooler. Both Digital Ocean and Neon include them with their managed databases. I’ve been using database connection poolers successfully with AWS Lambda for the past few years. Amazon Aurora PostgreSQL also manages connections automatically, but VPCs add latency to the cold start.

[mariomnts]

Thanks for opening this issue and looking forward to the future of Keystone serverless 🙂

1. Why do you intend to run Keystone on serverless environments?
Scalability, ease of deployment, less infra to maintain

2. What does your end-to-end stack look like?
Only Keystone GraphQL API. No admin is used at all

3. Where do you host your database?
AWS RDS

4. How do you intend to keep your database latency low when you are running Keystone in serverless environments?
Managed DB from same serverless provider

5. How do you plan to manage the database connection problems of serverless runtimes?
This is an still open issue to me

[junaid33]

1. Why do you intend to run Keystone on serverless environments?
Serverless is the future. Also, serverless apps can be deployed serverfully or serverlessly. Serverful apps can only be deployed using a server.

2. What does your end-to-end stack look like?
Openship uses multi-tenancy for our users. Every user gets their own server and database. When we deploy Openship for our users, we deploy one application (Next.js & withKeystone) that has the frontend and backend. In production, Keystone offers a graphQL API, but not the Admin UI. The Admin UI would also have to served at a custom path (/admin) since our main application is taking the index path.

3. Where do you host your database?
Railway. When a user signs up for Openship, we spin up a project on Railway, create a database and server. The build creates the tables and when the user goes to the website, they are prompted to create the Admin user for the instance.

4. How do you intend to keep your database latency low when you are running Keystone in serverless environments?
Railway offers serverful hosting and uses a running server for Next.js so we haven't experienced high latency. Openship is also open-source and we have many people self-hosting Openship on Vercel since it's easy and simple. For most people self-hosting, their usage won't affect database latency too much. We also advise them to use Prisma Proxy or something like Stellate once their usage increases.

5. How do you plan to manage the database connection problems of serverless runtimes?
Our managed hosting uses serverful hosting so we don't face database connection issues either. Users self-hosting our app on Vercel seem fine for low/medium usage, but we advise a proxy once they reach higher usage so they don't hit connection limits.

All in all, I have Next.js and Keystone.js working and deployed as 1 server for our production clients. Giving them an admin UI would be even better.

[flexdinesh]

These are all great. Clearly shows the diversity in how Keystone is used in a variety of stacks and use cases. Thanks for sharing. Please keep 'em coming.

[DiesIrae]

1. Why do you intend to run Keystone on serverless environments? Eg. Save hosting cost, etc.

To easily publish test apps for our CI

2. What does your end-to-end stack look like? Eg. Keystone Server and Next.js frontend, Keystone server within Next.js routes, I only use Keystone as an API, etc.

• Keystone server over K8S
• Backend apps in Node.js and Python
• Frontend apps in React vanilla & Next

3. Where do you host your database? Eg. Provisioned database provider like Heroku/DO, in VPC closer to my server, etc.

K8S

4. How do you intend to keep your database latency low when you are running Keystone in serverless environments? Eg. By using a managed database from the same serverless provider (Lambda and RDS).

Not an issue as it won't be for production

5. How do you plan to manage the database connection problems of serverless runtimes? Eg. By using prisma dataproxy, etc.

Probably not an issue as it won't be for production

[relusion]

1. Why do you intend to run Keystone on serverless environments?
Save costs.

2. What does your end-to-end stack look like?
React Js front end hosted on Azure Static Web Apps connected with Keystone hosted on serverless Azure Container Apps.

3. Where do you host your database?
Azure Database for PostgreSQL flexible server

4. How do you intend to keep your database latency low when you are running Keystone in serverless environments?
Not an issue at the moment.

5. How do you plan to manage the database connection problems of serverless runtimes?
Not an issue.

[jordie23]

1. Why do you intend to run Keystone on serverless environments?

We don't right now, but if it's an option and it's easy, then we would. Cost might be a good benefit. We currently use AWS Fargate to run keystone and I'd imagine Lambda would be cheaper.

Our main benefit might be helping fix what is actually more of a symptom. At the moment, a keystone container currently will sometimes run out of memory and die. We believe it's due to N+1 issues and deep relationships causing a crazy number of DB queries to be run and data to be loaded. It can otherwise result in slow responses. And with the container going down, other requests in progress or other incoming requests that haven't been diverted to another container will results in errors.

We're creating custom resolvers to address this when we see it, but sometimes we just need to get something out quick regardless of performance, and it results in this container dying issue. With serverless I'd imagine the collateral damage would be minimised as other requests wouldn't error out by going to the same container before a new one cycles in (or at least less of them would?).

2. What does your end-to-end stack look like?

Next.js frontend that uses keystone via the graphql API. So if it was deployed in a lambda we'd need to think about how we'd access it, perhaps a simple API gateway setup or Lambda's new function URLs feature.

3. Where do you host your database?

AWS RDS - postgres. Separate readers and writer instances

4. How do you intend to keep your database latency low when you are running Keystone in serverless environments?

By using a managed database from the same serverless provider (Lambda and RDS).

5. How do you plan to manage the database connection problems of serverless runtimes?

AWS provides db a connection proxy that we'd maybe make use of https://aws.amazon.com/rds/proxy/

[mariomnts]

Note that RDS Proxy don't solve any issue of connection pooling because of the way it handles the type of connections Prisma opens: https://www.prisma.io/docs/guides/deployment/deployment-guides/caveats-when-deploying-to-aws-platforms#aws-rds-proxy

[supagu]

1. Why do you intend to run Keystone on serverless environments?
   Reduced costs.
   Reduced complexity of app - the rest of our app is serverless but our CMS always needs a dedicated server. This would allow us to unify our architecture better.

2. What does your end-to-end stack look like?
   Currently we use wordpress or Strapi for CMS
   Next.js frontend, which we generally do static exports and run them from s3 buckets.

3. Where do you host your database?
   If we have databases at all, we just hook into the CMS's API. If using Strapi, we use AWS RDS.

4. How do you intend to keep your database latency low when you are running Keystone in serverless environments?
   Using AWS Lambda's + RDS.

5. How do you plan to manage the database connection problems of serverless runtimes?
   Typically we cache CMS' API in s3 buckets where possible.

[johnboylesingfield]

1. Why do you intend to run Keystone on serverless environments?

As a developper working for artists and non-profits institutions, I need a solution to build maintainable websites at low cost. A fully serverless Keystone CMS with the admin UI could greatly help me achieve that goal, while allowing me to use modern and flexible technologies like Prisma.

One other obvious solution would be to use a provider like Xata or Airtable as a CMS and database, which would be very simple to use for users and take care of everything. This approach however lack in flexibility: I would be forced to work with a proprietary technology on a free tier that can change anytime. Migrations could also be a challenge.

I come from WordPress land. Although being terrible in a lot of areas, WordPress offer some degree of flexibility and stability, as it is (relatively) easy to update and migrate to virtually any hosting service out there. I've been trying to find a replacement for it, but it is not so easy in a context where human/financial ressources are low.

A serverless CMS like Keystone would check many boxes I've been wanting to check for a long time. A light and stable CMS integration with Next.js would provide me with tons of flexibility, as I can deploy it pretty much anywhere (not only serverless). Working with high-level building blocks that are coming from a trusted, open source tech like Prisma also makes me feel I won't learn something too specific that will get obsolete in six months because of the next cool thing. Last but not least, it reduce complexity by a significant margin (again, this is important due to the limited time/money ressources I have).

2. What does your end-to-end stack look like?
   Keystone CMS + Next.js frontend hosted on Vercel.

3. Where do you host your database?
   Postgres Vercel.

4. How do you intend to keep your database latency low when you are running Keystone in serverless environments?
   Not an issue, I think (see answer to question 3).

5. How do you plan to manage the database connection problems of serverless runtimes?
   Not an issue, I think (see answer to question 3).

[Utzel-Butzel]

1. Why do you intend to run Keystone on serverless environments?
   Faster and simpler deployment

2. What does your end-to-end stack look like?
   Currently Keystone Instances on fly.io and AWS Elastic Beanstalk, frontends mostly on Vercel or directly inside S3 buckets (used as a storage for translation data).

3. Where do you host your database?
   AWS RDS, fly.io most likely moving to Vercel for small applications

4. How do you intend to keep your database latency low when you are running Keystone in serverless environments?
   Trying Vercel with it's own Postgres Database service in the future, usually latency is not a big issue since our next.js frontends do there own caching

5. How do you plan to manage the database connection problems of serverless runtimes?
   For a more developer documentation oriented project, where we can't have a database due to organizational restrictions we try using Tina.io and store the data inside Git (mdx files with Frontmatter).

[sladg]

1. Why do you intend to run Keystone on serverless environments?
   AWS Lambdas. We run everywhere there, saving in costs as well as ease of setup. Simpler deployments using ton of existing tools.

2. What does your end-to-end stack look like?
   Keystone Server (including admin view) and Next frontend.

3. Where do you host your database?
   AWS, RDS in private VPC or Lightsail to save costs on smaller projects.

4. How do you intend to keep your database latency low when you are running Keystone in serverless environments?
   Lambda and RDS combination. Same provider. Latency is lesser of issue really. There are ways to improve if needed. I would say that majority of community is not primarily concerned by latency. I.e. let us make our decision and bear the consequences <3

5. How do you plan to manage the database connection problems of serverless runtimes?
   Serverless Aurora, pg_bouncer or pooled connections.