Redwood + ZEAL October Extravaganza

Hello, fellow foresters!

Every Friday in October, every ZEAL team member will be focused on building with, and furthering the mission of, Redwood.

We’ll be putting out blog posts, launching tools, answering questions, and whatever else we can to support the builders in the community.

You’ll see us (and probably already have) in the forums, Discord, and Github. We should be identifiable in Discord and Discourse by some form of ZEAL after our names. Feel free to connect!

If there is something you’re working on, or something in the Redwood repo, that you’d like us to help out with, give a holler. We’ve got lots of stuff we’re working on but we’d love to help you out, too!

– Jason

10 Likes

Incredible! Thank you so much, team ZEAL :rocket:

4 Likes

Thanks @thatonejason and everyone at ZEAL!

I’ve started an Office Hours demo series recently and have some post up already with example repos:

We’ve been in touch already and excited to collaborate … and I wanted to share with the community some ideas for posts, examples, and tools:

  • Autocomplete using Algolia’s Autocomplete widget and GraphQL ( I have a working example)

  • Pagination with Web Component Controls and Offset and Cursor based examples. See RFC
  • Modal Routing - See RFC
  • Route Transitions
  • Make a generator that takes a Swagger/OpenAPI/JSONSchema api documentation and build out SDL and queries and mutations and services to consume the api
  • How to Upload with RedwoodJS. There are so many ways (S3 signed url, Filestack, Supabase Storage, etc). What are some patterns to use consistently
  • Switch to use GraphQL Armor for GraphQL security defaults (remove depth limit, rate limit and use their plugins). And why use over existing depth-limit plugins, etc.
  • Document how to use Prisma ERD generators and use with Docusaurus.

I think that’s most of my wishlist :slight_smile:

Do people have others?

Thanks again for having ZEAL focus on contributing and collaborating with RedwoodJS community.

Excited to see what we all make together.

5 Likes

I would have prefered an open source self hostable solution instead of algolia, like meilisearch.

Hi @razzeee

In this demo, I didn’t use the Algolia search service – I used their open source autocomplete widget.

Autocomplete is an open source, production-ready JavaScript library for building autocomplete experiences.

The search itself is performed over GraphQL and Prisma making a “like” (*aka contains) Postgres query for the terms.

Please see: redwood-office-hours/2022-10-12-algolia-autocomplete at main · redwoodjs/redwood-office-hours · GitHub

and

1 Like

@dthyresson This sounds interesting. Going to take a look at this one.

@dthyresson Some notes and finding love to get your eyes on.

graphql-armor comes with several plugins already included and enabled by default here is an itemized list below of what Redwood would get.

To configure each plugin, it appears that you can just pass the EnvelopArmor constructor to an object containing the configuration for one or more of the plug-ins inside of it.

EnvelopArmorPlugin({
        costLimit: {
          enabled: true,
          maxCost: 100,
          objectCost: 1,
          scalarCost: 1,
          depthCostFactor: 2,
          ignoreIntrospection: true,
        },
        maxAliases: {
          enabled: true,
          n: 1,
        },
        maxDirectives: {
          n: 10,
        },
        maxDepth: {
          n: 4,
        },
        maxTokens: {
          n: 250,
        },
      })

The first thing that jumped out at me is that the depth-limit plugin for graphql-armor doesn’t allow you to configure ignoring certain fields like the current depth-limit plugin allows. Not sure if that is of any concern.

You also noted the rate-limit plugin, but it doesn’t appear graphql-armor offer a rate-limit plugin by default, and it also appears to be an optional configuration that the developer can add it on their own.

One question I have is how we should allow configuration for each plugin. Should we have, each plug-in configuration passed separately like with do for other configurations, ie.

export const handler = createGraphQLHandler({
  loggerConfig: { logger, options: { query: true } },
  depthLimitOptions: ...,
  costLimitOptions, ...,
  maxDirectivesOptions: ...,
  // ...
})

Doing so would make existing configurations for plugins like depth-limit backward compatible (except for ignoring not being possible anymore).

Or should we just nest all configurations under a single property? ie.

export const handler = createGraphQLHandler({
  loggerConfig: { logger, options: { query: true } },
  armorOptions: {
        maxDirectives: {
          n: 10,
        },
        maxDepth: {
          n: 4,
        },
        maxTokens: {
          n: 250,
        },
  },
  // ...
})

Doing this could allow for easier compatibility with future versions of graphql-armor since we’re just passing a big configuration object and don’t have to worry about updating or removing properties.

1 Like

As I noted oil Discord, RedwoodJS will be upgrading to Yoga v3 soon so this gives us an opportunity (if we choose so) to introduce some breaking changes (with code mods to update) in the GraphQL handler.

Therefore, I agree that passing in the entire configuration for GraphQL Armor seems a better idea so that one won’t have to update the handler options as Armour adds new features – and allows the user more control.

Let’s remove the individual handler options and replace with a singular configuration.

Perhaps call it graphQLArmorConfig?

1 Like

Ah, I thought it did. I know there are some plugins for that, but they need a redis or other data store. We can skip that for now. I imagine Armor may support that down the road.

I don’t think I am concerned with that. I think the overall goal is to prevent deep, nested querying that could tie up the api.

I think I had a rather generous default of 8 according to the docs GraphQL | RedwoodJS Docs which may be too high honestly.

Which reminds, me that the as part of this PR, the GraphQL security section of the docs could use updating to showcase more of the protections.: GraphQL | RedwoodJS Docs

1 Like