Querying on a decentralized Web

Confession:
I haven’t written
any GraphQL query yet 😱

However, I’ve been
querying the Web
for 10 years already 👴

Future Web apps will access
multiple APIs simultaneously 💪
by distributing queries
across clients and servers 🚀

SPARQL closely resembles GraphQL:
it is both a query language and an API.

GraphQL queries only have meaning
with respect to one source.

# List 10 people and their names
{
  person(first:10) {
    name
  }
}

GraphQL queries only have meaning
with respect to one source.

# List 10 people and their names
{
  users(first:10) {
    fullName
  }
}

GraphQL queries only have meaning
with respect to one source.

# List 10 people and their names
{
  friends(first:10) {
    displayName
  }
}

SPARQL queries have universal meaning
across all possible sources.

PREFIX dbo:  <http://dbpedia.org/ontology/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

# List 10 people and their names
SELECT * {
  ?person a dbo:Person;
          rdfs:label ?name.
}
LIMIT 10

We can separate language from API:
this query runs partially client-side.

The client-side engine especially shines
when executing cross-API queries.

Decentralized Web apps act as views
that share access to data interfaces.

We can talk about decentralization
on very different scales.

In decentralized a app, every piece of data
can come from a different place.

Views in decentralized apps
can be built with queries.

• Queries need cross-API meaning.
• We don’t know in advance:
  • the sources we’ll need
  • the API of those sources
• APIs can—and will—change,
  but our applications should not.

Current apps send hard-coded requests
to one specific server interface.

Using queries to develop logic makes
decentralized Web apps sustainable.

An app’s queries can be run anywhere:
client, server, intermediaries—or all three.

We need to talk about
run-time cross-API GraphQL ✊
and flexible query execution
across the network 🔥