The goal of Sagrada is to abstract away the difficulty of building and scaling the underlying layers of many applications, providing a plugin library solution to a suite of services that can live on one box or many hundreds. By accessing these services over the internet, it also allows client applications (such as Firefox) to have access to these functions in a centralized cloud, while giving external developers the ability to host their own Sagrada instance should they desire.
Another Sagrada goal is to provide a deployment solution for server applications, allowing them to start as a small instance, but scale up as usage of the application grows without having to make major architectural changes.
Sagrada consists of two tiers, a service tier and an application tier. Both are designed to be scaled out independently and with (relative) ease, and can be built on any setup from a single box up to many machines across multiple datacenters.
The Sagrada interaction flow is as follows:
- User signs into BrowserID in their browser
- User makes a request to an application (or takes an action that causes an application to wish to do something on behalf of the user)
- Application performs discovery on the Sagrada instance to see which versions, if any, of the needed service are installed
- Application asks the user (via the browser) to retrieve a user token and location for the needed service.
- Browser hands the token to the application
- Application hands the provided token to the service at the location specified along with the service request.
The Sagrada application tier consists of libraries in a variety of languages that abstract away the Sagrada interaction flow into a simple function call associated with the appropriate service. The goal is to enable fast development of intermediary applications.
It also consists of an interface to a turnkey deployment solution allowing you to scale an application from a single box to multiple boxes as needed to support growth of an application.
The Sagrada service tier is composed of a set of basic services, all of which allow token-based access to resources, along with a browserid-based token generator that allows users to retrieve short-lived tokens that they can hand off to applications to allow those applications to interact with Sagrada services on their behalf.
The Service Discovery API is the fixed URL entrypoint into the Sagrada service layer. It is the URL configured in an application to allow it to work with a Sagrada service instance.
The API returns a JSON-encoded dictionary with a list of all supported services and versions, along with a URL for the token server. Note that it does not supply URLs to the other services, as those may be on a per-user basis.
The Service Discovery API does not require authentication. It returns the same result for all queries.
Service Discovery semantics are documented in https://wiki.mozilla.org/Services/Sagrada/ServiceDiscovery
Token Generation/Service Location
The Token Generation service takes a request for a specific service along with a BrowserID assertion. It verifies the BrowserID assertion and returns the location of the service, along with an (encrypted) authentication key, a consumer secret and an optional (encrypted) metadata token. These pieces of information are turned into headers that are passed into the application.
Applications will also request their own tokens to identify themselves. Service semantics will determine which combination of user token and application token are required to act on the service resource.
Token Server semantics are documented in https://wiki.mozilla.org/Services/Sagrada/TokenServer
Sauropod is low-volume, high-availability, durable key-value storage. Data is encrypted server-side for additional security.
Users have a single storage bucket, though they can have many keys within that bucket. It is designed primarily as a user metadata store.
Sauropod semantics are documented in https://wiki.mozilla.org/Services/Sagrada/Sauropod
Sync storage is high-volume, low-availablity, client-reparing storage designed for synchronizing information between multiple computers. It allows for direct retrieval through key lookup, and also modified-since retrieval.
Users maintain a series of buckets called collections in which they store data. The semantics of data inside these collections are left to the discretion of the application that generates them.
Sync Storage semantics are documented in https://wiki.mozilla.org/Services/Sagrada/SyncStorage
DurableSync has the same semantics as SyncStorage, but is low-volume, high-availability and server-repairing for situations where you don't want to rely on the clients being a source of truth for data that needs to be synchronized between them.
Queuey provides applications with a message queues, and optionally lets an application allocate message queues for each user. Message queues created for a user are readable only by the user, but writable by the application creating it.
Queuey semantics are documented in https://wiki.mozilla.org/Services/Sagrada/Queuey
Metrics and Logging
Metlog is a logging infrastructure that allows for fast logging, aggregation and display. It differs from most of the Sagrada APIs in that the application token is needed to open the channel and periodically refresh it, but authentication is not done on every request.
Metlog is also used internally within Sagrada for logging.
Metlog semantics are documented in https://wiki.mozilla.org/Services/Sagrada/Metlog
La Sagrada Familia is a Roman Catholic church in Barcelona, Spain created by the architect Antoni Gaudi. Despite not being complete, and still under construction, it is considered a masterwork, a UNESCO world heritage site and is in regular use for services.