tl;dr A theoretical framework for dis-aggregating the web services stack and separating front end apps from back-end servers (databases, files, permissioning).  (Part of a series of posts.)

When I took programming back up a decade or so ago, I fell in love with JavaScript. The learning curve for JavaScript is such a joyful ride of wonder. We can just open a console in our browser and start writing code. We can create complex web pages on our local drive using a simple text editor. Step by step, we are empowered to create ever more sophisticated interactions. 

But then we get stuck when we want to store a piece of data in a database or a save a file in file-system, or if we want more than one person to use our new web page. Suddenly, we have to learn to set up web-servers and database servers and file servers and configure all of these so that they work together and we have to administer them so they don’t break down. 

It struck me that for almost all apps that I use or imagined I wanted, the bulk of the unique value proposition lay in the front-end interface. Besides that, the basic work of writing and reading from databases and file systems and administering the services all seemed common across all apps. I don’t mean to say that all the unique back-end processing done by web-services companies are of zero incremental value to me. I am just suggesting that many apps might work quite well with only a restricted set of core generic back-end functions.

Let’s define the “front end” portion of an app as a package of html, css and javascript files that define the interactions with the user. Then, let us assume that these apps could call on a set of common commands to access file and database servers. I will use the freezr namespace to define those commands as follows:

• freezr.db.write (data, options, callback): Write data to a database. Returns an object-id.
• freezr.db.getById (data_object_id, options, callback): Retrieve data based on its id.
• freezr.db.query (options, callback): Query the database.
• freezr.db.upload (file, options, callback): Upload a file to the server
• freezr.utils.filePathFromId (fileId, options): Create a path to be able to retrieve the file

Think of the many applications we use to store our personal content - be it a note taking app, a blogging or tweeting tool, a simple spreadsheet, a photo storage and sharing app, or any collaboration or messaging tool. I would posit that each of them could provide a great user-experience with just these few commands, and almost no other back-end functionality. Assuming there is a server that can handle the back end of these commands – that is, reading from and writing to databases and file systems - the apps themselves could all be reduced to a simple zip file containing html, css and JavaScript files running on the front end*.

I propose that personal servers have the capability to “install” such apps. In other words, you should be able to upload a zip file of html/css/js files and have it serve those pages to you, so you can “use” the app. In such a model, the app become fully portable and autonomous. I can change the app if I want. I can move it to another server and a completely different back end environment. I can delete it. I can share it. And most importantly, I can do all this without needing the permission of the app developer or anyone else. 

The portability of apps from one server to another, based on a common set of back-end commands also changes the dynamics of app distribution.  A developer can be confident that their app can be installed by anyone with a server that accepts the defined APIs. In the same way that developers know that their ios app can be installed on all the millions of iphones out there, they will also know that if they build their apps using the standard APIs, it can be installed on all servers that accept such an API.

This common interface also empowers a much larger set of developers – be they “newbies” or front-end experts. It removes the intimidating barrier of setting up and administrating servers, and gives developers the ability to create new apps and iterate on other apps. Today, motivated newbie developers can pick up JavaScript techniques by looking at the JavaScript code of web pages they like. Such a common system would allow a developer, not only to learn from other web pages, but to replicate them in her own apps, and thus recreate similar apps with improved features, or with a slightly different set of design principles or functions aimed at a particular use case. 

I would also suggest that what you lose in back-end sophistication by creating a common interface to the server, you can gain in making apps easier to write, in reducing barriers to app creation and distribution, in creating app portability, and in fostering a more dynamic environment of app iteration. This inevitably leads to greater creativity among markers of apps, which could kickstart a virtuous cycle of consumer adoption and new app development.

What’s more, besides giving us a greater variety of apps, this platform would free our data from the shackles of the web services model…

Previous Post Next Post

* Some exceptions and caveats to the no-back-end thesis:

• Clearly, a permissioning system is necessary to allow the people you want access your data, like a message or a photo. This is part of the core functionality of the back end.  (See next post. https://www.salmanff.com/ppage/2019-data-freedom)
• As mentioned, back-end service can no doubt be of value – when facebook or Twitter use algorithms to show you relevant posts, or when Google Photos highlights the best photos in a series. It would be nice to have localized ML running on our data if we let it do so. This shall be dealt with in a future post on plug-in services. In the long term, it is about defining these standard services accessible to all apps, rather than yearning for proprietary backends inextricably tied to the front-end interface.
• The trend towards frameworks such as React and Angular is not fully compatible with this vision. Of course, using them as front-end libraries is easier to envisage. Integrating them as back end services is technically feasible but would run counter to the philosophy of the service. (See post on Extensions https://www.salmanff.com/ppage/2019-extensions.)