I’m just getting started with Redwood, so far I’ve been running locally. I recently upgraded to the Redwood 6.0.0 RC. I’ve been trying to find a good deployment service, and settled (so far) on render.com for my prototype. I followed the instructions to deploy a Redwood app, but I was confused by several things:
My app has the several default main components: web, api, db (and a 4th, separate python API service I’m setting up, but that’s tangential so far). The “web” component is called a “static web site” and I don’t understand the terminology, since I would expect my site to be either fully-dynamic or a mix of static and dynamic. E.g., I have a logged-out landing page that is static, but once a user logs in everything is completely dynamic. Render.com only has a “static” option, so is it even possible to serve dynamic sites with e.g. a user login option?
Assuming I can use the “static web site” option for my mostly-dynamic Redwood app, I don’t understand the “Add Rewrite rules” step. I’m supposed to add 2 rewrite rules in the “web” component: 1. point
/.redwood/functions/* to the URL of my hosted API like
https://project-api/onrender.com/* and 2. point
/index.html I don’t understand this at all. OK, #1 sort of makes sense, calling the API for any functions. But #2 apparently rewrites any URL as
index.html and I assume that will break any “Routes” I have defined. This seems like it could only possible make sense if we’re actually talking about a static single-page website that does nothing dynamic at all. So again I think I’m either missing something basic or else render.com can’t serve normal redwood apps unless they’re a single static page.
Edit – I thought my site was broken when I posted this, but I found a missing environment variable and now it’s actually working as expected. However, I still have no idea how these “rewrite rules” work so I’m hoping to learn what’s actually happening here. Thanks!
Hey @eraoul, welcome to Redwood!
If you look at your website in the developer console, you’ll see that your entire site is being rendered in a
In terms of the rewrite rules, there’s two things going on:
- The API route rewrite - this is primarily to bypass CORS issues. The docs has a great interlude on this.
index.html one - this is related to the above stuff about the virtual DOM. Your website really only ships the one html file - if you go to your site’s build output, you’ll see only
It’s worth noting that in v7 of Redwood, this may be changing with the adoption of React Server Components - you can start your journey down that rabbit hole with @thedavid’s recent post: Bighorn Epoch Updates (aka the React Server Components roadmap)
Thanks so much @arimendelow, that all makes a lot of sense although I have one lingering question below. I was used to the term single-page application (SPA) and I have also called something like a non-changing landing page a “static” page, but I was surprised by calling an SPA “static”. As it refers to the original HTML, that makes sense.
However, as far as the rewrite to index.html, I still don’t understand something about React/JS in general then regarding the URL: when I have a link in my site that navigates via a “Router” and displays a URL such as
mysite.com/profile, how does that that still show up as
mysite.com/profile even though I’ve apparently “rewritten” it to
index.html? Specifically, I can navigate to e.g.
mysite.com/subscriptions and see a different page than
mysite.com/profile, and I never see the “index.html” thing show up in the URL, so I don’t understand when that rewrite is happening and how it’s never showing up at the user level. (how does the “virtual DOM” interact with the stuff in the URL bar, basically?) Anyway, it’s cool that it works.
Ah - the root of all this is that HTML 5 provides a History API - Web APIs | MDN.
This allows you to put basically whatever you want in the user’s history and address bar, and without any page reload or actual navigation happening.
Got it – thanks! The history API is the key, I see!