[rzarate]

Kudos to the author(s) for building LiteFS, it really does seems like an interesting project. However, I can't see this being a popular pattern moving forward (or at least I hope that's not the case).

Replacing APIs with DBs in real production workloads? Really? I don't have much else to say. Also, the value proposition is not quite clear to me. Using replication to have local, read-only replicas of an SQLite db might admittedly be beneficial for high read-throughput workloads but I'd imagine that the DB might have serious size/read-throughput constraints due disk space and network overhead from replication.

My takeaways are: a) This doesn't sound like a reliabile pattern to build distributed services. b) It's bad PR for fly to publicly push for the adoption of this pattern. c) It's even worse PR that fly is using this internally.

[jampekka]

Replacing APIs with DBs is a good idea. I don't have much else to say.

[TjZkxkxeky]

It's certainly not a new idea, however. Every product that allows backdoor access into their database directly has effectively done this. Hope you have your schema correct when your customers build a mountain of cards on top of your database schema.

[jampekka]

How does this differ from them building a mountain of cards on top of your API?

The schema used by the public API doesn't have to match the database layout itself. E.g. views can be used for this.

A lot of APIs are quite straightforward mappings typically from REST/GraphQL to a database, often via some sort of ORM or other abstaction. These extra layers mostly amount to needless complexity, more surface of bugs, lots of busywork and worse API usability.

[TjZkxkxeky]

It differs dramatically. Your API is likely much much smaller than the inherent API of SQL tables. It's a difference in degree that is a difference in kind.

Anyways, every old idea must be retried.

[jampekka]

I don't see much difference between a set of SQL tables to a set of API endpoints that let you list a set of "objects". At least in read-only cases with no sensitive data.

Of course there's the big difference in that with SQL you can compute and join tables server side, sparing a lot of traffic of doing this manually (or coming up with ad-hoc ways of doing it). It's not like the SQL itself is gonna substantially change.

The schema can be restricted or kept compatible with e.g. views as mentioned before (although I'd go more for the consenting-adults philosophy here too). Too heavy queries can be limited with e.g. query timeouts, quotas or query priorities. And you usually have to do such things somehow anyway.

I have hard time seeing major concrete problems with the approach that don't have existing straightforward solutions. I do see a lot of unfounded FUD.

For writes and sensitive data it gets trickier, but for many cases it would be probably easier to secure the database interface than to do it ad-hoc on a "business layer".

I haven't heard the idea of public facing SQL querying floated around much in at least over 20 years. When it's proposed, the response is usually knee-jerk no, as seen in most comments in this post.

Also I'm not much of a fan of SQL itself but I'm against the current software development philosophy that computing should be made as restricted, layered and inflexible as possible.