Questions mainly related to customising Redwood

Get Help and Help Others Solutions
1

Redowood is a fantistic piece of work. There does not exist any such package in the JS excosystem. I have few questions, pl. answer them.

a. Is it possible to use our-own custom JWT implementation… If yes, is there any tutorial or example code that demonstrates this including client-side implementation?

b. Looks like Redwood has built-in support for roles. Can we define our own roles like Admin, Moderator, Editor, User, etc.? Is it possible to attach the fine-grained permissions to these roles, for example, casl-ability npm package.

c. Redwood does not support cron jobs currently. If not, hope it’d be easy to use the node-cron like package? For example, inactivate the users who are not active since the last one year.

d. Same for queues, probably no built-in support. We may need a package like bull to send emails, newsletters etc.

e. Can we use custom validators like zod or yup i.e. overriding the built-in validation?

f. Looks like Redwood Graphql uses the schema-first approach. I had a look at the Blog example where you defined the SDLs for User and Post types. But there doesn’t exist any SDL for input, output types etc. Why so?

g. Is the live-queries feature, alternative to subscriptions, fully functional?

h. Can we extend the built-in validations and add our own, for example, a password should match a given Reg Ex?

i. Does Redwood support client-side validations which are typically used before the forms are submitted to the server? If yes, is there any example that demonstrates the usage of built-in validations at client-side?

j. How is it possible to use the Fastify middlewares in Redwood. For example, I need to use the csurf middleware. Probably it is not possible use the middleware especially in the serverless environment because we are not going to create the Fastify instance ourselves, Am I right?

1 Like
2

Hi @ramandhingra Welcome to Redwood! Glad you’re excited about it. As you know, we sure are, too.

These are awesome questions. What would be amazing is if we had a way to create some kind of FAQ using these as a foundation. I only have time for a few answers now, but I’ll loop in some other folks.

Without trying to over generalize and overstate, the answer to all your questions is effectively, “Yes, that’s possible.” And I can think of people and projects who can tell you more. Redwood is very modular — the primary work we do is integration of the parts. This means things can be decoupled, swapped, thrown own, etc. as needed. But when you do that, you leave the “golden path” of configuration and integration convenience. The irony is that when you’re first getting started and the team is small (or your running solo), it feels reasonable to swap things out and customize. But this can make it harder to scale the team and product. So our starting recommendation is always, “see how far and for how long you can stick with the golden path, and as your product and team grows, then start to specialize and customize.” But each case is it’s own case.

a. Yes. Do search the forums.

b. Yes. There’s great docs on this.

c. and d. This is an infra question as much as feature. Do look into our own Repeater.dev and Quirrel if you’re deploying serverless. If traditional server, well, you have all kinds of other options (but, correct, nothing built in).

e. Yes, @peter at Snaplet doest his but he’s customized a lot of the API as well

f. Redwood handles resolvers for you. Docs are good for explaining this too

g. Not yet. But check out what’s coming with Envelop/Helix. Feels reasonable to expect somethign in 2022

h. yes

i. Yes, we have those (and use React-Hook-Forms). See the docs

j. For serverless look into Middy. Yes to middlewares in general although we haven’t documented best practices. But Fastify maintainers helped us with the integration and we could loop them in for design/architecture discussion — would be helpful for the whole community

Looping in @dthyresson @orta @rob

3

@thedavid

Thanks for your reply… many doubts got cleared.

When you said, “Redwood handles resolvers”, does it mean that it implicitly takes cares of the resolvers’ signatures and we don’t need to define the Grahpql schema for the input Args, the output type, etc. if the resolvers. Correct?

Fastify lets us use proven and stable Express middlewares, to name a few, cookie-parser, csurf (CSRF), cors, compression, stats. It’d be great if we are able to use them in Redwood i.e. Redwood offers something like request interceptors and then we can apply the Express middleware over there.

It looks like that Envelop has support for Graphql middleware and we can use graphql-shield for configuring and checking permissions before the resolvers are invoked.

4

When you said, “Redwood handles resolvers”, does it mean that it implicitly takes cares of the resolvers’ signatures and we don’t need to define the Grahpql schema for the input Args, the output type, etc. if the resolvers. Correct?

Just to make sure I’m not confusing things, have you read this?

Fastify lets us use proven and stable Express middlewares, to name a few, cookie-parser, csurf (CSRF), cors, compression, stats. It’d be great if we are able to use them in Redwood i.e. Redwood offers something like request interceptors and then we can apply the Express middleware over there.

Again, we don’t have an established pattern for this but it’s possible. If needed and there’s momentum, it might make sense to start a GH Issue and loop in Fastify maintainers. Any additional thoughts for now @danny?

It looks like that Envelop has support for Graphql middleware and we can use graphql-shield for configuring and checking permissions before the resolvers are invoked.

Do check out everything you can do out of the box and the settings + plugins added by default:

And check out the beginning of this doc I already linked:

Do we have a list of Envelop plugins pre-configured @dthyresson?

1 Like
5

Hi @thedavid

I read the Graphql documentation carefully. Things have been clear now.

Thanks.

1 Like
8

Not by name in docs, but many are used in the Security section of the GraphQL documentation here: GraphQL | RedwoodJS Docs

To see a full (current as of posting) list, see: redwood/packages/graphql-server/src/functions/graphql.ts at fd8ac2f10287abeb5e627f1bf1a91acfddbb5844 · redwoodjs/redwood · GitHub

import {
  envelop,
  EnvelopError,
  FormatErrorHandler,
  useMaskedErrors,
  useSchema,
} from '@envelop/core'
import type { PluginOrDisabledPlugin } from '@envelop/core'

import { useDepthLimit } from '@envelop/depth-limit'
import { useDisableIntrospection } from '@envelop/disable-introspection'
import { useFilterAllowedOperations } from '@envelop/filter-operation-type'
import { useParserCache } from '@envelop/parser-cache'
import { useValidationCache } from '@envelop/validation-cache'

You can also add additional envelop plugins (from their suite of plugins ro even write your own) to your GraphQLHandler via extraPlugins:

/**
 * Creates an Enveloped GraphQL Server, configured with default Redwood plugins
 *
 * You can add your own plugins by passing them to the extraPlugins object
 *
 * @see https://www.envelop.dev/ for information about envelop
 * @see https://www.envelop.dev/plugins for available envelop plugins
 * ```js
 * export const handler = createGraphQLHandler({ schema, context, getCurrentUser })
 * ```
 */
export const createGraphQLHandler = ({
  loggerConfig,
  context,
  getCurrentUser,
  onException,
  extraPlugins,