After months of hard work, we recently released the Relevant iOS App. With Relevant we are breaking existing paradigms on how we glance at and interact with content and services on the web, while giving users back some of the time that they would otherwise spend jumping from app to app, and website to website. We do that by turning apps and web services into cards (more here).

Cards, as independent interactive units, are a peek into the future of mobile interfaces.

When we first started working on Relevant, we knew two things: Relevant Cards had to be beautiful, and they had to be universal; meaning that their content could come from any source on the web with little restrictions. The beautiful part deserves an article of its own. In this post I would like to elaborate more on the infrastructure of Relevant Cards, and how we made them universal.

Cards as JSON Objects

Since Relevant Cards needed to be lightweight and downloadable, we decided to make them JSON files. These JSON files would contain instructions on how to access different sources and APIs on the internet, and how to map these sources’ data to the card’s labels and images.

The infrastructure behind Relevant Cards needed to be extremely flexible without jeopardizing the simplicity of the card building process. One should be able, for instance, to fetch an array of products from a given API, then fetch more details about each product, such as ratings, from completely different APIs, by conveniently linking the elements of all APIs together.

It thus became clear that we needed to give our infrastructure the capabilities of a universal API aggregator. One where instructions would be easy to modify, flexible, and hosted externally. This will create an ecosystem where cards can easily evolve, unlike native apps which tend to be stuck into hard-coded compiled modules.

APIs are Not Standard

Web services and APIs come in all different shapes and forms. Some list-based APIs return an array, while others may embed it deep into an outer object. Some of them use pagination, while others take an explicit page parameter. Add to this hundreds of date/time formats, a couple of URL standards, and a tendency to randomly add quotes around doubles and integers. Most developers who try building broad API aggregation systems quickly find themselves coding into a nested if-else block fractal hell.

We wanted something more powerful. We needed our platform to be independent of the quality of the API’s design or its data. So after much trial and error, the core chucks of a Relevant Card’s JSON ended up looking something like this:

A big part of our API aggregation infrastructure has to do with powerful back-end engines. However, the JSON-based syntax we built on top, which we coined REL, deserves the special mention.

REL has been designed from the beginning to be easily translated between a text editor and a graphical interface for making cards, as well as to limit the card maker’s reach to a predefined set of templates/macros. The graphical interface will be released in the near future.

So just for fun, here’s a quick intro to how the syntax works.

Quick Intro to REL — The Fancy JSON

REL looks like an adorned JSON format, but at its core, it is a purely functional programming language with lazy immutable variables (meaning nothing is computed or fetched unless needed and only when needed), and dynamic scope.

Types and Variables

REL’s types are the standard JSON types; numbers, strings, objects (dictionaries), and arrays. In fact most numbers, strings, or arrays in REL are parsed literally.

However, some objects have special meanings. The key-value pairs of an object having a “_RETURN” key, are parsed as variable-value pairs instead. Variables are then referenced or concatenated using curly brackets, as in “{variable_name}”.

For instance, REL parses this object

{
    "foo":1,
    "var":2,
    "_RETURN":{"_MATH":"{foo}+{var}"}
}

as the number 3.

Functions

We’re frequently adding new built-in functions to REL. These functions look like objects with certain special keys that begin with an underscore (“_”). The function “_MATH”, from the above example, parses a string into a mathematical expression and returns its result.

Other built-in functions include “_URL” which downloads JSON from a web address, and “_PATH” which seeks values within a JSON object or array. Those two functions are the basis for the API aggregation capabilities of the REL Engine.

Control Flow

Built-in functions such as {“_IF”: , “_THEN”: , “_ELSE”: } and {“_LOOP”:{“_ARRAY”: , “_EACH”: }} serve the purpose of control flow statements, but unlike in non-functional programming languages like C or Java, they always return a value.

Possibilities are Endless

We’re excited to see the Relevant App at its full potential, and we’re working on a drag-and-drop GUI for making cards. In the meanwhile, anyone with enough time in their hands can take on the challenge of making cards with REL. Download the free iOS app and head on to the documentation to get started.

We’re starting with the iOS app, but we’re not dozing just yet. Imagine being able to use an accessible tool to aggregate and mashup APIs and content on any platform. Keep an eye on relevant.ai for surprises. Check out our growing library of cards and please let us know what you think about Relevant!

If you liked this article please recommend it and share it with others.