Do We Really Need A Web API: Simplifying Communication Between Layers

Do We Really Need A Web API: Simplifying Communication Between Layers

Typically, when we build a single-page application, the frontend and the backend are living in two very separate worlds that are connected with a web API. Even if they are implemented with the same language (JavaScript), they cannot communicate directly using this language. They need something else in between, so we build a web API (REST, GraphQL, etc.), and that complicates everything.

In case you worry about the interoperability of Liaison with other environments (like many people did), please head over to my last article on the Liaison Blog:

https://liaison.dev/blog/articles/How-about-interoperability-oy3ugk

This has been a common issue for a long time with web apps. It might be helpful to look at other frameworks that have been down this road before, like Meteor. This was one of the allures of Meteor 8 years ago, that you would write completely isomorphic client and server side code, and there is no API layer between them; you simply write as function calls as if it’s all on the same side.

I personally use Meteor, so I’ve been using this functionality for a long time. I generally feel like there’s been a lot of reinventing of the wheel over the last few years to replicate what Meteor has done (everything from reactive frontend frameworks to API abstraction to GraphQL subscriptions), but for those who don’t use Meteor, I can see this being helpful in achieving one of those aspects.

Certainly, Meteor and Liaison share some similarities, but they are quite different beasts.

I don’t think Liaison reinvents the wheel. If it reinvents something, it is the axle so we can build nicer wheels on top of it. What I mean is that Liaison operates at a much lower level than Meteor. It is neither a framework nor even a library. I like to define it as a “language extension”.

Liaison adds primitives to the JavaScript language to enable “cross-layer class inheritance”. This low-level approach doesn’t trap us in a framework, and it opens a lot of possibilities.