Databases have failed the web
josephg.com
Databases have failed the web
1–10 of 144 posts
Re: Databases have failed the web
#2Learn More About Hymenotomy
Re: Databases have failed the web
#3I serve many, many millions of rows, collect real-time statistics, push real-time updates, and maintain data integrity and consistency... all from a single database server. If our workloads require it we're prepared to scale out horizontally. I'm really looking forward to PostgreSQL 10's new parallel query features for some of our analytics work.
Stack Overflow runs everything across what, 4 MS SQL Servers in total?
How has that "failed the web?"
Re: Databases have failed the web
#4It isn't that "everybody emulates the VT-100 for some reason" but that the VT-100 was the first terminal to support the ANSI standard for control codes and that that standard has been evolving ever since.
Re: Databases have failed the web
#5This is an interesting article.
And he gets a lot of things right – having a way to do queries against a database directly, being able to get changes directly is useful.
And GraphQL, for example, offers exactly that – there’s even a plugin to directly build a GraphQL API from your postgresql database. Although this still can’t send changes over the net, so you can’t have an always up-to-date view of the database.
But while this and Firebase¹ solve the problem of offering an API directly for a database, he’s missing to address the other task frontend servers do: They can render stuff on the server, in case you actually do have just a dumb terminal.
And that’s something that’s very useful for websites, as usually servers are more powerful than smartphones, and you need to do your computations somewhere. A web service applying deep dream to an image can’t run it in the phone, nor in the database – it has to run it on a specialized server
But it’s indeed a good question why there’s little academic research into changing the way web applications work. We’re already making databases directly open via GraphQL APIs, we’re separating statically hosted content into CDNs, so how can we combine this, and work truly "serverless"²?
[1]: Firebase is a great tool for prototyping your app, but if you want to run it it’s usually too expensive, and relying on proprietary Backend-as-a-Service technology has proven to be a bad idea already when parse.io shut down.
[2]: Serverless here meaning that you have no specialized application server – you have a general database able to handle all your applications, a general CDN, and all special code for the app is handled within the database, or triggers of it.
Re: Databases have failed the web
#6To be honest, this article seems pretty insubstantial. To the best of my ability to discern, the only concrete complaint is that access control is too coarse on modern databases, although it's not really specified in what way this is true.
Re: Databases have failed the web
#7This is an interesting article. And he gets a lot of things right – having a way to do queries against a database directly, being able to get changes directly is useful. And GraphQL, for example, offers exactly that – there’s even a plugin to directly build a GraphQL API from your postgresql database. Although this still can’t send changes over the net, so you can’t have an always up-to-date view of the database. But…
>there’s even a plugin to directly build a GraphQL API from your postgresql database
Would like a link for this.
Re: Databases have failed the web
#8I really disagree with this - separation of concerns is incredibly important. Why does the database server need to do everything my application server does now?
I don't want to have to know about how my database works internally just to implement a new feature in my application. I don't want to worry about a junior dev corrupting data while building a login page.
My "simple old-school" database is reliable and consistent BECAUSE it's been tested for years. My application server is not because it's solving a new problem (And that's OK, I won't lose customer data if someone can't login).
Re: Databases have failed the web
#9I agree with the article that modern middleware is too fat, and we could make more reliable systems by leaning on a full-featured database.
I disagree with the three reasons he gives for why we have fat middleware today. PostgreSQL solves 1 and 3, and PostgREST solves 2.
Re: Databases have failed the web
#10This is an interesting article. And he gets a lot of things right – having a way to do queries against a database directly, being able to get changes directly is useful. And GraphQL, for example, offers exactly that – there’s even a plugin to directly build a GraphQL API from your postgresql database. Although this still can’t send changes over the net, so you can’t have an always up-to-date view of the database. But…
>there’s even a plugin to directly build a GraphQL API from your postgresql database Would like a link for this.