The definition of headless is clean cut — or it should be, at least. In practice, there are blurred edges, generous interpretations, and shifting definitions.

Headless architecture “decouples” a website’s front-end from its back-end. Alex Shiferman, CTO at Nuts.com, describes the front-end as the “presentation layer.” It’s the content, user interface, and user experience. He calls the back-end the “business engine.” That’s services like your payment processing, order tracking, fulfillment, and so on.

Likewise with composable – it also has a fairly straightforward definition. In a composable application, each element works independently from one another and can be replaced without causing any impact on the rest of the system. Third-party experts build the elements to solve a very specific problem, to be easily plugged-in, implemented, and connected through an API layer to other pieces in the system.

Think of the composable enterprise as Lego, says Shiferman. Instead of buying one complete tool — an eCommerce platform, a finance system, a project management tool, whatever — you buy building blocks. Whenever you need a new tool, you combine blocks to create something bespoke for your organization. 

“If I buy a dollhouse for my daughter, it comes fully built,” he continues. “But if I buy a Lego dollhouse, she can move things around and make it really her own.”

What fake headless & fake composable look like?

While the definitions of these frequently used terms are fairly straightforward, the execution varies quite a lot. As the word du jour, headless, pops up in advertising copy, marketing material, and product documentation far more than it ought to. When fake headless services work their way into a technology stack, it can cause havoc.

With due diligence, however, software buyers can sort the wheat from the chaff. Although lots of services claim to be headless, the fakes rarely stand up under scrutiny. Here are three questions you can ask to test vendors’ headless claims.

#1 Do their APIs represent a subset of platform functionality?

“When you get into it, you might find that APIs are a subset of overall platform functionality,” says Shiferman. “You can only do this from the admin console. You can only do that from the command line.”

This tends to exhibit one of two ways. Either the API simply doesn’t offer some functionality or the API operates differently to the admin console. Both create similar complications: unexpected coding, unnecessary complexity, and abnormal operations.

#2 Did their service develop from an on-prem product?

The composable enterprise and headless are relatively new ideas. They only started gaining real traction in the last five to 10 years. Keeping that in mind, it’s unlikely that you’ll find a headless on-prem service. It just doesn’t make sense. With vendors who have recently moved their service away from on-prem, it’s worth investigating their technology.

“I’ve seen old school on-premise eCommerce vendors try to transition to a cloud offering,” says  Shiferman. “I’ve seen them struggle. That’s not how they build their tools and platforms. There’s often an underlying foundational limitation. You can’t just easily port a product to the cloud.”

#3 Do they have any limitations, however small, on the front-end?

 When vendors develop products and then transition to headless architecture, they often get near but not quite the whole way. True headless, for example, can support any front-end. Fake headless, meanwhile, might have limitations or requirements. 

True headless & true composable enable engineers to say “Yes, we can do that”

All-in-one platforms are like cooked spaghetti — services are tangled with each other. When multiple engineers are working on the same platform, it can get messy. Say someone changes the ordering system. That has knock on effects to the check out, fulfillment, inventory management, and a dozen more services. On the other hand, composable enterprises are like uncooked spaghetti. Each microservice stands on its own. “Every piece of functionality is distinct,” explains Shiferman. “You have clearly defined contracts. You can really manage everything at a very granular level.” Because each function is distinct, you can have 50 people all working on the same platform without everything becoming chaotic.

“You have to figure out how to support business users in different ways,” says Shiferman. “Ultimately, your goal is to enable either customer experience or business user experience. If you start saying, ‘Do this piece of work here, but do this piece of work there,’ it becomes hard to manage.”

Fake services hamstring an organization’s ability to scale. With truly headless services, engineering teams know they have all of their tools in one place. They have “full feature coverage,” as Shiferman puts it. But say one microservice turns out to be a fake headless product. When the engineers start building, they’re going to discover inconsistencies. Those inconsistencies will demand a new architecture. Suddenly, your team is supporting not one, but two, architectures, which is no easy feat.

Discover true headless search

“The term ‘headless’ is already part of the problem,” said Neha Sampat, CEO of API-first CMS Contentstack, during an interview with Diginomica. It implies the concept is merely cutting away the front-end and adding an API.

But headless is far more than that.

Headless means offering everything via API, not a selective subset of features. It means supporting any front-end, not just a chosen few. It means building API-first from the ground up, not adapting dated architecture to piggyback on the latest trend. It means being automatically omnichannel and vertical agnostic.

We built Algolia to be truly headless, starting with an API-first foundation. From the moment we started in 2012, our customers have been able to access every last mote of functionality via API — indexing, search, filtering, analytics, merchandising, A/B testing, everything. “With headless services, APIs are your starting point,” says Shiferman. “APIs are your foundational layer. The lowest common denominator is always the API.”

Because we have a clear distinction between front and back-end, Algolia supports any type of front-end — JS, React, Angular, Vue, Android, iOS, Kotlin, and so on. We built an agnostic product, too. Algolia isn’t just a media or marketplace search function that you can crowbar into different use cases. It can handle any device, any use case, and any vertical because we built it to be flexible and adaptable.

Going headless

So what are time-strapped engineers, designers, and technical leaders to do? How do you sort authentic headless microservices from the fakes? 

To unlock the benefits of headless, engineers, designers, and leaders must ruthlessly evaluate microservices, cutting away the fakes and frauds to reveal genuinely headless products. We can help with that. When you do that, you can usher in a new era of powerful and personalized software for your organization.

What are you waiting for? Discover true headless search today.