Would a site like stack overflow be better as separate static builds or a single app with run-time switches for each community?

Question

I'm designing a web application. I'd like to use sub-domains to split the site into logic separate sections based on some category - exactly like the stack exchange websites do. I'm currently aware of two approaches to this ...

1. One large application that gathers context from the current domain (or some other way) and renders X or Y template based on the sub-domain. I view this as a lot of run-time logic that selectively renders the correct items based on the current sub-domain.
2. Multiple application "builds" that are each individually hard-coded for their sub-domain, but still likely re-use a lot of shared code from the other sub-domains.

My web application is written using JS and React, and I bundle it using webpack. The approach for each of these scenarios seems straight forward in terms of how I get from here to there.

My question is, based on the stack exchange example and my description, which approach is "better"? Does either one have any gotchas that would be nice to know? I'm currently leaning towards the individual static builds per each sub-domain, because that seems pretty intuitive and easy to maintain.

• Robert Harvey: You might find this interesting: nickcraver.com/blog/2016/02/17/…
• Winston Ewert: How different are your sections? For stack exchange all the sections of the website are pretty much the same, with the differences being a few places where text specific to a site is inserted, or the style. There isn't any obviously apparent cases where there is special logic for different sites, but you talk about run-time logic which makes it sound like your case is different.

Answer 1

You're asking the classic multi-tenant question.

Personally I would - and have - maintain a single copy of the application. It would look up the subdomain in the db to grab a site id, grab the info about the site, and show the relevant content. Templates and images can be stored by putting them into a directory named the same as their subdomain or site id. So /subdomain1/logo.png, /subdomain2/logo.png, etc. With regard to the db, I'd use a single database unless given some requirement to keep data from the different sites separate.

The problem with having multiple copies of the app is straight forward - you have multiple copies of the app to update whenever you make changes. The only time I would use multiple copies was if there were significant differences that went far and beyond what could be configured at run time. Its certainly not a big deal if you only have 3 copies of the application, but what happens when you have 1,000 subdomains?