Wildcard subdomain pointing to static sites - how would you do it?
NOTE - this is long-winded. If anyone makes it to the end, THANK YOU! I just needed to get this written down somewhere and was looking for feedback at the same time.
I'm working on a project where the users will have a static single page site at a subdomain of their choosing. Basically they will choose from a list of our templates, fill in the blanks, and done. In the future maybe offer more customization, but not for now.
I have two ideas about how to accomplish this, each has drawbacks and benefits. I'm looking for some outside input to hopefully show me something I'm missing, or give me a new perspective to look at it.
Static files with proxy routing
My rough idea is to point my wildcard subdomain DNS to the chosen provider (such as AWS S3 or similar), and use that platform's routing mechanism to route to the right page. So, for example joel.example.com will proxy the routing to the S3 container's directory with the same name - /joel/index.html. Then use a catch-all for non-existing paths for a general 404 page.
I've only done some brief research, but this does seem possible using S3, Amazon Route 53, and Lambda functions. I imagine there are other platforms that offer similar options. I could also do this myself on a server with Nginx, but was hoping to use an existing static hosting option (e.g. serverless for me).
Pros
- As long as the routing logic isn't slow, the sites will be fast to load as it's a simple html file.
- No database queries or server-side functionality (though, if I have to use Lambda functions this is sort of no longer a valid point, I was hoping simple routing logic would be sufficient).
- Between the speed and the fact that it's technically rendered server-side (meaning meta data is available for crawlers) I can offer strong SEO as a benefit.
Cons
- Each new site and update to existing sites means I have to generate a new final html file and push it somewhere.
- Might not be too scalable, as each site will continue to add directories and files.
- From a technical perspective, this is more complex than the alternative I believe.
SPA + DB entries
This option is to use a simple framework (or build it myself, but existing frameworks will be faster for me) like Vue/React to host a single site at *.example.com. Then, in the application on SSR extract the subdomain, using that as a query parameter to a DB query to retrieve the user's data for the site, including the template chosen, and render the component accordingly.
I already have another project that works this way - statustracker.app. You can see https://acme.statustracker.app/ as an example of the wildcard subdomain logic.
Pros
- It's more scalable as it's a single site with some components and every user's site info is stored in a DB entry.
- From a technical perspective, it's more simple. I already have a working project with this logic so I have a reference point.
- "deploying" from the customer's perspective can be pretty much instantaneous - no need to generate and transmit a file somewhere.
Cons
- As you might have noticed looking at my acme reference, TTFP (Time to first paint) is slower because it depends on a DB query to return before we even know what template/theme to show to the user. Alternatively I could show a "loading" component while waiting for the request to complete - choosing between server-side rendering and slow, or client-side rendering and fast (perceived fastness).
- SEO is sacrificed - as mentioned above I either have to choose speed of TTFP or server-side rendering (which allows for proper meta data to exist for crawlers). Both of those impact SEO in their own way. (This wasn't a concern for status tracker as the customer sites weren't intended to be marketed, they are portals which require an account).
- Could be harder to implement the feature of offering more custom websites in the future, which we plan to eventually do.
What did I miss?
Is there an option I missed, or a benefit/downside to one of these I missed that could make my decision? Maybe there's an existing platform/service that I could work with that gives me what I'm wanting to do without me needing to build it all myself?
To be honest, I'm leaning towards the PWA + DB queries because it seems the best choice overall. I'm just really disappointed that I couldn't offer truly static pages with strong SEO capabilities more easily, as that was originally my intention.
Thanks again for sticking with me this far!
I used simple server with nginx to do that in my prev project.
it checks if there is a folder with the subdomain name in /var/www/html directory. It serves the content to that subdomain, if not found - 404.
I think you can put behind proxy/cdn and call it a day.
server {
listen 80;
server_name *.domain.com;
}
server {
server_name ~^(?<subdomain>.+).domain.com$ app.domain.com;
root /var/www/html/$subdomain;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
This is one of the options I was considering. As I mentioned I was hoping to avoid managing my own server, and would love to take advantage of free static site hosting at least for a while. But, I think honestly this might be the most simple option. Now that I think about it, I think I still have a Digital Ocean droplet still running that I've forgotten about, so maybe I can just use that.
This is an interesting topic and the need for strong SEO adds an extra dimension. I would probably lean toward SSR + DB on the wildcard subdomain. You likely have a DB in the project anyways and it would be easier to make changes to rendered content if you ever need to.
As of now this is where I’m leaning. But I’d like to implement SSR caching per subdomain with the ability to clear it per subdomain on demand (e.g. when the user makes an update in my main app). If I can solve that I think this is the way.
I'm actually building something very similar and totally get your pain. What turned out to work best for me is the solution you already described.
Host the static pages on an AWS/GCP bucket, just plain html, no routing etc.
Regenerate each page whenever a change is made. This is far quicker and easier and cheaper to do than making each site load dynamic content. It's even simpler if you're using React. Serving plain old html from a plain old directory structure from a bucket with automatic global cache system is blazingly fast and basically guarantees 100% uptime.
This is really what I wanted to do preferably. The part I’m getting caught up on is handling the subdomains. Either I have to deploy a new single file site and configure a new subdomain to point there for each site, or I have to handle routing with a wildcard subdomain to a directory with the same directory. You said no routing, but how would I handle each subdomain without routing to the appropriate directory?
I meant without dynamic routing within the websites. Just configure it to point to an index.html and about.html etc..
As for subdomain routing (to make it point to a specific website) you can set up whatever load balancer or routing configuration your hosting (AWS or GCP) provides to handle your case without ever writing the logic yourself. Basically: if someone visits foo.example.com try to load /websites/foo/index.html from your bucket and that's it.
This is what I was trying to figure out, what platforms offer this and how they work. Everything I read about doing this on S3 required a Lambda function for handling the proxy routing. But I would think it’s not too complicate it should be doable in a standard routing mechanism. In nginx it would be fairly straight forward. I just haven’t found yet an example of how to do this in a simple way. I’m not committed to any host provider, whatever solves my problem without extra complexity and without outrageous pricing.
Yeah using lambda to do the routing to an S3 bucket is an overkill and defeats the purpose of the setup.
In Google Cloud you can set it up without writing any code at all. Just config the load balancing and permissions in the admin panel.
And if you want to do something more complicated they have a config file with pretty straightforward syntax.
Ok cool, I haven't really looked into Google Cloud much, I keep forgetting about it. I'll check that out, thanks!
Next.js would work well for this
That’s what I used for the Status Tracker portals. It does work well, but my preference would be basic static file storage. Next is almost overkill for it, but it does solve some of the problems.
That's fair. It depends how extensible you need the app to be.
Yeah, these sites will be a basic landing page, only 1 page per site. Not a lot of need.
But, I just thought of something. If I can implement SSR caching with the subdomain as the key, then that can solve the speed problem with this choice. But I would need a way to invalid the cache externally - an api call or similar.
Have a look at the stale-while-revalidate header ;)
Yeah I looked at that. I don’t want it to auto-revalidate in the background like that, at least not always. Essentially I want it cached for good, until I explicitly tell it to invalidate the cache for a given subdomain/key. I know, I’m picky.
Hey I don't know how much progress you've made with this but I've recently implemented something similar with Cloudfront and S3. Happy to help out where I can if you're still working on this.
Hey William, thanks for the offer. For now I decided not to waste anymore time on it for the mvp and am just using standard SSR with a lookup from the subdomain. I’d like to improve it in future iterations if the project proves successful. I’ll keep that in mind as I progress.
If you find a way, let me know 👍