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.
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.
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.