RW patterns for common usecases

Get Help and Help Others
1

Hi all! Wanted to gather some ideas from the community:

1. Has anyone had some thoughts on how to “seed” prod dbs, as part of migrations?
I know you can use rw db seed, but this feels more like for local dev. Ideally I was looking for something like the rails up in the migration file

2. How do you guys handle error codes from graphql?
Is there an apollo-ific way to do this instead of digging into the error response like (yuck!)

if (
        networkError.response.status === 401 ||
        (networkError.response.status === 400 &&
          networkError.result.errors[0].extensions.code === 'UNAUTHENTICATED')
      )

3. How do you do retries on Cell failure?
Just wondering if there’s a standard way that the community is doing this

2

I haven’t done a retry in a Cell, but I have done so in a function that calls a service that then a 3rd party external API to deal with 503 rate limits or other errors that this external API can return … and I like the “exponential backoff” approach.

A nice package to do this is: exponential-backoff - npm

await backOff(() => signIn(userId))

Here, a function calls a service called signIn that fetches a full userProfile from Auth0’s management api.

I think the same approach could work inside a cells, since it calls a service too.

3

:heart: exponential backoff. This is a nice little touch.

The “unintuitive” bit I see is that, while the <Error/> component has access to the query in cells, there isn’t an obvious way to call this query in there. i.e. there isn’t a cookbook way of doing it, while its a very common usecase.

4

I’d do the retry in the service that the cell calls.

That way the Loading will wait wait wait and then if it finally errors after the max tries is exceeded, it’ll throw an error for the Error in cell to handle.

Or if it succeeds eventually, Success would be used.

5

That’s an uncomfortable one I’m also eager to see be solved.
With @peterp we’re trying to set up Apollo GraphQL’s links to address the issue here:

Link to the docs: Error Link - Apollo GraphQL Docs

Hopefully we can come up with a solution to integrate within Redwood :slight_smile:

I’ll keep the bench on 1/ and 3/.

6

Answering one of my own questions :sweat_smile:

This should be handled with data migrations which @rob is working on. In PR at the moment! https://github.com/redwoodjs/redwoodjs.com/pull/256 . Perfect timing :alarm_clock:

7

Yes, Data Migrations are here! You’ll be able to write migrations to database content with Data Migrations in a similar manner to database structure changes via Prisma Migrate.

There are three commands to know:

yarn rw dataMigrate install

This adds the needed database table for tracking which data migrations have already run to your schema.prisma file, and creates a directory for data migrations to live in.

yarn rw g dataMigration yourNameHere

Creates a new data migration file with a timestamp in the name. These go in api/prisma/dataMigrations

yarn rw dataMigrate up

Runs any outstanding data migrations against the database!

You can get a preview of the docs here, they’ll be going live as soon as 0.15 is released: https://deploy-preview-256--redwoodjs.netlify.app/docs/data-migrations

8

Bumping this thread for 2/ and 3/