Full Stack for All

In the beginning, there were only full-stack developers. We implemented everything in the backend with some PHP or Ruby On Rails and then, with a bit of jQuery running in the frontend, we were done.

But times have changed. Modern web apps require rich user interfaces that can no longer be rendered in the backend.

So we switched to a "single-page application" model with a frontend that entirely manages the user interface.

As for the backend, it is simplified because it only has to manage the domain model and the business logic.

The problem is that we now have to connect the frontend and the backend, and this is where things get complicated.

We build a web API (REST, GraphQL, etc.) that significantly increases the size of our code and results in duplicating our domain model.

In practice, it's like building two applications instead of one.

So we multiply the number of developers, and the overall complexity is such that we divide them into frontend and backend developers.

If you are a half-stack developer, you can only do half the work, and you spend a lot of time communicating with the person in charge of the other half.

If you're a full-stack developer, you're a real hero. You can implement a feature from start to finish in a much more efficient and satisfying way.

Dividing frontend and backend developers kills productivity and ruins all the fun.

But let's be honest, being a full-stack developer today is way too difficult.

Ideally, we should all be full-stack like we were in the beginning. But for that to be possible, we need to dramatically simplify the stack.

Simplifying the Stack

For the simplest projects, it is possible to use a "backendless" solution such as Parse, Firebase, or Amplify. But when the business logic goes beyond CRUD operations, it's not great.

Something called Meteor came out eight years ago (an eternity in software engineering). The main idea was to simplify the communication between the frontend and the backend, and at that time it was quite revolutionary. Unfortunately, the project has not aged well and it is not suited to today's environment anymore.

Recently, two projects made the buzz — RedwoodJS and Blitz.js. Both also aim to simplify the communication between the frontend and the backend, but with a different approach.

RedwoodJS simplifies the implementation of a GraphQL API and brings together React and Prisma in an opinionated framework.

Blitz.js is also a framework using React and Prisma, but it is built upon Next.js and it strives to eliminate the need for a web API.

These projects are heading in the right direction — simplifying the development of full-stack applications — and I hope they will be successful.

But let me introduce my attempt in the field — a project called Liaison that I have been working on for a year and a half.

Liaison

I created Liaison with an obsession — flattening the stack as much as possible.

A typical stack is made of six layers: data access, backend model, API server, API client, frontend model, and user interface.

With Liaison, a stack can be seen as a single logical layer that reunites the frontend and the backend.

The problem is that each layer leads to more code scattering, duplication of knowledge, boilerplate, and accidental complexity.

Liaison overcomes this problem by allowing you to assemble an application in a single logical layer.

Cross-Layer Inheritance

With Liaison, it is possible to inherit the frontend from the backend. It works like regular class inheritance but across layers running in separate environments.

Physically, we still have a separate frontend and backend, but logically, we get a single layer that unites the whole application.

When calling a method from a frontend class that inherits from a backend class, the execution takes place where the method is implemented — in the frontend or the backend — and it doesn't matter for the method's consumer. The execution environment is abstracted away.

Let's see how a full-stack "Hello, World!" would look like with Liaison.

To start, here is the backend:

import {Component, attribute, method, expose} from '@liaison/component';
import {ComponentHTTPServer} from '@liaison/component-http-server';

class Greeter extends Component {
  @expose({set: true}) @attribute() name = 'World';

  @expose({call: true}) @method() async hello() {
    return `Hello, ${this.name}!`;
  }
}

const server = new ComponentHTTPServer(Greeter, {port: 3210});

server.start();

And here is the frontend:

import {ComponentHTTPClient} from '@liaison/component-http-client';

const client = new ComponentHTTPClient('http://localhost:3210');

const Greeter = await client.getComponent();

const greeter = new Greeter({name: 'Steve'});

console.log(await greeter.hello());

Note: This article focuses on the architectural aspect of the stack, so don't worry if you don't fully understand the code.

When running the frontend, the

