←  Back to blog

Rapidly Build Data Apps with FuseLink

Written by Pablo Lomeli

September 04, 2015

We’re putting interface development for search and analysis in high gear. Our Fuse platform already provides the foundation for endless data-intensive applications, and now FuseLink provides the foundation for rapidly building those applications.

We began developing FuseLink several months ago as the first step in a journey to make beautiful and fine-tuned interfaces for search and analysis super simple. In short, FuseLink is a JavaScript library designed to make interaction with Fuse easy. We view this as a necessity to creating awesome experiences with Fuse. It shifts the focus from figuring out the best way for the application to interact with data, to figuring out the best way for people to interact with the application.

FuseLink will be released with Fuse 1.2 in the upcoming weeks, but let’s take a deep dive into how it looks.

FuseLink: A Quick Look

FuseLink is a collection of modules, one per Fuse API:

  • Query (Search and Analyse)
  • Users (Settings)
  • Control (Administration)
  • Tasks (Data Ingest)
  • Statistics (Usage and Monitoring)

Each module has a simplified API for interacting with Fuse in a JavaScript-friendly way. This implementation takes the burden of understanding Fuse’s implementation details off of the front-end developer with the goal of creating a great development experience while getting the most out of Fuse’s capabilities.

The JavaScript scene moves at a ferocious pace and we wanted to make sure anyone could bring FuseLink into their projects simply and with the tools they are already using. We also didn’t want to force anyone to switch to a particular stack of dev tools in order to use our library. So we packaged FuseLink as a UMD module and made it available on npm. This way it doesn’t matter if you are using CommonJS, AMD or ES2015 modules, incorporating FuseLink is just a `npm install` away.

Once FuseLink is installed, you can work with all modules or the specific ones you need.

And with this, you can bring the full functionality of Fuse into your application.

Designing FuseLink’s API

The main goal of this library is to simplify the interaction with Fuse in JavaScript.

From the beginning, we viewed FuseLink as a collection of modules, one for each of the Fuse APIs. This works well as not every application would need to interact with every module of Fuse. This design also matches how Fuse itself is built making a lot of decisions very straightforward for us. In addition, and as maintainers of the library, all changes are isolated to their respective module, making updates to Fuse easier to handle. Incidentally, this brings up another great benefit of using FuseLink – you won’t have to worry about changes to the internal implementation as they are all abstracted out.

When we started the development of FuseLink, or better said, before we started the development of FuseLink, we spent some time analyzing what makes an API great. In JavaScript land, there are multiple examples of great API design (and many, many bad examples); from fluent and imperative (jQuery) to functional and declarative (Ramda, lodash-fp). We stubbed out the API according to several design patterns, ultimately choosing a largely functional paradigm where it makes sense. The quick reason is that it provided the simplest solution for our scenario. For the longer reason, keep reading.

We wanted FuseLink to be clear and not clever. The code had to be self-evident. The following outlines choices we think help achieve this goal and together re-enforce our functional design choice.

Factories, Not Constructors

Actually, it’s probably more accurate to say that FuseLink is a collection of factories. With FuseLink, what you are doing is creating these little entities that we’ll call Clients. Code is better than words:

This is an example of interacting with a user’s setting in Fuse. As you can see, you don’t have to worry about ‘new’ or ‘this’. YAY!


We already mentioned this, but the benefits of modularity can not be overstated. FuseLink is not only modular at a high level (in-line with each Fuse API), but each component within a module is its own module as well. In the following code, we’re importing at a very granular level.

Error Handling and Logging

Standing on the shoulders of great libraries, our error handling and logging is very proactive. If FuseLink needs something from you, it will tell you. When developing, FuseLink gives you handy information if it receives data it is not expecting, making sure you only send Fuse valid requests. It’s a pseudo form of type checking to keep your applications solid.

FuseLink: An Example

One of the modules in FuseLink helps with progressively building expressions and query parameters that you can use to make requests to Fuse, all without worrying about exactly how Fuse expects this data.

Using FuseLink under the hood, we built an interactive Expression Builder that you can use to visualize and construct an expression (query) that fuse can understand. Fuse’s expressions are quite straightforward to understand, but also allow for incredible complexity and granularity. As an expression increases in complexity with more and more clauses and nesting, even the simplest syntax can become cumbersome. For example this is a very simple expression:

This expression would read like: “Give me results where name is John AND the age is 33. Not difficult to write and understand. But as we grow in complexity:

This statement becomes more involved and therefore more difficult to write or read. I actually used the Expression Builder for this expression to make life easier. You could imagine more complex scenarios like this when dealing with analytics or granular search queries.

The Expression Builder app was developed using React and Redux but that is not what we want highlight here. Instead, we’ll focus on FuseLink’s Query API module to take input and convert it into a usable expression.

Without getting too deep into the application logic, the expression builder allows you drag query operators (and, or, etc) and fill them with clauses (age >= 18, name = john, etc). Internally, the app is building a kind of a tree of interlinked nodes which it will traverses to build the expression.

This is a great example to demonstrate Fuselink’s clauseOperator and queryOperator factories from the QueryAPI module. Here’s how it would look:

In the example, you’re seeing FuseLink do the string manipulation and formatting of the query behind the scenes, leaving you to focus on building your app. This is exactly how FuseLink tries to make life easier and each module has been carefully thought out to let you concentrate on your application and leverage the power and simplicity of Fuse.

In Closing

FuseLink will be open sourced in the coming weeks and we’re excited for you to take a look. Following on the heals of FuseLink, we’re developing a Fuse-friendly component library to enable highly interactive features like autocomplete.

To learn more about what is available in the Query API and the other FuseLink modules, check the documentation at http://www.qsensei.com/docs/fuse.