I’ve been evaluating Render for a couple of days and really like a lot of what I see, but I’m struggling with the best way to do something that seems like a really, really common use case: A site with significant static assets, a dynamic piece, and a DB.
It seems fairly clear that static site + web service + DB is the way to go, the trick is in wiring up the static site and the web service in the right way.
First I tried rewrite rules on the static site to make API requests go to the web service. That works, but is slow – an API call that takes on average 40ms when pinging the web service directly takes an average of 400ms when performed through the static site rewrite. (Note this is rewrite, not redirect, so I wasn’t expecting that, but I guess there’s CDN plumbing and rerouting once it gets to Render’s servers and such…)
Another approach would be to use
example.com for the main site and
api.example.com for the API calls. That requires handling CORS and, in the case of “complex” requests, will mean the browser has to do an
OPTIONS request before doing the real request. That’s unnecessary overhead. You can reduce the
OPTIONS calls via
Access-Control-Max-Age but it’s per-path…
A third approach would be for the “API” server to actually serve the static files as well – no static site. But that’s markedly more complex to set up in an optimized way. I’m using a Node.js backend for this test, and while it’s good, it’s fairly classically not the best way to serve static content. Maybe it would be okay if it’s fronted by Render’s CDN, I don’t know.
What’s Render’s best practice for doing this?