hello()

method is called, and the fact that it is executed on the backend side can be seen as an implementation detail.

The

Greeter

class in the frontend behaves like a regular JavaScript class, and it can be extended. For example, we could override the

hello()

method like this:

class ExtendedGreeter extends Greeter {
  async hello() {
    return (await super.hello()).toUpperCase();
  }
}

Now, when the

hello()

method is called, the execution happens in both the frontend and the backend. But again, where the execution takes place can be seen as an implementation detail.

From the developer's perspective, the frontend and the backend are a single thing, and that makes everything easier.

Data Persistence

Most applications need to store data and here also things could be greatly simplified.

The idea is not new, a database can be abstracted away with an ORM, and this is the approach followed by Liaison.

In a nutshell, the

Storable()

mixin brings persistency to your data. For example, take the following class:

import {Component} from '@liaison/component';
import {Storable, primaryIdentifier, attribute} from '@liaison/storable';

class Movie extends Storable(Component) {
  @primaryIdentifier() id;
  @attribute() title;
}

To create and save a

Movie

, you can do this:

const movie = new Movie({title: 'Inception');
await movie.save();

And to retrieve an existing

Movie

, you can do this:

const movie = await Movie.get({id: 'abc123'});

Again, there is nothing new here, it is similar to any ORM using the active record pattern.

What changes with Liaison is that the ORM is not restricted to the backend. The cross-layer inheritance mechanism makes the ORM available in the frontend as well.

Conceptually, we therefore still have a single logical layer combining the frontend, the backend, and the database.

User Interface

In a typical application, the user interface and the domain model are completely separated. A few years ago there was a good reason to do so because the user interface was essentially made up of imperative code. But now that we have some functional UI libraries (e.g., React with hooks), it is possible to combine the user interface and the domain model.

Liaison allows you to implement your routes and views as methods of your models.

Here's an example of how to define routes:

import {Component} from '@liaison/component';
import {Routable, route} from '@liaison/routable';

class Movie extends Routable(Component) {
  @route('/movies') static List() {
    // Display all the movies...
  }

  @route('/movies/:id') static Item({id}) {
    // Display a specific movie...
  }
}

As you can see, a route is simply a URL associated with a method of a model.

Here's how to implement views:

import {Component, attribute} from '@liaison/component';
import React from 'react';
import {view} from '@liaison/react-integration';

class Movie extends Component {
  @attribute() title;
  @attribute() year;
  @attribute() country;

  @view() Home() {
    return (
      <div>
        <this.Heading />
        <this.Details />
      </div>
    );
  }

  @view() Heading() {
    return (
      <h3>
        {this.title} ({this.year})
      </h3>
    );
  }

  @view() Details() {
    return <div>Country: {this.country}</div>;
  }
}

A view is simply a method that returns something based on the attributes of a model, and returning user interface elements is not a problem at all.

Since a view is bound to a model, you probably won't need to use a state manager such as Redux or MobX. The

@view()

decorator makes sure that the view is re-rendered automatically when the value of an attribute changes.

So we've encapsulated the user interface in the domain model, and that's one less layer to worry about.

Conclusion

I strongly believe that flattening the stack is crucial to make full-stack development more approachable.

Liaison allows you to build a full-stack application in two physical layers — the frontend and the backend — which are gathered in a single logical layer.

It's easier to start a project with as few layers as possible, but that doesn't mean you have to build all your projects that way.

For some projects, it may be a good idea to break down an application into more layers. For example, it may be useful to separate the data access from the backend model or separate the user interface from the frontend model.

No worries. The cross-layer inheritance mechanism allows you to multiply the physical layers while keeping a single logical layer.

If object-oriented programming is not your cup of tea, you won't like Liaison. But please don't reject OOP because you think it offers a poor composition model. JavaScript classes can be functionally defined (e.g., mixins), and are therefore extremely composable.

Check out the Liaison documentation, start building something, and let me know what you think.