Developing Apps for a Decentralized Web
Ruben Verborgh
Ghent University – imec
Solid aims to restore choice
by separating data from apps.
-
Typical platforms nowadays store data
inseparably from an application.
- If we need to access the data, we cannot choose our app.
- If we need to use the app, we can’t choose our data source.
-
By separating data from apps,
we create independent choices.
-
In essence, we‘re taking Web apps back to desktop mode,
where one file can be opened by multiple apps.
Every piece of data created by a person
or about them, is stored in a data pod.
Apps and services appear similarly,
but they blend data from many sources.
A person can grant apps and people access
to very specific parts of their data.
Separating app and storage competition
creates better offerings for all parties.
By abandoning data harvesting,
we restore permissionless innovation.
Solid is not a platform to replace others,
but a way of building for the Web.
-
Solid is an ecosystem.
- Standards enable interoperability.
-
Solid is a movement.
- We need to shift the app builder mindset.
-
Solid is a community.
-
Building Solid requires different people,
companies, and organisations.
With JSON-LD, every piece of data
can link to any other piece of data.
{
"@context": "https://www.w3.org/ns/activitystreams",
"id": "#ruben-likes-thewebconf",
"type": "Like",
"actor": "https://ruben.verborgh.org/profile/#me",
"object": "https://www2022.thewebconf.org/#this",
"published": "2022-04-28T08:00:00Z"
}
Data shapes and their semantics
enable layered compatibility.
{
"@context": "https://www.w3.org/ns/activitystreams",
"id": "#ruben-likes-thewebconf",
"type": "Like",
"actor": "https://ruben.verborgh.org/profile/#me",
"object": "https://www2022.thewebconf.org/#this",
"published": "2022-04-28T08:00:00Z"
}
Different source data
can be concatenated.
{
"@context": "https://www.w3.org/ns/activitystreams",
"@graph": [{
"type": "Like",
"actor": "https://ruben.verborgh.org/profile/#me",
"object": "https://www2022.thewebconf.org/#this",
"published": "2022-04-28T08:00:00Z"
},{
"type": "Like",
"actor": "http://tomayac.com/thomas_steiner.rdf#me",
"object": "https://www2022.thewebconf.org/#this",
"published": "2022-04-28T10:00:00Z"
}]
}
Apps, in some way,
read–write access to a knowledge graph.
The graph is too big for any single place,
so apps reconstruct the whole via parts.
When knowledge fits in a single source,
we can place an API in front of it.
Abstract knowledge needs to be exposed
through concrete documents/resources.
A GraphQL API combines data from across
multiple resources of the “main” API.
Let’s revisit API design for cases where
knowledge cannot fit in one place.
Each data pod exposes its part
as RDF through a Web API.
Different APIs for RDF
have different characteristics.
It quickly becomes unfeasible for apps
to deal with all possible API combinations.
A GraphQL Web API is not possible here,
since there is no server to attach it to.
The app can still be written with GraphQL:
a library translates it into HTTP requests.
Solid technology marks a transition
from API integration to data integration.
-
Solid app developers face challenges…
…but API problems are not among those!
-
The way we write apps can be independent
of the Web APIs offered by servers.
- Clients can have their own abstractions.
-
Let's invest in reusable client development patterns.
The developer experience is the most
crucial factor for Solid success.
-
Front-end developers build
the apps people see.
-
Together with UX designers,
they bring Solid to people.
-
Enabling developers
means enabling ourselves.
The old way of working with RDF
followed the old way of JSON APIs.
- Gather input data.
- Send a specific API call.
- Parse the response as JSON.
- Traverse the JSON tree structure.
- Update the DOM.
The old way of working with RDF
in the browser is hard.
- Gather input data into a query.
- Send
a specific API call the query.
- Parse the response as
JSON RDF.
- Traverse the
JSON tree RDF graph structure.
- Update the DOM.
Frameworks like React combines all steps
into a seamless component experience.
<LoggedIn>
<p>Welcome, <Value src="user.firstName"/></p>
<Image src="user.image" defaultSrc="profile.svg"/>
<ul>
<li><Link href="user.inbox">Your inbox</Link></li>
<li><Link href="user.homepage">Your homepage</Link></li>
</ul>
<h2>Your friends</h2>
<List src="user.friends.firstName"/>
</LoggedIn>
Reusable abstractions can be shared
between different frameworks.
<LoggedIn>
<p>Welcome, <Value src="user.firstName"/></p>
<Image src="user.image" defaultSrc="profile.svg"/>
<ul>
<li><Link href="user.inbox">Your inbox</Link></li>
<li><Link href="user.homepage">Your homepage</Link></li>
</ul>
<h2>Your friends</h2>
<List src="user.friends.firstName"/>
</LoggedIn>
LDflex exposes Linked Data’s flexibility
without RDF’s complexity.
- data.user.name
- data.user.friends
- data.user.friends.firstName
- data.user.friends.friends.firstName
- data['https://ruben.verborgh.org/profile/#me'].blog
LDflex is a domain-specific language
for JavaScript.
-
Every expression is valid JavaScript.
data.user.friend.firstName
-
It feels like a local object.
-
It behaves like a Web query.