Prisma Data Proxy / Accelerate / Pulse Mini-guide + Help Me

First off, shoutout to all RW contributors. Y’all have a community post or guide for just about every problem I encountered that I couldn’t reason through.
I saw Danny’s older post starting a couple years back about connection pooling, but I am getting some clarification from the RW community here between Data Proxy, Accelerate, and Pulse as well as help with my first foray into connection pooling.
I knew from our last busy season that I might need to look into connection pooling from a few times I hit connection limits (I have been using Redwood on Vercel and Netlify since v1 now).
I started by perusing the Connection Pooling Guide a month or so ago here: [Connection Pooling | RedwoodJS Docs](https://Connection Pooling)

However, I noticed the Prisma site seemed to be updating information on the Data Proxy and sure enough I see Prisma on the last Redwood Partner Talks with Accelerate and Pulse.

Am I mistaken in saying that Accelerate will be what the original Data Proxy was for connection pooling and then Pulse will be real-time events triggered by the db?

So to get as far as I did let’s walkthrough what I already did to help other catch up:

I dove in with a v6.0 Redwood project (need Prisma v5) using the [Prisma Accelerator Docs] (Getting started with Accelerate)

I decided to dive on in so let’s catch people up to where I got to with Accelerate.

I needed to sign up for Prisma’s Cloud Platform with Github:
Prisma Cloud Platform

You’ll be shuttled to the dashboard for the Cloud Platform:

Create a “New Cloud Project” on the Dashboard:

Enable Accelerate:

You’ll need your old DB connection string, and to choose a location close to your DB:

Click Generate API Key:

Copy the new connection string, this will be your project’s new DATABASE_URL.

This will be used to update your .env file. Your DATABASE_URL is now the accelerate URL generated, and the DIRECT_DATABASE_URL is the old connection string that was DATABASE_URL:

# .env
DATABASE_URL="prisma://accelerate.prisma-data.net/?api_key=__API_KEY__"
DIRECT_DATABASE_URL="postgresql://user:password@host:port/db_name?schema=public"

You’ll also need to update the schema.prisma file to have a “directUrl” so that some of the Prisma functionality can still work not through the proxy:

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")
  directUrl = env("DIRECT_DATABASE_URL")
}

Instead of the suggested npm use yarn to add the Prisma Client Extension:

yarn add @prisma/extension-accelerate

then:

yarn rw prisma generate --accelerate

***I Initially had this wrong as ‘npx prisma generate’ like prisma docs show

After that I needed to updated the db.js file in api/src/lib/db.js.

This is where I had some trouble. I couldn’t get logging working.
My code before has this:

export const db = new PrismaClient({
  log: emitLogLevels(['info', 'warn', 'error']),
})

I was able to get Accelerate working without logging by changing the db line to:

export const db = new PrismaClient().$extends(withAccelerate())

However, logging seems to be breaking if I do:

export const db = new PrismaClient({
  log: emitLogLevels(['info', 'warn', 'error']),
}).$extends(withAccelerate())

With the following error:

Is the logging here technically a middleware? Prisma gives this heads-up as part of the Accelerate Docs:
“If you are using Prisma Middleware in your application, make sure they are added before any Prisma Client extensions (like Accelerate). For example:”

const prisma = new PrismaClient().$use(middleware).$extends(withAccelerate())

Anyways thought I’d share where I got to with Accelerate and what looks to be the new Prisma Connection Pooling

Btw: I am on Redwood 6.0.0-rc.662 and Prisma 5.0.0. I know Prisma has a 5.1 that I can upgrade to, but wanted to see where I got with what’s just on v6.0 baked -in.

2 Likes

Hey there :wave: !
So you should be using the middleware before extending the client. The snippet below resolves the issue for me.

import { PrismaClient } from '@prisma/client'
import { withAccelerate } from '@prisma/extension-accelerate'

import { emitLogLevels, handlePrismaLogging } from '@redwoodjs/api/logger'

import { logger } from './logger'

const prisma = new PrismaClient({
  log: emitLogLevels(['info', 'warn', 'error']),
})
// this is where the middleware logic is applied
handlePrismaLogging({
  db: prisma,
  logger,
  logLevels: ['info', 'warn', 'error'],
})

// then we're extending the PrismaClient and exporting it 
export const db = prisma.$extends(withAccelerate())

Let me know if it helps solve the issue for you!

1 Like

This fixed the first issue.

It looks like I still had some weirdness after that.
I might have missed it in the docs, but if you used Data Proxy and are now using Accelerate, or if like me you setup Accelerate then realized Prisma Studio would not work with Prisma v5 or v5.1 (though it might with 5.2 Prisma now). I had tried to use Data Proxy to get the Cloud Platform version of Prisma Studio to edit my DB data which then got errors of the clients fighting:

