Envelope – Postgres database to web app with just HTML and SQL
envelope.xyz
envelope.xyz
Envelope is a complete platform that makes building web apps on top of PostgreSQL easy.
Envelope is free, open source, offered under a PostgreSQL style license, compatible with modern and mobile browsers, production ready and available today at envelope.xyz.
All you need to know is SQL, and some HTML and you can publish your database as a web application with Envelope!
Envelope source code is available on Github but free installers are available for Mac, Linux and FreeBSD. Visit envelope.xyz and click on "Install" to get your copy.
Easy when it is a simple CRUD app? When does 'easy' stop and the real work begin?
>...production ready and available today...
What are some production apps that have been built with this tool?
>All you need to know is SQL, and some HTML and you can publish your database as a web application with Envelope!
Is that all? Again, is this just for a simple CRUD app? If not, then for a substantial application, what do you mean by "some HTML"?
What are the real world uses for this? I didn't really get a clear picture of that from your web site.
Edit: These questions sounded a bit snarky. Not my intention. If I had a better idea of what this was actually used for it would help.
Envelope includes the Greyspots framework which is a collection of web components that talk to PostgreSQL through the Envelope server. These web components give you all the standard widgets that you would use to put together a normal database app. For example, all the components that MS Access provides, Greyspots framework provides. Many app developers will never need to write their own widgets, but for those who do need something unique, you can copy the closest Greyspots widget (its just a Javascript web component) and hack it into whatever you need. Then you just use it in your HTML via <my-component>. More info on Web Components: webcomponents.org
Envelope has been in production for six years. Apps in production: Foreign stocking location (barcode inventory app), Jmine (Export of a Goldmine database published to the web), all our internal apps (Address Book, Calendar, Wiki), JType (export of Suntype published to the web, Suntype is a DOS-based newspaper accounting app). Workflow Products, LLC has used Envelope for all its customers for years now.
> (SQL and HTML) Is that all? Again, is this just for a simple CRUD app?
I've worked with MS Access for many years and never wrote my own widget. Envelope is designed for these types of apps. You can build simple apps with no Javascript. You can easily build very full featured apps with a little Javascript but you don't need to write any widgets or extend the platform to do so.
So it's a reimagined ColdFusion? :-)
I've built production apps in Rails, PHP, and CF, and I've tinkered with Go, Python, etc. I still haven't found a language that gets interns from "don't know HTML" to "working dynamic web thing" faster than ColdFusion.
I looked at the Wikipedia entry for it and I see its heavy on server side programming. Envelope replaces server side programming.
CF uses server side programming to make components whereas Envelope uses Javascript web components on the client side.
Their seems to be a lot of overlap in expected use cases. Internal apps, data-driven apps.
I apologize, I can't really assert much else do to lack of experience with CF.
* Took me a minute to realize I can't scroll when my mouse is outside the center container
* Drop the sticky header/footer (let them scroll with the content)
* Add a bit more padding / line-spacing on the content on most pages (especially the Install page)
* Optimize (scale down?) the images on the support page so they load quickly (they seem pretty heavy)
Great work, though!
People that aren't seeing the changes need to hit refresh on their browser. I apologize for the confusion.
edit: Another suggestion... use a proper source of random numbers in init_aes_key_iv(). Using the time isn't good.
time(NULL) * getpid() * clock()
https://www.schneier.com/blog/archives/2013/10/insecurities_...
Edit: For reference, this is exactly how the Netscape's original SSL implementation was broken: https://web.archive.org/web/20141214141822/http://www.cs.ber...
I think it's also best to use #ifdef to prevent those hardcoded debugging keys from being included in production builds. That is, if you still need to keep them at all.
edit:
joelthelion: You are mistaken. It's not the 1990s anymore. Use the non-blocking /dev/urandom, not /dev/random. (I can't seem to reply directly to you)
This is why cryptography is doomed to fail.
This /dev/random vs /dev/urandom (blocking vs non-blocking and whether it matters) is discussed frequently on HN, usually with very long threads, and yet it still comes up.
If I want to remember whether there's an apostrophe in possessive its there's a cartoon to tell me. We need a good, accurate, fact-checked cartoon for urandom vs random.
(It's one of the things I'd do if I had FU money.)
As for actually generating random numbers, here's a good explanation from 'tptacek: http://sockpuppet.org/blog/2014/02/25/safely-generate-random...
I apologize for the certificate errors. If you want the cert its here: https://demo.envelope.xyz/certificate/index.html
I worked on an internal website once on MS stack where management wanted to try and authorize access to the webapp through access permissions to the backend MSSQL database, with the Windows Domain user getting picked up automatically through IE. It was a mess to get even kinda working and to debug, and we were never able to get it all the way working.
Fricken awesome. Very easy to sleep at night. We can do a complete security audit in fifteen minutes.
> Is having thousands or millions of users practical, or is this intended more for a limited-use in house application?
Envelope is a very small C binary. You'll find it scales way better than PostgreSQL itself and as such you should be able to apply similar strategies. You'll find your database design is way more important than the Envelope overhead. If you were going to open a site to millions of users I would consider pooling users into groups so you could pool PostgreSQL connections. Again, the bottleneck isn't Envelope, but PostgreSQL.
> Is it practical to allow new users to register on the site and have a site admin manage their roles and permissions through a web interface, or do DBAs need to manage that stuff manually in psql?
We don't use psql. Envelope includes Postage, a sort of web based PGAdmin. Developers can use that to administrate the database. We've also written a 'User Admin' app for non-developers that we've installed into some of our client Envelope instances. This allows the customer to administrate their own users.
> ...management wanted to try and authorize access to the webapp through access permissions to the backend MSSQL database, with the Windows Domain user getting picked up automatically through IE...we were never able to get it all the way working.
Sorry to hear that. Our app was originally written in just a couple of hours but I didn't even know you could get the Domain User in IE. I'll have to try that.
however, for anything that needs even slightly more complicated scenarios such as decisioning etc -- the SQL gets really complicated to build and test.
I am suggesting that this could be extended with a possible rules engine like drools, which is bundled in, and uses an object model that is the same as the table structure.
Data is fetched from the db, this data is reasoned on in the rules engine (and filtered) and this data is then either updated to the db ( sent to back tier ) or displayed on the screen ( sent to front tier ).
Hence a complicated SQL query can be broken into a bunch of rules that are reused across scenarios.
We also like having all the display handled in the html with web components. We really like the separation. I Don't think we can help you.
We use no code from the Polymer project. At the time we were evaluating we decided to go straight web components with X-Tags as a shim. I haven't kept up with Polymer but I don't think it offers database integration so its really not comparable to Greyspots in any way. Different goals entirely.
Greyspots has two parts: the front end and the Envelope Server. The front end is comprised of custom HTML tags and a JS library (We use X-tags to implement custom tags). The Envelope Server is a middleware replacement that exposes a fixed API from the front end to a Postgres database.
Not to bag on the effort though. This may come in handy for someone.
Dragonwriter's reply (below) sort of sums up my view also. I am not a fan of jamming all the logic in the SQL and like a middle layer... actually need a middle layer to carry out operations on the data before it is presented. I would prefer not to use JS for this.
But again.. I'm sure this project has some uses and would be handy for some people. It's a cool idea and a cool project and I commend your effort. It's just not something I personally would chose to use. Please don't take that the wrong way....
I'm of the school that says you should fetch the data you want because the database is optimized for data operations. can you give me an example of a data operation that's best done in middleware?
Just about anything in which the SQL query is considerably more difficult to debug or get intermediate verification than in the corresponding code.
SQL does many things well. So far, it doesn't do everything as well as middleware code. It isn't as easy to use for every use case as middleware code. Long complex SQL queries are a nightmare to unravel. Middleware code can more easily (in my experience) be broken up into smaller steps that can be manipulated and tested independently.
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.
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.)
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-r...
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.
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.
I didn't stay at that place very long.
It's all fun and games until your DB administrator gives you an Envelope built app that you have to use every day.