Redwood Sides & Sides targets

Get Help and Help Others
1

@peterp I’ve had a quick look at the Sides PR you’re working on, and I’ve seen the notion of target within the Sides configuration.

Do you have some kind of a spec, or at least a vision about what those “targets” would encompass?

I’m asking because I heard/read things like “a react-native Side” several times now, and I think we should actually talk about React Native as a target for a mobile/app (I guess the name wouldn’t be imposed on the dev?) Side.

What do you think? I’m sorry if that’s too much nitpicking at that stage, but I believe using the right terms is helpful to understand the concepts but also to be clear about where we’re headed and help us get there.

It also relates to a remark I made around plugins and Vue.js during our last meetup.
I think it’s @mojombo who talked about a vue Side. I’d argue that we should be talking about a vue target for the web Side.

Designing it this way could allow us to use powerful conventions such as target-dependent builds or target-dependent generators (and maybe, if that makes sense, target-dependent deployments?).

For instance in a plugin-enabled future, when using yarn rw g page home /, we could automatically load the redwood-[target]-page-generator module to have the correct files generated depending on the target (e.g. Vue components for the vue target).

At the moment, targets seem hardcoded into the framework, but as Redwood grows it could be possible to follow Rails’ path and extract parts of the code to official redwood-[target]-build / -generator / … modules, so that loading the layers to generate, build and deploy a Redwood app would become purely dynamic.
Once we have that, supporting technology xxx in Redwood would just need someone to step up and create the proper redwood-xxx- modules.

It’s definitely not going to happen tomorrow (and I have a tendency to get excited about quite uncertain & long-term things like this, sorry :man_facepalming:), but targets seem like a good first step to pave the way?

4 Likes
2

I think the closest thing to a spec would be this:

3

They way I see it is the “spec” should answer some of the following questions:

  1. where are you located in the project?
  2. what should we do when we run the dev command (target related.)
  3. what should we do when we run the build command (target related.)
  4. where should the code that we build be available?
1 Like
4

Thanks Peter for the reply, it does clear things up!

What’s your take on the “React native / Vue Side” vs. “React native / Vue target” and the idea that it could power more dynamism later?
Just trying to understand how you see things from the inside :slight_smile:

1 Like
5

What’s your take on the “React native / Vue Side” vs. “React native / Vue target” and the idea that it could power more dynamism later?

Maybe a definition for a Side is something like:

  • is a specific yarn workspace
  • with a specific config or extension of RW common config (e.g. babel, webpack)
  • with a specific dev-server (and server?)
  • and a specific build command
1 Like
6

Sorry! I didn’t see this here. I think of the side as the path location and label within a workspace. So right now we have two sides: “api” and “web”, but those could be called anything.

The “target” is how they are served by the yarn rw dev command, and built by the yarn rw build command.

The target also brings a bunch of baggage along. A node target could have a db, but a browser target could not.

3 Likes
7

Thank you both for chiming in :slight_smile:

2 Likes
8

The idea of “sides” is a good one.

Speaking for myself and guessing what the community at large needs: I suspect a server-side worker “side” would be the most useful.

Most apps will have server-side processing that’s not initiated from a web or mobile client, e.g. event-driven (like queue processing), time-driven (all manner of cron jobs: maintenance, backups etc.) and admin-driven (data loads, user on-boarding etc). It would be useful to have a way to define server-side work processes within the Redwood framework that use the Services and don’t necessarily have any UI. These could be thought of as pure Lambda workers a la AWS.

All for “sides”. Server-side workers feels like a priority side to me.

The alternative would be to define separate worker processes, triggered by some (non-Redwood) API, that have to establish a GraphQL or Services client to interact with Redwood: not ideal.

3 Likes
9

That’s a great idea! I wonder what the deployment target would be?

10

@peterp I’d think for many apps, the deploy target would be another Redwood function – basically one worker = one Lambda. However the function shouldn’t be accessible from the client, just the API. The dev can connect the worker via the API if the client should have access (not the normal case).

More highly scaled apps may need the workers to be deployed on AWS. The relationship of the AWS API Gateway --> lambda and API Gateway --> queue --> lambda is very tight and allows for (1) event-driven actions (no polling) and (2) fast performance when the services are co-located.

So maybe Netlify-deployed for less-scaled apps and AWS-deployed for higher-scaled apps?

1 Like
11

I’ve been seeing/thinking this way as well. Seems to be clarifying itself as more needs pop via real use cases.

But I also know we have a direct line to communicate needs+features to Netlify – odds are they haven’t thought about much of this simply because there has not been demand. fwiw.