[ak39]

Ok, "static" here means no RDBMS-backed website. But you can still use statically generated JSON resources from a db once off. These resources can then be "filtered" and "combined" without the need for databases (not using the words JOIN or WHERE carefully).

Sounds like a great idea to overcome the need to obsess about connection multi-plexing.

[notacoward]

"Statically generated JSON resources" implies client-side rendering, and I suspect you'd find some disagreement over whether that's really static. If there's only one such resource per page, then maybe, though you'd still be losing some advantages wrt caching. If the JS running on the client has to fetch many such resources and stitch them together, then it's functionally equivalent to a standard dynamic website and shares many of its drawbacks. Sure, you distribute some of the top-level logic to clients, but the server still has to find each of those individual resources and that's basically the same load as a DB (if not worse as files).

The reason many people (including me) have gone to static generators is not just the static part but the generator part as well. It's not just static but preprocessed, no further operations necessary except to deliver dead bits. That captures all of the caching, security, and other advantages in a way that hybrid approaches tend not to.

[chriswarbo]

> "Statically generated JSON resources" implies client-side rendering, and I suspect you'd find some disagreement over whether that's really static.

> If the JS running on the client has to fetch many such resources and stitch them together, then it's functionally equivalent to a standard dynamic website and shares many of its drawbacks.

Whilst you're talking about extremes (e.g. rendering a page using Javascript), it seems to me that the most abundant use for AJAX-style approaches on static sites is when there are a few "value added" parts which rely on a DB. For example, a static blog with Disqus comments.

As other commenters have noted, the ability to push bits and pieces of functionality into JS has tipped the balance in many cases, e.g. from "if you want comments, it'll all have to be done in PHP" to "there's no point rendering this on demand, we can do the dynamic bits in JS".

[codingdave]

How do you figure that loading a static file is the same as a DB query? Even if the actual finding of the bits on the hard drive and sending them across the wire is close to the same, you don't need a database running. You get to shut down an entire process, or depending on your architecture, an entire server.

Heck, once CDNs and caching get involved, I wonder how many requests will even hit your HTTP process at all.

[notacoward]

Loading the set of files needed to satisfy a request is equivalent to a database query. Databases and file systems have to deal with similar issues when looking up a single item, so there's a clear correspondence there. The difference is that a database can do a JOIN but a file system can't (directory traversals really aren't equivalent). In that case any such logic would have to be in the client-side JS, fetching objects and quite likely imposing even more load than an SQL query would have. Being able to shut down that database process is good in a lot of ways (especially security) but reduced total load isn't necessarily one of them. You might just be shifting load to the the web server and file system. That's why I said the generator part is as important as the static part. That solves the result-aggregation problem at edit/compile time instead of request/run time, which is good regardless of whether the back end is a database or a file system.

[ak39]

The loading of static files for HTTP is significantly different from accessing the same data via databases. The biggest difference is the need for a CLI (call level interface) connection object in db access. And those things are resource hungry operations (authentication, prototocol management etc). Most times you have to pool connection objects which in itself is a resource cost.

The DB is truly the scalability bottleneck.

[notacoward]

The overhead you're talking about doesn't seem to be in the database itself, but in crappy (possibly language- or framework-specific) interfaces to them. That's an application issue, and I was talking about system issues.