On: Skip the API, ship your database

[EMM_386]

I have never in my career spanning decades have I had to ask a server to send me a dataset so large that it "most tables in the database on first page load".

In what use case do you run into that?

I'm lead and an architect on an enterprise application at the moment that drives the whole company. It's your standard configuration, front-end, APIs, SQL. The system requests what it needs to fulfill only what functionality the user is dealing with.

Earlier in my career I was dealing with large enterprise desktop applications that talked directly to the database, with no centralized API. Some of them had thousands of individual desktop clients hitting a single multi-tenant SQL server. No problem, SQL Server would handle it without breaking a sweat. The bandwidth to an indidual client was fine. It was fast. And that was 20 years ago.

[mickael-kerjean → EMM_386]

I did faced this scenario a couple time when working on application that would work offline, a few of those I was involved in:

- try to reduce the amount of paper based catalog we were sending out to customers, those were a couple thousands of pages and not cheap to produce, not cheap to send and would get deprecated very quickly. The web app would be pulling the entire catalog at first load so customers could go in remote location and still be able to use the catalog

- a web app for sales that was intended to be use on customer site containing all the marketing materials and much more during presentations on site without ever having to connect anywhere

[cj → EMM_386]

> In what use case do you run into that?

Single-tenant simple sites without permission checks with limited content volume.

Of course you can also do the same in a multi-tenant environment but naturally you wouldn’t be returning all rows in the database.

[hobs → EMM_386]

This is pretty much what many SPA were/is, dump entire app state relevant on first load and then offline is no problem.