4 ms·

The conceit of this article seems to be that all web applications are merely CRUD apps that do nothing but talk to the database, thus databses are "failing the

The conceit of this article seems to be that all web applications are merely CRUD apps that do nothing but talk to the database, thus databses are "failing the web" for... not being more than just a database. I see a number of problems with this: 1. Not every web app is merely CRUD. Some of us work on apps that do quite a bit more than CRUD, and the CRUD part is relatively small and boring. 2. There's very little respect here for the idea that good utilities should do one thing and do that thing very well. Lots of people need relational databases. Not everybody needs a relational database that can automagically filter out XSS attacks and serve HTTP responses.

josephg 10y ago
Author here. I think CRUD apps are the most boring example. But think about something like Slack. There's some data and queries, sure - but the app also needs realtime feeds. It needs to have triggers running notification tasks off changes made. There's lots of stuff that need to happen as a result of data changes. Doing all that stuff purely at the application layer is an architectural mess. What you really want is an event log of messages, with workers and search indexes listening on that. Maybe later you'll want to add full text search via elasticsearch - and that needs to be kept in sync via the event log as well. Rolling your own version of all this stuff correctly is really hard. Either you do it inside postgres using triggers and stored procs, or you use kafka and invent your own complicated system to handle conflicting writes. Or you add hooks in all the places in your app where you do writes, but that introduces its own set of consistency problems. Samza, Datomic, Bottled Water, Couchdb and firebase all solve at least some of this stuff better than classic SQL stores. Its time for relational dbs to get on board. Being no more than a database isn't good enough anymore.
- cookiecaper 10y ago
  Your complaint is that SQL databases aren't message brokers? SQL servers have been abused as message brokers for decades. It's not the use case they're designed for, and while a plugin that integrates this type of functionality into PgSQL would be interesting, there's no reason to expect them to assume that problem space. If you want the database to handle the incoming message streams, then set your consumers to call a stored procedure. That should alleviate your concern with conflicting data models.
- kisstheblade 10y ago
  Why can't they (the "workers") just listen on postgres? https://www.postgresql.org/docs/9.0/static/sql-notify.html https://www.postgresql.org/docs/9.0/static/sql-notify.html
- dragonwriter 10y ago
  Aside from real-time feeds, RDBMSs usually provide the functionality you are discussing, and some can provide real-time change notifications to clients, as well.

josephg 10y ago

Author here. I think CRUD apps are the most boring example. But think about something like Slack. There's some data and queries, sure - but the app also needs realtime feeds. It needs to have triggers running notification tasks off changes made. There's lots of stuff that need to happen as a result of data changes. Doing all that stuff purely at the application layer is an architectural mess. What you really want is an event log of messages, with workers and search indexes listening on that. Maybe later you'll want to add full text search via elasticsearch - and that needs to be kept in sync via the event log as well. Rolling your own version of all this stuff correctly is really hard. Either you do it inside postgres using triggers and stored procs, or you use kafka and invent your own complicated system to handle conflicting writes. Or you add hooks in all the places in your app where you do writes, but that introduces its own set of consistency problems. Samza, Datomic, Bottled Water, Couchdb and firebase all solve at least some of this stuff better than classic SQL stores. Its time for relational dbs to get on board. Being no more than a database isn't good enough anymore.

cookiecaper 10y ago
Your complaint is that SQL databases aren't message brokers? SQL servers have been abused as message brokers for decades. It's not the use case they're designed for, and while a plugin that integrates this type of functionality into PgSQL would be interesting, there's no reason to expect them to assume that problem space. If you want the database to handle the incoming message streams, then set your consumers to call a stored procedure. That should alleviate your concern with conflicting data models.
kisstheblade 10y ago
Why can't they (the "workers") just listen on postgres? https://www.postgresql.org/docs/9.0/static/sql-notify.html https://www.postgresql.org/docs/9.0/static/sql-notify.html
dragonwriter 10y ago
Aside from real-time feeds, RDBMSs usually provide the functionality you are discussing, and some can provide real-time change notifications to clients, as well.