Envelope is designed to completely replace the middleware that sits between your web server and your PostgreSQL database. It does this by exposing your database, documents and other actions via a fixed API. You can publish your Envelope apps to the web or just your local network easily by configuring it behind NGINX or your favorite web server.

All security in Envelope is handled by PostgreSQL by using PostgreSQL ROLEs. This greatly simplifies the security model. Users log in to Envelope through a web interface and get an encrypted cookie, then whenever they attempt to access something, Envelope uses their PostgreSQL user name and password to log in to the database and see if they have permission. PostgreSQL will either answer the request or error depending on if they have permission.

A professional web developer would build a web application. But web applications are typically complex. Website architectures usually involve a browser, a web server, middleware and a database. When a request gets sent out by a browser it travels to the other components of the system and a response comes back. We call this the request/response cycle.

A typical request works like this: The user clicks a link, which causes the browser to make a request of the web server.

BROWSER => WEB SERVER

The web server hands the request to the middleware and the middleware creates an answer for that request. The middleware could be PHP, Perl, Django, Drupal, Ruby on Rails, ASP.NET, Java or some other software. There are many choices.

WEB SERVER => MIDDLEWARE

Sometimes, the middleware will talk to the database before it creates the answer. That would look like this:

MIDDLEWARE => DATABASE

Once the answer is ready, the middleware hands it back to the web server, which sends it back to the browser.

MIDDLEWARE(answer) => WEB SERVER => BROWSER

With this basic understanding we can point out some issues:

For every feature that you want to add, you need to write code in the middleware to handle each request. But every time you touch the middleware you may create a security issue, a performance issue or a maintenance issue because there are no rules or limitations. You can do whatever you like in a middleware stack. In practice that means your application is only going to be written as well as the confluence of many factors allow. Despite extensive experience, high skill and thoughtful discipline, requirements can change and cause what looked like good decisions to seem poor in hindsight.

Due to the sheer number of components, the request/response cycle can be difficult to debug.

In order to be very good at web programming you need to learn a lot and most of what you learn needs to come from the school of hard knocks. And if you become unavailable and want someone else to maintain the system you first need to train them in how it works. This is often the catalyst for rewrites, but many rewrites come from the need for a new feature that is just very difficult to add due to the way the application was originally written.

For these reasons, broken website implementations are very common.

For every item that you want the user to see, you need to write HTML or Javascript. The problem is, HTML doesn't provide the standard controls needed for your typical database application. There are hundreds of frameworks that claim to make app development easier but they never do the thing that we want.

There's no combo box. In fact, there are no HTML elements that interact with a data source at all. Simple application building blocks like a form or a dialog box have to be custom coded using primitives like <div>, <input> and <button>. If we do power through it all and build something useful its difficult to read the code because we end up with primitives strewn everywhere. Now add on top of that the difficulty of making it all mobile friendly and its not a surprise that there exists a brisk business in Javascript frameworks. There is a lot of pain out there and it isn't being addressed by current frameworks.

Now you're probably thinking, "So what? This is how everyone does it, why should I do it differently?"

Because it doesn't have to be this way. Web application development isn't painful out of necessity. Its painful because we don't use the right building blocks. Modern web development with middleware is like building a skyscraper with two by fours when we need steel girders.

Poor security leads to pain. The old paradigm of web development leads to extensive undocumented API's of questionable security. Since every change to the application can involve touching widely used code, security auditing is prohibitively expensive. In fact, security auditing is often ineffective because many times the only person available that can read and understand the code is the programmer. Penetration testing is very difficult, time consuming and its usually impossible to prove you have total coverage.

Developers are moving with the fashions in such high numbers these days because they are in pain. Developers who are happy aren't constantly flocking to the next great Javascript framework. For example, a while back there was a new tool that let you do all your server development in Javascript. That's sounds cool. That way you don't have to shift your frame of mind language-wise when you shift from developing on the client or on the server. But then we found out that, productivity-wise, it was pretty much a wash. Turns out you still need to think in a different paradigm when programming on the server even if the language is the same.

There was a fashion where you'd have an app generate an interface to a table that would provide Create Read Update and Delete functionality automatically. This involves dynamically generating the entire page. But then it tends to be difficult to customize individual pages. A RAD CRUD solution ultimately does not address the real desire of most developers. We don't want a wizard to make a standard page. We want an easier way to make any page in any app. A comprehensive set of powerful widgets will trump a page factory any day of the week.

Another problem is that the reality of how the web works can cause good programmers to honestly disagree about what the Model is, or where the View code belongs, or what the Controller should do. There are quite simply lots of ways to do it. So if you give three web developers the same stack and tell them to use MVC or some other paradigm, they'll come back with code all over the place. And it isn't their fault.

All of this of course often leads to poor product quality, rewrites, possibly a security breach. And we're still in pain. But it doesn't have to be this way. We need to think carefully about what we really want and what would be useful. Then get the tools that would give us those things.

We want to be able to write a website application that is perpetually maintainable. We don't ever want to code ourselves into a corner. We want our web apps to be reliable and not fragile. So when we write an app we want to know that we're not messing with a dependency from another app and breaking something by accident.

We want to be highly productive. We'd have more potential customers or more profit if we could build things twice as fast. And we need something future proof. We don't want to look a customer in the eye and say we'd need to rewrite part of the website or write a whole new server application to add one new feature.

We want to be able to sleep at night. We want a secure web app. No one wants to write a web app that gets broken into and made into another headline. Over the last ten years there have been many dozens of high profile security breaches and the cost has been enormous. Its time we upped our game.

Here are the four parts of our application.

BROWSER <=> WEB SERVER <=> MIDDLEWARE <=> DATABASE

We can't get rid of the web browser. We still need to serve up web pages so we can't get rid of the web server. What about the database? Well, for your typical business application, a database really is the best tool for the job so we don't want to throw that away.

Lets look at this another way. Where are all the security issues? In the middleware. Where are all the maintenance issues? In the middleware. Where is the vast majority of my code that needs to be maintained, extended and debugged? In the middleware.

Here's a fact, IF we could replace the middleware with a black box that had a fixed API THEN things would be better.

BROWSER <=> WEB SERVER <=> FIXED API <=> DATABASE

And not just from four problems to three problems better, not linearly better at all. It would be exponentially better. Security would improve right from the start and never get worse over the life of the application. Maintainability is now moot. Think about when you write code in a web page. Its self contained. If you do write something reusable you push it to a script file and reference it from other web pages. There is no code in the web server in this architecture so that can't become an issue. In the database you write your tables, your views, some functions and stored procedures. So long as you maintain proper permissions everything is secure. There isn't anything that can get out of hand anymore. Performance would not degrade as the application grows. In fact, the size of the application would be totally irrelevant.

Well, this all sounds really nice, right? But how are we going to do it? Well, let me introduce you to envelope. Envelope is a program that sits between your web server and your Postgres database.

BROWSER <=> WEB SERVER <=> ENVELOPE <=> DATABASE

Unlike middleware programming, Envelope is a simple binary with a fixed API. You can't change it. No application code goes in there. No business rules go in there. That means you need to put all your code elsewhere, such as in the HTML, the Javascript or in the database using your favorite procedural language.

We encourage you to give Envelope a try and let us know if you have any feedback.