Error validating datasource `db`: the URL must start with the protocol `postgresql://` or `postgres://`.To use a URL with protocol `prisma://`, you need to either enable Accelerate or the Data Proxy. Enable Accelerate via `prisma generate --accelerate` or the Data Proxy via `prisma generate --data-proxy.` More information about Data Proxy: https://pris.ly/d/data-proxy

I’ll come back and try wiping node modules and reinstalling. I do have to say when I didn’t mess with mixing Data Proxy and Accelerate performance was good and it seems like about the easiest way to setup SWR with Redwood.

Once Accelerate is setup you just need to add the “cacheStrategy” to your queries you want to use caching with from:

export const batchReports = () => {
  return db.batchReport.findMany()
}

over to:

export const batchReports = () => {
  return db.batchReport.findMany({
    cacheStrategy: {
      ttl: 30,
      swr: 60,
    },
  })
}

The query before would take 100-180ms and Accelerate dropped them down sub 15ms when it was a cache hit:

1 Like

Thanks for the update @QuinnsCode! Version 5.2 now has the ability to automatically detect whether Accelerate or a direct database connection is in use. Additionally, it includes support for Prisma Studio. I hope you have a nice experience :smile:!

1 Like

I have been using this off and on A/B/C ing between the Data Proxy, Accelerate as just connection pool, Accelerate + TTL/SWR.

I must say it feels like a cheat code for how easy it is to setup now and just have it work.
The difference getting to have it US-WEST-1 was pretty decent for me whereas Data Proxy had to be US-EAST something.

I haven’t ventured out of 5.1.1 to 5.2 for Prisma & Client as I’ve been catching up their Redwood dependencies, but seems like an auto include on any project going out into the wild with Prisma for me.

Worst case it is easy to pluck out the from your services:

cacheStrategy: { swr: XX, ttl: XX }

and in then go back to no .extends

export const db = prisma.$extends(withAccelerate())

export const db = prisma

I’ve recently been setting up connection pooling through Accelerate. I’ve got it all up and running both locally and on Netlify. However, I keep getting this warning:

prisma:warn In production, we recommend using `prisma generate --no-engine`

I’ve tried running that script multiple ways with no luck. When I run it directly yarn prisma ... I get “Couldn’t find a script named ‘prisma’”. When I run it with yarn rw prisma ... the redwood command turns --no-engine into --engine and so the command fails since the flag --engine is invalid.

Does anybody have any insight on how I can resolve this issue?

What version of prisma are you on if you do:
yarn rw primsa --v

I believe the --accelerate flag is supposed to handle this but depending on prisma version or if things are wonky might need to directly specify. This is from docs but i subbed it to yarn rw instead of npx

When using Prisma Accelerate in a Serverless or an Edge application, we recommend you to run the following command to generate Prisma Client:

yarn rw prisma generate --no-engine

The --no-engine flag prevents a Query Engine file from being included in the generated Prisma Client, this ensures the bundle size of your application remains small.

If your Prisma version is below 5.2.0, generate Prisma Client with the --accelerate option:

yarn rw prisma generate --accelerate

If your Prisma version is below 5.0.0, generate Prisma Client with the --data-proxy option:

yarn rw prisma generate --data-proxy

I don’t think that last option is being supported or is being sunsetted though

I’m on 5.7.0 and the yarn rw prisma generate --accelerate runs without issues. It just gives me the error in the command line during deploy/build.

So it does work, but throws the warning if I understand?
Maybe check package.json and see if there’s another prisma extension there.
Also maybe something wonky on install/overwrite when extension installs so could maybe delete node modules and redo yarn install after also checking package.json
After that maybe try walking back the prisma version to see if it’s something with that version maybe acting up.
I have one project on 5.2.2 and another on like 5.6, but I am on Vercel.

You might also try manually setting the commands in the netlify.toml to run all the commands you need to instead of relying on the boilerplate yarn tw deploy so you can set custom flags.

You can simply && (chain) a number of them to build and regenerate the client as needed. See also Connection Pooling | RedwoodJS Docs

Yeah I was following that doc to get started with connection pooling. It was referencing the old method so that is what led me here. I’ll try updating netlify.toml file and see if that resolves the problem.

It also looks like the NODE_ENV isn’t getting properly set when deploying using the deploy boilerplate since the console is still showing the Apollo dev tools recommendation on my production site. So I was going to try editing that file as is; hopefully this will handle both items at the same time

Could you clarify what you mean by this? Perhaps a screenshot?

There are no Apollo tools deployed. Do you mean the GraphQL Playground perhaps?

My apologies, that wasn’t very clear. I was referring to this message appearing in the console. From what I can find online, this shouldn’t come up outside of a development environment. But it is still appearing in the console on my deployed site so I’m wanting to resolve that.