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.

Checkout postgrest: http://postgrest.com/

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

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.

I really liked this post because it painted why JavaScript is a good language to use across so many projects. I've always loved node.js despite the many quirks but enjoy getting to use it for nearly every aspect of work. I'm hoping arduino will support JavaScript directly in the near future as well!

The simpler ATmega-based Arduino boards don't have the chops to run a JavaScript runtime. The 328P used in the Uno only has 32KB of program storage and only 2KB of RAM! The Zero, which is ARM-based, has 256KB of storage and 32KB of RAM. That's still probably too little to run a full JS implementation, but it might work if the JS is precompiled before being sent to the device.

Compare with the NetDuino, which runs the .NET micro framework. It has 1.4MB of program storage and 164KB of RAM. And even that is dealing with a binary program representation.

What is the link between Medium and JavaScript? I see a steady flux of JS-related articles on Medium. I generally can't stand Medium because it's full of hype.

What is the link between craft beer, mustaches and fixed-gear bicycles?

Handle bars?

You might be seeing the effect of millions of JavaScript programmers. What other language has so many developers?