3 ms·

Meanwhile I'm moving more of my software into PostgreSQL. What I started as a dumb data store has gained foreign keys and check constraints, multi-join views an

Meanwhile I'm moving more of my software into PostgreSQL. What I started as a dumb data store has gained foreign keys and check constraints, multi-join views and recursive queries, even some crazy functions. Some day I hope to move authorization into it: instead of opening the database with an all-seeing user, open it as the current web user, who has a corresponding user account in the database, and is restricted to seeing data through GRANT and CREATE VIEW. So my web apps are becoming strongly concentrated in the edges: more and more business logic and control in the database; more and more user interface logic in the browser. It is mattering less and less what runs between them, be it PHP or Node. That section's job is mainly to take the data out of the database, wrap it in templates, and send it on its merry way.

vetinari 10y ago
Are you sure about that? Using a connection pool to the database is a form of optimization. Otherwise, you need a connection per user. This is not being done even in network where is was easy to do that for years (i.e. those using Kerberos auth for users, where the webserver just could forward Kerberos tickets to the database).
- combatentropy 10y ago
  I've heard of others using connection pooling but have never gone for it. I have read about problems where certain things can get left around or intermingled among users that shouldn't be. For example, a database transaction that doesn't cleanly close: the next user can walk right into the middle of it. I'm sure it saves some time, but so far the speed-up hasn't seemed worth the risk, and I've been at it for about a decade. We use one server for few thousand corporate users a day, and everything is usually fast. When things are noticeably slow, it is usually from a page loading too much JavaScript, images, etc., that it doesn't really need. When it's the database, it's because of a poorly written query taking a few seconds. Rewriting the query resumes normal operations: split-second page loads.
cel1ne 10y ago
Checkout postgrest: http://postgrest.com/ http://postgrest.com/

vetinari 10y ago

Are you sure about that? Using a connection pool to the database is a form of optimization. Otherwise, you need a connection per user. This is not being done even in network where is was easy to do that for years (i.e. those using Kerberos auth for users, where the webserver just could forward Kerberos tickets to the database).

combatentropy 10y ago
I've heard of others using connection pooling but have never gone for it. I have read about problems where certain things can get left around or intermingled among users that shouldn't be. For example, a database transaction that doesn't cleanly close: the next user can walk right into the middle of it. I'm sure it saves some time, but so far the speed-up hasn't seemed worth the risk, and I've been at it for about a decade. We use one server for few thousand corporate users a day, and everything is usually fast. When things are noticeably slow, it is usually from a page loading too much JavaScript, images, etc., that it doesn't really need. When it's the database, it's because of a poorly written query taking a few seconds. Rewriting the query resumes normal operations: split-second page loads.

cel1ne 10y ago

Checkout postgrest: http://postgrest.com/ http://postgrest.com/