We review Vulcain, a new protocol using HTTP/2 Server Push to create fast and idiomatic client-driven REST APIs.

Developers have been struggling with performance bottlenecks for their web APIs for years. Some web developers were trying to solve the dilemma with asynchronous processing as far as back as 2013. Others have gone on to experiment with other formats and programming environments over the years, with mixed results.

In a bid for speed and performance, some developers have been turning to GraphQL to consolidate their requests into one API call. It’s also quick and easy to work with GraphQL. You end up making a lot of sacrifices, some of which can be quite serious, when you choose GraphQL over HTTP, where it is quite possible to make true REST APIs. Especially with the introduction of HTTP2/HTTP3.

Vulcain is a new protocol created by developer Kevin Dunglas that uses HTTP/2 and its Server Push function in conjunction with the hypermedia capability of HTTP. It also comes equipped with an open-source reverse proxy so you can turn any existing web API into a Vulcain API.

Here’s our review of the Vulcain API, so you can decide for yourself if you want to incorporate it into your web development stack.

Vulcain Review

Vulcain: a protocol for creating REST APIs by Kévin Dunglas. Github repo. It also includes an open-source Gateway Server to use with existing APIs.

There are so many reasons why you might want to make or take advantage of a REST API. It’s very scalable, for one thing. Data isn’t tied to particular methods or resources, giving the end-user the ability to make different types of calls and return different types of data. It also supports a wide array of different data types, unlike SOAP. RESTful APIs can handle XML, JSON, or YAML, among others. REST APIs are also stateless, which means that API calls can be made independent of one another.

Unfortunately, some performance bottlenecks, like over-fetching and under-fetching, have prevented traditional Web APIs from truly taking advantage of REST architecture. Many of today’s solutions, including GraphQL and JSON:API, get around these problems using HTTP/1. These solutions cause additional problems with HTTP logs, cache, and security, unfortunately.

Vulcain takes advantage of some of the new features in HTTP/2, luckily, eliminating the need for these workarounds. The most important may be Server Push.

What Is Server Push?

Accessing a website has always involved some sort of call and response. A device makes a request to a remote server, which then returns the requested content. Both forms are traditionally handled with HTML. The HTML resource returned by the server is further parsed by the browser, which calls up the necessary scripts, style sheets, and images.

This creates additional steps after the HTML resource has already been returned, delaying rendering and increasing page load times. Server Push remedies this issue.

Server Push allows a website to “push” assets to a user without them having to ask for them. It lets the server send the resources they know an end user’s going to need before they’ve explicitly asked for them. This was also possible in HTML/1, though. What wasn’t possible was caching. This means that certain elements would have to be retrieved every single time, increasing page load time and eliminating many of the perks of using Server Push in the first place.

Thanks to the multiplexing abilities of HTTP/2, numerous Server Push assets can be shipped in parallel. This means that resources can be stacked and sent all at once rather than having to be called individually. This makes Vulcain even more streamlined and efficient, reducing page load times even further.

Pushing relations in Vulcain

What Is Under-Fetching and Over-Fetching?

One of the reasons developers turned to GraphQL over REST is under-fetching and over-fetching. Both have negative repercussions on your bandwidth.

Over-fetching is when too much data is retrieved from a call, resulting in unused data. Under-fetching is when not enough data is returned for an endpoint, resulting in a second endpoint needing to be called.

Neither of these is all that common, but they do happen. This is especially true when it comes to scaling and iterating your products.

Vulcain Vs. JSON

JSON is one of the most widely used data interchange formats on the web. It can transform data at any point in the data transfer, from the server to the endpoint or even on the same machine. With JSON being so powerful and popular, what are the advantages of using Vulcain as a data interchange format?

For one thing, JSON has no error handling protocol. When it doesn’t work, simply nothing happens. JSON is also not very secure, which is probably its biggest drawback. A JSON service that receives a JSON response wrapped in a function call, it will execute that function.

Vulcain & GraphQL

Vulcain was largely created to remove the need to have to use GraphQL, which is largely meant as a way to consume APIs. For those who’ve gotten used to using GraphQL or just like the interface, you’re in luck. It’s quite easy and intuitive to use Vulcain in conjunction with GraphQL.

All you have to do is make your GraphQL requests like you would normally do. These are converted into REST requests by using Vulcain headers and a dedicated JavaScript library. You can use libraries like ‘apollo-link-rest,’ which converts all of the GraphQL requests into a format that Vulcain can handle.

This also solves potential issues you might run into running GraphQL on the server-side.

Querying and filtering with Vulcain with the Fields HTTP header

Vulcain API Review: Final Thoughts

The internet is built on RESTful principles. Hypermedia is what separates web-based resources from a regular, static database. Making web services that can take advantage of RESTful architectural styles takes full advantage of web-based technology. It also used to be prohibitively slow, unfortunately,

Frameworks like GraphQL were created to solve some of these problems. They came with their own difficulties, unfortunately, mostly in regards to security. Vulcain makes the best of both worlds, giving you speed and security.

That’s not the only benefit, either. RESTful architecture makes web services infinitely more scalable, which your clients will love. You’re much less likely to have to worry about broken links or addresses when you use RESTful architecture.

Vulcain takes full advantage of HTTP/2 and HTTP/3 to create a framework for the next generation of web services. This is particularly true of Server Push, whose multiplexing capability seems to have powerful potential.

Vulcain’s ability to convert other web APIs into its format is its other greatest strength. You won’t have to change the APIs you consume while still being able to take advantage of HTTP/2 and HTTP/3’s capabilities.

Vulcain is totally free and open-source. It does take a little bit of work to get it running out of the box, however. If you’re new to working with or programming APIs, you might need to spend some time getting used to its format. It might be well worth the time and effort to do so, though, with its powerful and useful built-in library. It also integrates automatically with GraphQL, so you don’t have to choose one or the other. Considering that a lot of websites and digital tools haven’t been formatted to work with HTTP/2 and beyond yet, that gives you an opportunity to integrate Vulcain into your workflow now, and get acclimated to the format.