Solid for Application Development: Faster, Cheaper, Better

One of the key components of Solid is that it "separates the apps from the data storage", to quote Inrupt’s co-founder Sir Tim Berners-Lee in a Washington Post interview a few years back. But what does this separation mean? Well, a few interesting things, but I'd like to touch on an aspect rarely mentioned, which is that it makes app development faster, cheaper, less risky and more predictable for organizations.

Solid is also touted as the next phase of the Web. Let's remember though that the Web is not a standard, but more of an architectural style that defines how to use existing technologies like HTTP, URLs and HTML to get a system more valuable than the sum of its parts. Similarly, Solid is mostly an architectural style defining how to use existing web technologies to build apps, extending the Web beyond these commonly used technologies to incorporate identity, authorization and Linked Data.

A universal way to access backend data

Now, let's dissect the way apps are built. They usually have a frontend and a backend. Backends do a lot of interesting things, including (micro)services powered by some databases. These services offer APIs used by frontends to deliver an optimal user experience.

Next, let's look at the cost and effort. The vast majority of it goes into developing the backend. While frontends execute in the users' browsers or on mobile devices, the backend requires deployment and operations. It requires constant attention, monitoring, capacity planning, cyber defense mechanisms, maintenance and fixes. All of these require time and budgets, and every change adds risks for the enterprise.

Solid’s architectural style offers a simple solution: What if the Web offered a universal way to access backend data? What if we build a technology that allows data to be stored in a container of sorts—or a Pod in Solid lingo? By putting data relevant to a specific entity (such as a user), this entity could now control access to its data. That would become, effectively, a general purpose backend for any application. 

As Solid continues to be more widely adopted,  Solid servers would eventually become a simple-to-acquire commodity, available to enterprises with all the relevant features out-of-the-box, eliminating most of the costs and risks associated with custom backend development. With a Solid architecture, wouldn't backend projects be more focused and developed faster? Wouldn't project budgets be significantly smaller? Wouldn't that significantly reduce the risks for an enterprise?

The benefits of Solid may not be obvious when a first application is built. However, when the second, or better yet the tenth application is built, the speed of development and the advantage of reusing existing data will quickly become apparent. Why? Two reasons: First, a Solid Pod is a single source of truth for data; and second, in reality enterprises, for all sorts of reasons, use different kinds of databases, so a lot of integration work to make data available is simply not necessary with Pods.

Here’s another way of looking at it: Because Solid decouples applications from data, it reduces the impact of changes across apps. This is a direct consequence of the discipline imposed by Solid when building apps and the main source of reduced risk and both development and maintenance costs when building apps.

While Solid provides many benefits for the backend and operations, there are also positive implications for the frontend. Solid provides a universal (HTTP-based) API for accessing data in Pods, serving as the backend. Therefore the need for custom APIs is dramatically reduced and the attention is shifted, appropriately so, to data modeling. This model creates a smaller learning curve for frontend developers and leads to less miscommunication and a smaller need for internal documentation of custom APIs. It also involves less time, lower costs and lower risks.

Linked Data: Making the backend more valuable

As the Solid architectural style becomes more widely understood, so will the importance of data modeling. One of the stumbling blocks of Solid adoption is its use of Linked Data. Linking data is an important and very useful feature of Solid, but technically an optional one. Developers can build applications without taking advantage of Linked Data—it is a perfectly valid way of harnessing Solid Pods that we use already. 

However, when Linked Data is used, it becomes a de-facto persistence layer of a graph. One can then use any number of graph or database technologies to power searches or any other algorithm, making the backend so much more valuable and powerful. More importantly, if changes are to be made to the graph database schema (such as supporting other vocabularies), they can be made without impacting existing data and apps. This strategy again leads to less cost and less risk. For a more in-depth coverage of the benefits of Linked Data, I can recommend Dave McComb's book The Data-Centric Revolution.

In future posts, we’ll elaborate on the impact of Solid on app design and implementation, and best practices for writing idiomatic Solid apps. The undeniable advantages of using Solid, should lure you into at least trying it. Beware though, you may get hooked!