In the last decade I have built many full-stack applications. As a full-stack developer I’m writing API’s all the time for the communication between the frontend and backend, but also with other services. Mostly to request or store some data using the following flow.

For me, the second and third step has always felt like a lot of overhead. Especially for internally used API’s. I’ve always wondered if there isn’t a way to automate these steps and just call a function on the other end and not be bothered with the communication details. As if both ends have melted together like this.

Luckily I’m not alone at this, and options have become available the past few years.

One of these options is meta-frameworks that bundle frontend and backend frameworks together to create a slick full-stack developer experience (like Remix).

The combination and integration provides a powerful set of functionality, and really speeds up development. But I’ve noticed that I’m hesitant to use them. While still recovering from the AngularJS shift to the new Angular, I’ve built up a fear of committing to a framework. Let alone a meta-framework. The last thing I want is to rewrite the frontend and backend and all the communication when a framework (version) gets unmaintained. I simply want to replace what’s out-dated, as fast as possible, with as little impact as possible.

This brought me to another option, a mediator tying both ends together with glue code (like Inertia).

Like a meta-framework, a mediator takes care of all the interactions with frameworks. The difference is that a mediator isn’t a framework itself, and only provides a gluing layer. Solutions like Inertia provide adapters for commonly used frontend and backend frameworks, giving some freedom of choice. For me, this already sounds a lot better. But there’s still a big dependency on the mediator and the used adapters. With every release of the mediator or framework the adapter(s) needs an update when breaking changes are introduced. As long as maintenance is active this is fine, but what in four or five years?

This made me think, and came to realize that I was looking for a ghost. The only way to avoid additional dependencies is to bind both ends together without anything in between. The search for such a solution resulted in nothing, so I let it be. But it kept me busy in the back of my mind. Until an idea popped up. Let the runtime handle it.

This has been the trigger for the development of Jitar, a distributed runtime for JavaScript and TypeScript applications. It’s a configuration only solution, that doesn’t live in the code. Server functions can be imported and called directly in the client.

import { someFunction } from './server';
const answer = await someFunction();

This keeps the code clean, simple and focused because there is nothing in between anymore. The client doesn’t know that the function is on the other end, and doesn’t have to know. Defining what runs on what end is a matter of configuration. It doesn’t matter what frameworks are used.

Using JavaScript / TypeScript at both ends limits the choice of frameworks, but enables running the same components on both the client and server. It also enables creating a very good developer experience because type checking and Intellisense are available throughout the whole application. This is where the other options are still struggling with.

Replacing Jitar is fairly easy. Just stop using the runtime and use something else for the communication. This most likely means building the API you haven’t built yet :-)

For me, Jitar brings the solution I’ve been searching for. It’s an open source project released under the MIT license. And currently under active development by a growing number of contributors. Feel free to give it a try. More information about Jitar can be found in the documentation and the GitHub repo.

That’s it for now. I hope you’ve enjoyed reading this article. Can you relate to the things I’m saying? What frameworks / tools do you use? Please let me know in the comments!