New Enterprise Web App Design Choices for 2016

stack designs for 1993, 2000, and 2006 enterprise web applications were simple . the advent of client-side mvc in 2012 gave you interesting possibilities and continued a shift of onus of development towards the browser (and javascript). those two blog entries above are from early 2012. here’s the pics from them together, to recap:

there’s a whole push for "serverless" applications presently. i’m only going to focus on a very small subset for this blog entry—where the app is served up statically from one domain and the data for it is coming from a different domain via cors . while that data could also be from a server written by you in your regular choice of backend 3gl, i’m only going to focus on designs where you’ve written no logic whatsoever into that data store:

the server handling the data provision and accepting back the updates is, in fact, a data-store that can speak http and knows about cors. couchdb has been around for a long time and is hugely attractive for many reasons. online, firebase would be an example too, if you don’t want to own your own data. both have their own custom over-http wire language that works well for them, and use the http verbs - get, post, put, delete.

facebook’s graphql, in the last couple of years, makes for a very compelling standard (albeit post-centric) here’s my elevator pitch for graphql:

a comprehensive over-http api standard for data,
that easily caters for schema changes over time.
it is designed for machines, but is wire-debuggable
by humans. it should supplant rest.

graphql capable stores could be deployed to host the data, and leave you in a more elegant place than the custom over-http apis of couchdb and firebase. there are some purpose-built adapters for postgres that allow for a translation between graphql and postgres’ sql dialect. those are graphpostgresql and postgraphql . again, i’m not deploying logic to those (controllers, etc). instead, i’m sending requests that conform to graphql’s pseudo-functional dsl, and they do the interop with the postgres database.

here’s a test on github of a graphql layer on top of couch (i.e. couchdb could end up being graphql-capable too.)

anyway, i love the idea of the browser speaking straight to the database for certain categories of enterprise applications. less code quite often means better, and this certainly is that. look at the pics again: the transfer of logic from the server to the client over 20 years, but also the feeling that javascript libraries on the browser side are allowing us to limit the code we write there. while web apps are still unacceptably expensive to make, things are looking better and better.

see also the couchdb/svg/angular/cors and firebase/angular demo apps i made last year.