4 ms·

> Since the application layer in a typical n-tier architecture is replaced with a generic, application-neutral layer, the back-end business logic is, of necessi

> Since the application layer in a typical n-tier architecture is replaced with a generic, application-neutral layer, the back-end business logic is, of necessity, all moved into the database Yes! Just like a typical desktop app! What we've done here is just simplify the web architecture down to a typical desktop architecture. > This isn't the first time this type of thing has been proposed, and its not necessarily a bad idea, All us desktop application developers agree. This isn't new at all. We use it every day. MS Access, .NET, Borland, Filemaker and many other tools used the exact same architecture for many many years. > but there are a number of concerns associated with it (particularly, that scaling out a typical middle-tier is often easier than scaling out Postgres, so this approach may limit scalability of the resulting apps.) Hmmm. I am not a middle tier scale person so I can't speak to comparison. I will point out you could easily have one Envelope serving out to ten PostgreSQL databases before you need to introduce another Envelope instance. Meanwile, Envelope is a microservice so scaling is just a simple NGINX config change. This looks relevent: http://spin.atomicobject.com/2012/02/28/load-balancing-and-reverse-proxying-with-nginx/ http://spin.atomicobject.com/2012/02/28/load-balancing-and-r...

dragonwriter 11y ago
> Yes! Just like a typical desktop app! A typical desktop app has the application logic in an application language, not the backend DB (if it even has a backend DB.) > What we've done here is just simplify the web architecture down to a typical desktop architecture. Relational DB backend + declarative front-end (HTML or otherwise) with no application logic in an intermediate layer between those isn't the typical desktop architecture, either. > All us desktop application developers agree. I mean, specifically, the RDBMS back-end with all business logic, generic middle-layer (possibly built into the database), and HTML front-end architecture for web apps has been proposed and provided before. But not really taken off.
- justintocci 11y ago
  Let me give you an example. MS Access and a database. Sure I could use the database as a dumb store and write reams of VBA, but that's not how I do it. I write functions in plpgsql and have minimal code in VBA. In my practice VBA and JavaScript are used in very much the same way. One of the great things about writing apps this way is you can easily migrate your MS Access database to the web. Or use both at the same time, say, MS Access for the desktop and Envelope for mobile users. Then when someone hits a "ship" button the same code runs regardless. This is the original Oracle model published in their very earliest manuals. I know lots of people don't take advantage of the database for stored procedures/functions but I wasn't thinking about them when I wrote my previous comment. I apologize.

dragonwriter 11y ago

> Yes! Just like a typical desktop app! A typical desktop app has the application logic in an application language, not the backend DB (if it even has a backend DB.) > What we've done here is just simplify the web architecture down to a typical desktop architecture. Relational DB backend + declarative front-end (HTML or otherwise) with no application logic in an intermediate layer between those isn't the typical desktop architecture, either. > All us desktop application developers agree. I mean, specifically, the RDBMS back-end with all business logic, generic middle-layer (possibly built into the database), and HTML front-end architecture for web apps has been proposed and provided before. But not really taken off.

justintocci 11y ago
Let me give you an example. MS Access and a database. Sure I could use the database as a dumb store and write reams of VBA, but that's not how I do it. I write functions in plpgsql and have minimal code in VBA. In my practice VBA and JavaScript are used in very much the same way. One of the great things about writing apps this way is you can easily migrate your MS Access database to the web. Or use both at the same time, say, MS Access for the desktop and Envelope for mobile users. Then when someone hits a "ship" button the same code runs regardless. This is the original Oracle model published in their very earliest manuals. I know lots of people don't take advantage of the database for stored procedures/functions but I wasn't thinking about them when I wrote my previous comment. I apologize.