In the beginning, there were only full-stack developers. We implemented everything in the backend with some or and then, with a bit of running in the frontend, we were done. PHP Ruby On Rails jQuery 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 model with a frontend that entirely manages the user interface. "single-page application" 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 ( , , etc.) that significantly increases the size of our code and results in duplicating our domain model. REST GraphQL 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 , , or . But when the business logic goes beyond CRUD operations, it's not great. Parse Firebase Amplify Something called 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. Meteor Recently, two projects made the buzz — and . Both also aim to simplify the communication between the frontend and the backend, but with a different approach. RedwoodJS Blitz.js RedwoodJS simplifies the implementation of a GraphQL API and brings together and in an opinionated framework. React Prisma Blitz.js is also a framework using React and Prisma, but it is built upon and it strives to eliminate the need for a web API. Next.js 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 that I have been working on for a year and a half. Liaison 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 would look like with Liaison. "Hello, World!" To start, here is the backend: {Component, attribute, method, expose} ; {ComponentHTTPServer} ; {
  @expose({ : }) @attribute() name = ;

  @expose({ : }) @method() hello() { ;
  }
} server = ComponentHTTPServer(Greeter, { : });

server.start(); import from '@liaison/component' import from '@liaison/component-http-server' class Greeter extends Component set true 'World' call true async return `Hello, !` ${ .name} this const new port 3210 And here is the frontend: {ComponentHTTPClient} ; client = ComponentHTTPClient( ); Greeter = client.getComponent(); greeter = Greeter({ : }); .log( greeter.hello()); import from '@liaison/component-http-client' const new 'http://localhost:3210' const await const new name 'Steve' console await 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 method is called, and the fact that it is executed on the backend side can be seen as an implementation detail. hello() The class in the frontend behaves like a regular JavaScript class, and it can be extended. For example, we could override the method like this: Greeter hello() { hello() { ( .hello()).toUpperCase();
  }
} class ExtendedGreeter extends Greeter async return await super Now, when the 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. hello() 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 , and this is the approach followed by Liaison. ORM In a nutshell, the mixin brings persistency to your data. For example, take the following class: Storable() {Component} ; {Storable, primaryIdentifier, attribute} ; {
  @primaryIdentifier() id;
  @attribute() title;
} import from '@liaison/component' import from '@liaison/storable' ( ) class Movie extends Storable Component To create and save a , you can do this: Movie movie = Movie({ : ); movie.save(); const new title 'Inception' await And to retrieve an existing , you can do this: Movie movie = Movie.get({ : }); const await 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., ), it is possible to combine the user interface and the domain model. React with hooks Liaison allows you to implement your routes and views as methods of your models. Here's an example of how to define routes: {Component} ; {Routable, route} ; {
  @route( ) List() { }

  @route( ) Item({id}) { }
} import from '@liaison/component' import from '@liaison/routable' ( ) class Movie extends Routable Component '/movies' static // Display all the movies... '/movies/:id' static // 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: {Component, attribute} ; React ; {view} ; {
  @attribute() title;
  @attribute() year;
  @attribute() country;

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

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

  @view() Details() {
    return <div>Country: {this.country}</div>;
  }
} import from '@liaison/component' import from 'react' import from '@liaison/react-integration' class Movie extends Component return < > 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 or . The decorator makes sure that the view is re-rendered automatically when the value of an attribute changes. Redux MobX @view() 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., ), and are therefore extremely composable. mixins Check out the , start building something, and what you think. Liaison documentation let me know

Super

Follow me on Twitter

Read My Stories

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Full Stack for All

Too Long; Didn't Read

Company Mentioned

Manuel Vila

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Full Stack for All

Too Long; Didn't Read

Company Mentioned

Manuel Vila

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES