Mapping Redwood concepts to tools

Get Help and Help Others
1

Hey all – last week I put together a mental mapping of Redwood concepts, tools, and “layers of the stack.” It’s incomplete (where do serverless functions fit?), but thought it might still be helpful given the conversation in today’s meetup:

rw-layers
rw-layers1206×758 72.7 KB

What do you think? Is this a helpful high-level overview? Anything foundational missing or not categorized correctly?

7 Likes
2

Nice! Thanks for this.

3

I love it Tim! That’s great :slight_smile:

4

Scaffolding and redwood configuration of Apollo and prisma :slightly_smiling_face:.

Also I need to check this again but SDLs are orchestrated I believe by redwood directly. These ties are the thin hard kind to grasp to really ‘grok’ RW, in my humble opinion.

Thanks for taking the task though :slightly_smiling_face: that’s awesome!

1 Like
5

I’m not sure what to call the layer that has Services in it, but within the api side … and I do think the concept of sides need to be used more in the diagrams because I think it’s an awesome way to “think about” how to coordinate common functionality and demonstrates that this functionality can be shared “across sides”. As the RW intro docs state:

You’ll notice that the web side is called “web” and not “frontend”. This is because Redwood conceives of a world where you may have other sides like “mobile”, “desktop”, “cli”, etc., all consuming the same GraphQL API and living in the same monorepo.

It helps me not to look at it as a “stack” or something that “goes in one direction” or “down and then up”. It’s more like a “graph” or maybe “hub” I dunno. One side can do something and use something from another side or call something from another side.

In that regard, I’d consider where to put other api side capabilities:

  • functions (which I right now think of as external api endpoints that used by something external to my app, ie. i cannot import the service). Though doesn’t have to be. These can accept incoming webhooks … something that needs to post info that isn’t going to want to call graphql. I mean, graphql is just a function that exposes the qraphql endpoint. RW proxies it so it doesn’t really look like it, but it still is.
  • services (and functions) are not limited to Prisma; they can use any third-party API (connect to Hasura, Contentful, the Weather API, etc). Though, I probably would have my function call a service that then interacts with that API. I’m trying that now in someting I’m workin on.

A good topic for future might be: when to use services and when to use functions.

Also

  • Security I’d want to include that there’s an authentication and authorization capability that can be used … again … across the sides. My function can requireAuth and my service can too and my web side/routes can and … and so on.

And then:

  • other sides I can see a need for a jobs side that is kicked off by a cron schedule. Maybe that cron posts a webhook (with some signed secret) to a function (that verifies that the webhook is valid and permitted) and the function then kicks off that job and that job calls a service to “perform” whatever the job has to do … like send an email to all users … so it uses the User service to get those email addresses.

Can see that it gets interconnected really fast – and that’s what’s really nice and powerful about the architecture … even so early on in RW’s life.

1 Like
6

@tctrautman Thanks again for this! Wanted to share links to docs I’ve found helpful as well:

Apollo

Prisma

1 Like