Reaction’s Take on REST APIs

“Does Reaction have a RESTful API?”

It’s a question we get all the time.

It’s also something which warrants more than just a one-word answer.

REST has been powering many of the web’s major APIs for decades now. So, it’s no surprise that we receive this inquiry from developers on a near-weekly basis. Our response? It’s possible, but it’s not really our preferred method of choice.

In this blog post, after exploring the pros and cons of REST, we’ll show you how to convert a Meteor application into a REST API with just one step. We’d also like to present some preferred alternatives, like GraphQL, which we think will shape the future of web APIs. To learn more, read on.

What is a REST API?

REST (Representational State Transfer) is a style of architecture through which communication occurs. It uses HTTP to move and receive data, bit by bit, from the client to the server. Much like HTTP, all REST APIs function on the CRUD (create, read, update, or delete) model, which means that every request that’s made fits squarely into one of those four actions. It’s also important to note that with REST, every individual component of your page is tied to a specific request or call.

Take, for instance, a WordPress blog. You may notice that a blog homepage is typically made of several moving parts, from blog posts to sidebar links to comments to the footer. For each of these components to load on the page, an individual call must be made for each one. With REST, all of that data is broken down into single atomic units on the server-side, then ultimately assembled together on the page.

Adding REST in Reaction

Here’s the long and the short of it: while we don’t have REST enabled by default, and while we don’t have any imminent plans to build a standalone REST API, it is 100% possible and effortlessly easy to configure. All you have to do is install simple:rest, a package that turns Reaction’s existing DDP publications and methods into REST endpoints. This allows users to integrate their backend into a native mobile app, or to even query data from a Rails or PHP app. No code required — you literally just add the package.

REST harbors some limitations, partly because it was invented decades ago for traditional computer networks. For one, it’s stateless, so every request made is treated as if it’s coming from a stranger with no context. And on slower mobile networks, users have to be careful with how many requests they make due to data charges, slow page loads, limited connectivity, and more. That can get tricky when you’re running an ecommerce shop, where lots of moving parts, from cart items to order lists to product listings, make up the overall user experience.

RESTful API’s are something we, or anyone else, can add easily. But once you use DDP or GraphQL, you’ll probably ask yourself, “Wait, why would I wanna do that?”

More on DDP

If you’ve been looking into Meteor, then you’ve probably read up a little about DDP (Distributed Data Protocol). At Reaction, it’s the method we currently use as our default mode of client-server communication in lieu of REST. Here’s why:

DDP allows users to access data using WebSockets, a protocol that establishes a line of connection between the client and the server. This line stays open and persistent, which is precisely how Reaction can be real-time by default. Typically with REST, whenever a user makes a request to the server, it will respond to the client with static data. With DDP, changes on the server-side appear dynamically, all without refreshing the page! To learn more about how DDP works across different applications, check out this super-handy blog post about reactivity.

Real-time reactivity is the beating heart of Reaction. Still, DDP’s limited adoption outside of the Meteor community can be a drawback (although WebSockets are fairly well-known universally). That’s where GraphQL and Apollo comes in.

Why GraphQL?

Unless you’re up-to-date with open source, it’s likely that you haven’t been exposed to the magical world of GraphQL, Facebook’s API query language and runtime. But after getting past the initial learning curve, intrepid developers will soon realize that it is truly a game-changer for both devs and users alike — in fact, once it’s widely adopted, we think it’s going to herald in a new standard.

With GraphQL, you can get as much data as you want and exactly what you need. Send a query specifying all the pieces of data you need on the client side and the server will return everything back in one single request. For people who consume APIs and get very granular with data, this is an obvious benefit. In fact, Facebook invented GraphQL in 2015 to display newsfeeds to mobile users quickly, even during times of limited network connectivity. With a REST API, it would take close to 70 different calls to the server to piece every single element of your newsfeed together. But when you implement GraphQL, there’s no limit to how many things that can be queried and pulled in one request, and it’s agnostic to your language or database of choice.

We think every developer should take a look at GraphQL. Once somebody gives you a walkthrough and you see how easy it is to implement, things click pretty quickly. And if you’re still keen on REST — don’t worry. It’s still an option, even after adopting GraphQL.

What’s Next

So is Reaction going to convert to GraphQL? Well, it’s not on our Product Roadmap just yet. A project of that breadth is going to take some time, especially when we’re still in the middle of converting Blaze to React. Ideally, we’d like to expose our data API via GraphQL, which is currently how our managed platform and reaction-cli communicates through. But once it’s ready and in our app, it will be the method we officially recommend.

This piece was originally posted as a blog post for Reaction Commerce.