4 ms·

You write HTML documents to make the apps. Those are then stored to the file system like normal. When you load the app in the browser, the components (just cust

You write HTML documents to make the apps. Those are then stored to the file system like normal. When you load the app in the browser, the components (just custom HTML tags) connect through Envelope to your database. Also, it's not for static web sites, it's for web applications. For example accounting, wiki, calendar, address book etc. You'd never write any of the site in SQL. You do write your VIEWs, queries and any functions you need in SQL. Then you connect to those things with some of your components.

dragonwriter 11y ago
> You write HTML documents to make the apps. The front-end of the apps. 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 (unless you propose moving that into the front end, which I suspect you don't.) This isn't the first time this type of thing has been proposed, and its not necessarily a bad idea, 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.)
- justintocci 11y ago
  > 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.
- kawera 11y ago
  Scalability can certainly be a problem but the approach proposed here can be very useful for small internal apps which frequently have, at best, a handfull of users.

dragonwriter 11y ago

> You write HTML documents to make the apps. The front-end of the apps. 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 (unless you propose moving that into the front end, which I suspect you don't.) This isn't the first time this type of thing has been proposed, and its not necessarily a bad idea, 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.)

justintocci 11y ago
> 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.
kawera 11y ago
Scalability can certainly be a problem but the approach proposed here can be very useful for small internal apps which frequently have, at best, a handfull of users.