English for RedwoodJS Developers

RedwoodJS conversations often need to justify its opinionated, full-stack structure and its GraphQL-first data layer, so the vocabulary covers cells, the api/web split, and the conventions that make a Redwood app predictable to navigate.

Key Vocabulary

Cell — a RedwoodJS component pattern that declaratively handles the loading, error, empty, and success states of a GraphQL query, removing manual state management for data fetching. “Wrap that component in a cell instead of writing your own loading and error branches — Redwood generates all four states from the query automatically.”

api side / web side — RedwoodJS’s split of a single monorepo into a backend GraphQL API package and a frontend React package, sharing types but deploying independently. “The validation logic belongs on the api side, not the web side — the web side should only be rendering what the API already validated.”

SDL (Schema Definition Language) — the GraphQL schema files in a Redwood project that define types, queries, and mutations, which Redwood uses to auto-generate resolver stubs. “Add the new field to the SDL first — Redwood will complain about a missing resolver until the service function matches what’s declared there.”

Service function — the business logic layer in RedwoodJS that implements the resolvers declared in the SDL, typically containing the actual database calls via Prisma. “Keep the service function thin and push the complex query logic into a separate helper — it’s easier to unit test outside the GraphQL context.”

Redwood generators — the CLI scaffolding commands (yarn redwood generate) that create cells, pages, SDLs, and services with consistent file structure and naming. “Just use the Redwood generators for this — hand-writing the cell boilerplate isn’t worth it when the generator produces the same four states correctly every time.”

Common Phrases

• “Should this be a cell, or is the data simple enough that a plain component with useQuery is fine?”
• “Is this logic supposed to live on the api side, or is it leaking into the web side where it doesn’t belong?”
• “Did we update the SDL before writing the resolver, or is that why the generator is failing?”
• “Is the service function doing too much here, or is this still reasonable for one resolver?”
• “Can we just scaffold this with the Redwood generators instead of copying an existing cell by hand?”

Example Sentences

Explaining the architecture to a new hire: “Everything under api/ is the api side — it owns the database and business logic. Everything under web/ is the web side — it should only consume GraphQL, never talk to Prisma directly.”

Reviewing a pull request: “This component is manually managing loading and error state — can we convert it to a cell so Redwood handles that consistently with the rest of the app?”

Onboarding someone to the workflow: “Don’t write the resolver from scratch — run the Redwood generator for a service, then fill in the actual query logic.”

Professional Tips

• Use cell precisely in code review — flagging a manually-managed loading state as “this should be a cell” is a clear, actionable comment.
• Explain the api side / web side split early, since developers coming from single-package frameworks often reach for direct database access from the frontend package by habit.
• Keep discussions of the SDL tied to “contract-first” language — it’s the source of truth the resolver must match, which helps explain generator errors.
• Push back on bloated service functions in review by asking whether logic could move to a shared library, keeping resolvers testable in isolation.

Practice Exercise

1. Explain what a cell is and what problem it solves compared to manually written loading and error states.
2. Describe the difference between the api side and the web side in a Redwood project.
3. Write a code review comment asking a teammate to move a business logic block from a component into a service function.