Fuego is a social extensible Web service built on NodeJS and PostgreSQL. It provides an open database for experimental applications, UIs, schemas, and data-formats.
Currently Fuego has (plans for) APIs for:
- Forums
- User accounts
- Uploading Dat Archives
Fuego is still in early development. Everything is subject to change.
Fuego is a Web service built in concert with a Web browser named Beaker.
Beaker uses the Dat peer-to-peer hypermedia protocol to host websites. Dat is a bit like BitTorrent. It lets users fork, share, and deploy applications from the device; you can start a new site by simply generating a keypair, and publishing the site-files on the network.
This p2p deployment network is key to the fun. By removing the friction of the hack/share/deploy cycle, we let users share their creations freely.
What Fuego provides is a central backend for Dat apps to read/write to. Its APIs provide generic data models (such as Forums) which can then be extended with custom attributes. Different "coordination fields" let apps identify the schemas, formats, and modules they use. It'll be noisy, and it won't always work right, but it will be fun!
Fuego is a general-purpose backend to applications, with no server-side middleware. This is known as a Two-Tier Architecure, and it's also in line with the NoBackend philosophy. Parts of Fuego are inspired by the remoteStorage spec.
Fuego provides a predefined set of data-structures with extensible schemas. These predefined structures enable Fuego to provide aggregation queries, caching, and fine-grained permissions, without needing to trust users.
Any database should provide aggregate knowledge of the current state, such as "number of votes on this post," or "last user to comment on this thread." SQL databases do this with relational queries, using joins and groupings. NoSQL databases use computational piplines such as MapReduce.
Neither of these solutions would work in a Web-facing database. If the query-model is too open or programmable, it'd be possible for users to DoS the database with expensive queries. Query cost should be predictable so that rate-limiting can be effective, and the data model should be predictable enough for caching to be applied.
Fuego's solution is to create a suite of common application data-structures, such as "Forum Threads," "Calendar Events," and "Polls." These structures will include fixed properties and relationships which support the most often-needed aggregate knowledge. Users/Applications can then extend the structures with additional properties. Basically, Fuego has a fixed approach to normalization and the resulting queries.
Returns:
{
forums: Array of {
id: String
owner: UserId
createdAt: String
title: String
description: String
}
}
Returns:
{
id: String
owner: UserId
createdAt: String
title: String
description: String
topicSchema: JSONSchema
postSchema: JSONSchema
}
Expects:
{
title: String
description: String
topicSchema: JSONSchema
postSchema: JSONSchema
}
forum
ForumIDoffset
Numberlimit
Numberinclude
Array of strings, properties to include from the topic schema. Can be '*' to include all.
Returns:
{
topics: Array of {
id: String
author: UserID
createdAt: Date
title: String
properties: Object, defined by include
}
}
include
Array of strings, properties to include from the topic schema. Can be '*' to include all.
Returns:
{
id: String
forum: ForumID
author: UserId
createdAt: Date
title: String
properties: Object, defined by include
}
Expects:
{
forum: ForumID
title: String
properties: Object, must validate against the forum's topicSchema
}
topic
TopicIDoffset
Numberlimit
Numberinclude
Array of strings, properties to include from the post schema. Can be '*' to include all.
Returns:
{
posts: Array of {
id: String
author: UserId
createdAt: Date
properties: Object, defined by include
}
}
include
Array of strings, properties to include from the post schema. Can be '*' to include all.
Returns:
{
id: String
topic: TopicID
author: UserId
createdAt: Date
properties: Object, defined by include
}
Expects:
{
topic: TopicID
properties: Object, must validate against the forum's postSchema
}
Returns:
{
id: String
createdAt: Date
}
There are several existing platforms/protocols that are similar in scope to Fuego, but each has limitations that make it unsuitable for Fuego's vision of providing an extensible database Web service with open schemas and data formats.
Hoodie provides an API for building client-side applications without thinking about the backend. It uses CouchDB to sync the backend with data stored in the browser, which allows applications to operate in the face of poor network connectivity. The project's maintainers claim that "Hoodies' API is optimized for...being intuitive and accessible.". By default, Hoodie includes modules for user signup, data storage, data sharing, and sending emails, but it is extendable beyond that core functionality.
It does not appear that the platform is suitable for rapid deployment. By the project maintainers' own admission, "unfortunately deployments aren't really easy yet."
remoteStorage is an open standard for enabling unhosted web applications. It intends to free app developers from the burden of hosting and maintaining a central database, and to grant users full control over where to store their application data.
remoteStorage's data model is built on "documents" and "folders", wherein folders reference a list of and documents documents have the following properties:
- Version
- Content type
- Content length
- Content
While this is sufficient for many use cases, it isn't conducive to advanced querying, thus limits the scope of applications that can be built with the protocol.
Much like Hoodie and remoteStorage, Firebase, deployd, Kinvey, and Parse (RIP), offer(ed) a platform for building applications without needing to maintain a backend data storage service.
While each of these tools is well-received and appreciated by many developers, they each suffer from a lack of extensibility and less than convenient data export, which is a central piece of Fuego's goal to build a platform in which users can seamlessly and freely import their data into any compatible application.