Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Databases have failed the web

josephg.com

Post reply on HN
Print view View original

91–100 of 144 posts

Re: Databases have failed the web

#91

Post by josephg »

jandrewrogers wrote: post #73

In the mid-1990s, some of the most complex web applications were implemented inside the database! I was the technical lead for a production web app written in... 250,000 lines of PL/SQL. This model had some significant advantages and worked surprisingly well considering that Oracle was not designed with that (ab)use case in mind. So why didn't this model become common given that it was relatively elegant and capable?…

> As a practical matter no one designs web apps this way any more so there is no market for it.

Well, the problem is that I'd say PL/SQL isn't a good choice of language to implement a web templating engine. And the web framework selection is ... lacking. And its hard to hire engineers who know PL/SQL.

But even if the database has a native JS engine or something there's also a separation of concerns problem here. But if the database simply exposed an event stream and versioning information from queries, we could write our applications in whatever language we want. They can listen on the database's event stream and invalidate caches or eagerly re-render the app as data changes. And if you have a kafka-style event log they can live on other machines and run in separate processes.

From any angle I think the samza/datomic model is simply a much nicer architecture to do this sort of thing. More ergonomic than the pl/sql approach, and certainly much nicer than what we have now using databases as dumb stores.

Re: Databases have failed the web

#92

Post by laythea »

pbnjay wrote: post #32
Klathmon wrote: post #20

Earlier quoted context omitted.

I'd argue that there is some merit into combining those things, or at least changing where the separation happens. There might be performance improvements and better abstractions from moving what is traditionally known as "application code" into a place where it has better, more direct, access to the data. I'm not saying that we should be throwing out SQL and starting over, but if there are massive gains to be had by…

Stored Procedures have been around for a long time, so it's very easy to put some business logic closer to your database without resorting to the level of integration suggested by the post.

yes but in my experience even though they exist, many applications are written in an outside environment, in order to take advantage of software engineering facilities that are not available "in the DB". This competes with the idea of merging the app into the DB and is why the split is common place.

Re: Databases have failed the web

#93

Post by spacemanmatt »

Animats wrote: post #63

And, to fix it, he says, we need functional programming at the database level! What? Today's databases are probably the best part of the server side stack. The parts that talk HTTP, JSON, and do business logic are usually worse.

I find the DB part to be the only sane part of my stack these days. It's funny though, I got the hang of functional programming by cross-training in SQL first. Writing attribute expressions is a lot like writing pure functions of immutable data.

Re: Databases have failed the web

#94

Post by josephg »

takeda wrote: post #57
PaulHoule wrote: post #4

It 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.

Yep, I also wanted to add that if you use Mac, or Unix you most likely don't use VT-100. Yes, they all support VT-100, but that's because it became a standard, and essentially any device understands it. For example if you connect to a network switch you know that it will at least support VT-100 so you have a common protocol to communicate with it, and be able to switch to a modern protocol if the device supports it.…

> I feel like the author is a front end developer and just hates the fact that JavaScript in the browser can't communicate with a database server directly.

Author here. I hate the fact that here in 2017 we still write login code, again, for every application. I hate the fact that if I want to trigger re-renders, or run workers off database changes all my options suck.

> it is also possible that database could provide a generic enough interface that would work

Exactly. It doesn't have to suck - our databases could provide a nice interface to do all this stuff cleanly instead. We just need a resumable event stream, with versions and some other API tweaks and we can do computed views out-of-process of the database, written in whatever language I want. I'm firmly of the opinion that all databases should provide a Samza / Storm / Kafka / etc style event log.

Re: Databases have failed the web

#95

Post by hive_mind »

YCode wrote: post #67
hive_mind wrote: post #44

Earlier quoted context omitted.

Lindy Effect.

I can't tell if you're describing or disputing the comment you replied to. Are you saying SQL survived only because people have used it for so long and therefore its sustained use isn't an indicator of value?

If you read up on what Taleb writes about Lindy Effect, you should be able to understand.

OP said that it's probably good because it has lasted so long. I would agree.

Re: Databases have failed the web

#96

Post by josephg »

vog wrote: post #83
AgentK20 wrote: post #49

Earlier quoted context omitted.

That's what this article is arguing against. The "good practice" is more precedent than anything. Sure, we can argue that it "adds security" to the mix by adding a separate layer between the user and the actual place where billing info and passwords are stored, but if that front layer gets breached then you're still screwed. From what I understand, the article suggests the reverse of what you're saying. Not necessari…

