Paul Hammant's Blog: New Enterprise Web-App Design Choices for 2016
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 attractice 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.
blog comments powered by Disqus