by

Tridion and Node: Using Node as an API

Reading Time: 4 minutes

This is inline with a small series of posts I want to write as a follow-up to my presentation at the Tridion Developer Summit this year on Tridion and JavaScript. In this article I want to discuss some specifics of using Tridion and Node together, where Node is used to provide a Rest API.

We’ll walk through motivations for this approach, the benefits, and the pitfalls of such an architecture.

Tridion doesn’t care how content is consumed

Tridion’s pretty powerful in a lot of ways. One of its strengths is how it can syndicate content; content could be put on a mobile site, a desktop site, and in 45 languages  — all without it blinking a digital eye. Another is that it separates content creation from content-consumption; it doesn’t care if you’re consuming raw HTML or JSON. A third powerful feature is that it doesn’t tie publication to publishing; it can put your content in a database or on a web server.

This all comes together when you have a client that wants to use Tridion as the Single Source of Truth™ for web sites, web applications, and native apps.

Content isn’t always consumed on a web site

Content isn’t consumed just in web sites. It can be consumed in web applications, too. It can also be consumed in desktop applications or native OS applications (i.e. Android apps, Windows Store apps, iOS apps).

So what do we do with the fact that:

  • Tridion doesn’t care how content is consumed
  • Content can be consumed in any number of modalities

 

We think outside of the box.

Thinking outside of DXA

I often tell folks to think of DXA as three distinct pieces:

  1. Tridion-side templates, schemas, and utilities
  2. Server-side application containing views, models, controllers
  3. Client-side rendering containing an HTML prototype, CSS, and JavaScript

 

The Typical DXA application looks something like what you see above.

This means DXA works great for web sites but can fall short for web apps. When we need a highly versatile faceted search tool, a research portal, or a product picker, DXA can fall short because we’ve got content that is rendered based on a state that’s established in the browser, or events happening based on data sent do a server after a page load.

So web applications need direct access to content. Which means the traditional DXA setup isn’t going to work.

This is a great use-case for Node.js.

Node.js as a service layer

So, imagine the research portal that’s got a faceted search, search filters, breadcrumbs, internal bookmarks, highlights, and of course…content. This is an application that needs access to that content super quick.

Or imagine a Tridion client that has brick-and-mortar locations with customized displays. Real, physical displays like marquees and flipboards.

In both cases, we get MVVM applications that really just need their models. So this is a good case for an API that’s talking to Tridion’s broker database directly and rendering that content.

If these applications are highly interactive and event-driven, this makes a good case for Node.js.

So what we end up with is a Node.js-powered Rest API talking to a client side web application.

An application architecture that includes node.js providing an API layer

This approach ends up being super handy because we don’t change anything happening in Tridion. We still let TBBs be TBBs and publish JSON. We still let there be a broker database. We still let there be a standalone, static web application.

We just plug a node.js-based API in there, and that ends up being a service layer that we can use to add a whole slew of new apps.

But why Node?

Why couldn’t this be a .net-based API? Or a Java API— if you can’t think of anything worse?

As I’ve mentioned before, concurrency is Node’s strong-suit. Node will do well with multiple connections asking for the same data. This, of course, is with the caveat that you’re not doing any computations or incorporating business logic on that data.

Setting aside the benefits of concurrency, another benefit of Node is the language behind it.

JavaScript isn’t just the language of the web browser, it’s also becoming the language of desktop apps and native apps, too. So Node makes sense from an organizational perspective; the same engineers building the apps can build the APIs, too.

What could go wrong?

This approach assumes that you’re using Node with non-web-site content. You’re consuming application content.

When you’re using that Rest API to consume content for a web site, you’ll find yourself missing some really spiffy features, like link resolving and component links. As soon as you need links on pages, you’re going to be missing DXA super hard.The alternative, of course, is that you build an API that can resolve links as well as DXA can. But…Node doesn’t do computations well. A multi-threaded application will be much better-suited when you need to render linked components and resolve page links.

Node will end up being the wrong-choice if you try to transition a static, traditional HTML site onto a Node API. The API will have to get overhauled to provide features that are expected in a traditional DXA environment.

TL;DR

Node is a great extension point for your Tridion ecosystem. But it shouldn’t be the only application consuming Tridion content.