> What about if the DB itself supported a psuedo-PHP runtime, or better yet closer to native code? Note that in PostgreSQL, user defined functions can be written in many languages, including SQL but also Python (very well supported) and PHP (not so well supported, but doable).

Post author here. I actually think it would be much cleaner to support an event log API and run this stuff out-of-process. My database shouldn't have to support the language-de-jour, and I don't want my react rendering process slowing down my database servers. You can totally decouple this stuff with a clean kafka-like eventlog API, but postgres doesn't provide one.

Re: Databases have failed the web

#97

Post by carsongross »

Look, kids. You are going to have to have an execution layer you can trust somewhere, you can't just expose your data store directly to the outside world or you run into an infinite number of security issues[1]. (Not that this is stopping people from doing exactly this these days.)

That somewhere is going to be a server side execution environment, and it will be separate from your data store so you can scale these concerns independently. Additionally, you are probably going to want a DSL for your data access as well as a highly tuned indexing system for your data store.

We have systems that do this, they are called databases. Are they perfect? No. Nothing is. But the idea that they have "failed the web" is so over-the-top childish that, like the author says at the end of his post, I'm not inclined to be charitable.

[1] - http://intercoolerjs.org/2016/02/17/api-churn-vs-security.ht...

Re: Databases have failed the web

#98

Post by dragonwriter »

carsongross wrote: post #97

Look, kids. You are going to have to have an execution layer you can trust somewhere, you can't just expose your data store directly to the outside world or you run into an infinite number of security issues[1]. (Not that this is stopping people from doing exactly this these days.) That somewhere is going to be a server side execution environment, and it will be separate from your data store so you can scale these co…

> Look, kids. You are going to have to have an execution layer you can trust somewhere, you can't just expose your data store directly to the outside world or you run into an infinite number of security issues

The security issues your source points to in new, SQL-like (but not SQL) general query APIs (GraphQL, etc.) are actually already fairly completely addressed in modern relational databases, which are designed for multiuser access with users having different permissions. So exposing the datastore directly solves, rather than causes, the issues it raises with common generalized near-SQL query APIs.

Re: Databases have failed the web

#99

Post by taeric »

dpark wrote: post #80
taeric wrote: post #64

Earlier quoted context omitted.

You gain making users of your system a first class and distinct part of your application from those that maintain it. Or, would you rather swap a regular user entry into and away from a maintenance role when you hire/fire someone? (Certainly doable, but seems extreme.) You also gain the ability to severely lock down destructive permissions to the database behind fairly rigid authentication rules.

> Or, would you rather swap a regular user entry into and away from a maintenance role when you hire/fire someone? (Certainly doable, but seems extreme.) How is this more extreme or more cumbersome than deleting an admin account? For that matter, you could also just give admins a separate admin account even if they are also users. When I worked in "IT support", I had a separate admin account even though I had a user…

You probably already have a separate system that is regionally and logically separated from your application to control access to company resources.

The argument seems to be that the logical separation is not desired. But that implies that if I were an employee of Google, I should have a specially flagged Google account. And if I were to leave, I would lose that flag. Which means it should probably not be a simple flag, anymore, but a date gated property which may go off an on several times.

And already, that sounds more complicated than just keeping your application accounts distinct and completely separate from your organizations accounts.

Re: Databases have failed the web

#100

Post by ruslan_talpa »

agentultra wrote: post #79
ruslan_talpa wrote: post #56

Earlier quoted context omitted.

Exactly! How about "developers have failed the databases" The majority of the developers don't use (or don't know how to) views/stored procedures/roles/triggers. Whenever you mention something like this you hear "omg, you put business logic in the db? everybody knows that does not scale" or "we deconstruct our request into a few simple queries instead of a join so we run super optimal"

I suspect it's because many developers are introduced to programming through web development. The pedagogy fails them and they go on to successful careers believing falsehoods. It's hard enough to learn a programming language the first time that I can see how ORMs and frameworks relieve the burden of having to learn SQL, RDBMSs, etc. However it's a convenient lie that seems to rarely ever be corrected. The reality is…

I also have a theory about this when it comes to a bit older devs (like 30+, yours i think relates to younger ones). We've entered our careers in the days of php4 and mysql4 and in those days if i remember correctly, mysql did not have all these nice features postgres has today and also the query planner was not that powerful, joins indeed were painful. We did not have access to databases like Oracle so this is where the culture of fat middle layer comes from, because it was the only way. But ppl, 15 years have passed, databases are monsters now, postgres can do 1.5M tps on a single box. How many of you are working on projects with that kind of scale ...
Post reply on HN