Forem: Manuel Vila

Layr v2 Is Out, but You May Never Use It

Manuel Vila — Fri, 13 Jan 2023 00:04:13 +0000

Finally, after two years of hard work, Layr v2 is out.

Actually, Layr v2 was published on NPM a year ago, but I haven't announced it because I needed to achieve three important things:

Documented the new features.
Created a CLI for Layr, which turned out to be a companion tool called Boostr.
Rewrote the "Hello, World" tutorial and updated all the app examples.

That's all done, and I can now officially announce the release of Layr v2. However, as I will explain later, you may never use it.

Please check out my previous article if you've never heard of Layr.

What's New?

Here are the most notable new features in Layr v2.

Components

Attribute sanitization: When you assign a new value to an attribute, this value can be automatically sanitized with some built-in (e.g., trim()) or custom sanitization functions.
Attribute value assignment: You can now change the value of multiple attributes at once thanks to the component assign() class and instance methods.
Method scheduling: Class methods have a new schedule option to specify that a class method should be repeatedly called with a fixed time delay between each call.
Method queuing: Class and instance methods have a new queue option to specify that a method should be executed in the background.

Routing

Wrappers: A wrapper can be associated with a component class or instance method to wrap any method associated with a route using this wrapper. Thanks to wrappers, you can, for example, easily nest your pages into layouts.
Component instance routes: Before, routes could only be associated with component class methods. Now, you can associate routes with component instance methods as well.
Catch-all routes: You can now suffix a route URL pattern with a wildcard ('*') to define a route that will be used when no other routes match the current URL. A typical use case is to define a route for displaying a "Not found" page.

React Integration

page(): A decorator that combines the route() and @view() decorators.
layout(): A decorator that combines the wrapper() and @view() decorators.
useData(): A hook for loading data asynchronously and rendering a React element using these data.
useAction(): A hook for executing some asynchronous actions.

Command-Line Interface

Layr got a companion tool called Boostr for taking care of everything you need to build and deploy your apps.

You can check out the revised "Hello, World" tutorial to see Boostr in action.

Breaking Changes

Layr v2 includes some breaking changes that I will not describe here because, to my knowledge, nobody (except me) has built apps with Layr v1 for production use. Please let me know if it's not the case.

What's Next?

Some work remains to be done in the documentation:

Some additional tutorials to cover all the basic features of Layr.
A "Concepts" section to introduce the fundamental concepts behind Layr.
A "Guides" section to explain how the most common features of an app could be implemented with Layr.

Unfortunately, writing documentation takes a lot of time, and the Layr project is currently only handled by me, who has to work for customers to make a living and is also starting a new ambitious project called 1Place, which will be based on Layr.

I need to raise money for 1Place, and if everything goes well, I should be able to hire talents to work on 1Place, and, indirectly, fuel the development of Layr.

Also, to build 1Place, some critical features should be added to Layr, such as component subscription and polymorphic storage, which will probably lead to additional breaking changes and a v3 release.

In the current situation, the future of Layr depends on 1Place. If 1Place fails, I'm certainly not going to give up on Layr, which I really care about, but its development will likely be slowed down.

So, for all these reasons, unless you feel very adventurous, I can't recommend building your next app with Layr v2 today.

You may wonder why I am announcing a new version while telling you not to use it. Well, I just felt I had to keep the few people who follow Layr's development informed.

Some Thoughts on React Server Components

Manuel Vila — Wed, 23 Dec 2020 01:38:18 +0000

The React team unveiled yesterday a new experiment called React Server Components, and I must say I'm pretty excited about it.

Thank you, Dan Abramov, for saying that GraphQL is not for everyone. Thanks to the React team for looking for solutions to build web apps without web APIs and daring to challenge the status quo.

A few weeks ago, I wrote an article to defend the idea that it is possible to create single-page apps without building a web API to connect the frontend and the backend. I believe this article was as much loved as it was hated.

On the one hand, there are all the developers who are tired of developing web APIs and welcome all the solutions to get rid of them.

On the other hand, there are many developers who think that web APIs are necessary and that it's a shame to want to do without them.

Of course, no one is absolutely right or wrong. It depends on what you build.

I think a lot of web apps can live very well without a web API. But there is also a significant number of apps for which a web API can be very beneficial.

So, congrats to the React team for considering both cases and looking for a solution for those who are in the "API-less" camp.

React Server Components allow to abstract away the runtime environment where the views are rendered. Any view can be rendered in the frontend, the backend, or both, and from the developer's perspective, it doesn't matter. The developer can write an application as if the frontend and the backend were a single entity.

This approach appeals to me because it is in line with one of my biggest obsessions. Indeed, with Layr I'm trying to achieve the same thing — to bring the frontend and the backend together.

What makes Layr and React Server Components different is the nature of what is transported between the frontend and the backend. Layr transports models while React Server Components transport views.

I think that transporting the models eventually offers more possibilities because the views remain entirely in charge of the frontend and it is, therefore, easier to create multiple frontends for different platforms (web, mobile, desktop, etc.).

However, it is possible to imagine that React Server Components could also be used to build React Native apps. We would then have a backend capable of generating views for React Native. At first glance, the idea may seem crazy, but why not?

Anyway, all this reinforces my belief that the "API-less" approach is more and more a thing.

Thank you, React, for continuing to innovate. Removing the API layer is not a small deal. It is a huge architectural shift.

Good Bye Web APIs

Manuel Vila — Mon, 23 Nov 2020 20:26:17 +0000

When building a single-page application or a mobile application, we usually need to implement a web API (REST, GraphQL, etc.) to connect the frontend and the backend. Technically, it's not very difficult, but it has some unfortunate consequences.

Imagine two planets. The planet "frontend" speaks JavaScript and the planet "backend" also speaks JavaScript or any other advanced language.

Now let's say that these planets need to collaborate extensively to form a whole called "application".

Unfortunately, the planets are unable to communicate with each other directly using their native language and they have to rely on a third party called "web API" which speaks a much less sophisticated language.

Indeed, the language of most web APIs is limited to a combination of URLs, a few HTTP verbs (GET, POST, DELETE, etc.), and some JSON.

The web APIs that speak GraphQL are more advanced but they remain far behind the possibilities of a programming language such as JavaScript:

The programming paradigm is procedural or functional (no object-oriented programming).
Only the most basic types are supported (forget about Date, Map, Set, etc.).
The concept of reference is missing (you can only pass objects by value).

Placing a rudimentary language between the frontend and the backend adds a lot of boilerplate and ruins the development experience.

Another problem is that a web API is an extra layer to worry about. It must be designed, implemented, tested, documented, etc. And all this is frankly a pain in the ass.

But the worst thing is that building a web API generally forces you to degrade the quality of your codebase. Indeed, it's quite challenging to keep your code DRY and cohesive when your frontend and your backend are separated by a web API.

Now imagine that we could get rid of the web API. Imagine that the frontend could communicate directly with the backend using its native language. Wouldn't it be great?

The good news is that it's possible today thanks to a set of libraries called Layr.

Hello, Layr!

With Layr, the frontend and the backend are physically separated (they run in different environments) but logically reunited (it's as if they were in the same environment).

How does it work?

The backend is composed of one or more classes whose some of their attributes and methods are explicitly exposed to the frontend.
The frontend generates some proxies to the backend classes and can use these proxies as if they were regular JavaScript classes.

Under the hood, Layr relies on an RPC mechanism. So, superficially, it can be seen as something like CORBA, Java RMI, or .NET CWF.

But Layr is radically different:

It's not a distributed object system. A Layr backend is stateless, so there are no shared objects across the stack.
It doesn't involve any boilerplate code, generated code, configuration files, or artifacts.
It uses a simple but powerful serialization protocol (Deepr) that enables unique features such as chained invocation, automatic batching, or partial execution.

Layr starts its journey in JavaScript/TypeScript, but the problem it tackles is universal, and it could be ported to any object-oriented language.

Example

Let's implement the classic "Counter" example to see what it looks like to build a full-stack application with Layer.

First, we implement the "data model" and the "business logic" in the backend:



// backend.js

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

class Counter extends Component {
  // We need a primary identifier so a Counter instance
  // can be transported between the frontend and the backend
  // while keeping it's identity
  @expose({get: true, set: true}) @primaryIdentifier() id;

  // The counter value is exposed to the frontend
  @expose({get: true, set: true}) @attribute() value = 0;

  // And the "business logic" is exposed as well
  @expose({call: true}) @method() increment() {
    this.value++;
  }
}

// Lastly, we serve the Counter class through an HTTP server
const server = new ComponentHTTPServer(Counter, {port: 3210});
server.start();

Oh my! All that code just for a simple "Counter" example? Sure, it seems overkill, but we've actually implemented a full-grade backend with a data model, some business logic, and an HTTP server exposing the whole thing.

Now that we have a backend, we can consume it from a frontend:



// frontend.js

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

(async () => {
  // We create a client to connect to the backend server
  const client = new ComponentHTTPClient('http://localhost:3210');

  // We get a proxy to the Counter backend class
  const Counter = await client.getComponent();

  // Lastly, we consume the Counter
  const counter = new Counter();
  console.log(counter.value); // => 0
  await counter.increment();
  console.log(counter.value); // => 1
  await counter.increment();
  console.log(counter.value); // => 2
})();

What's going on here? By invoking the counter.increment() method the counter value is incremented. Note that this method does not exist in the frontend. It is implemented in the backend and is therefore executed in this environment. But from the perspective of the frontend, the actual execution environment doesn't matter. The fact that the method is executed remotely can be seen as an implementation detail.

The Counter class in the frontend can be extended to implement features that are specific to the frontend. Here's an example of how to override the increment() method to display a message when the counter reaches a certain value:



class ExtendedCounter extends Counter {
  async increment() {
    // We call the `increment()` method in the backend
    await super.increment();

    // We execute some additional code in the frontend
    if (this.value === 3)
      console.log('The counter value is 3');
    }
  }
}

This is what it looks like when the frontend and the backend are reunited. Pretty cool isn't it?

What's the Catch?

Why does everyone build web APIs when we could do without them?

There is one good reason to implement a web API, it's when you want to expose your backend to some external developers through an established protocol such as REST. But let's be honest, the vast majority of applications don't have this requirement. And if it turns out that you need a web API, it is possible to add it afterward while continuing to use the "API-less" approach for all your internal needs.

Another reason is if you work on a large-scale application with millions of users. Indeed, the convenience provided by Layr doesn't come without a cost, so if you want the most optimized application possible, you'd better go with a lower-level solution.

Finally, if you want to implement a frontend or a backend in a language other than JavaScript, you can still use Layr on one side of the stack, but you will then have to implement an API client or server that can speak the Deepr protocol on the other side of the stack.

Conclusion

Removing the web API allows you to build a full-stack application much faster while increasing the quality of your codebase.

By using Layr on several projects, including some production projects, I was able to reduce the amount of code by 50% on average and greatly increase my productivity.

Another important aspect is the development experience. Since the frontend and the backend are no longer separated by a web API, you get a feeling similar to developing a standalone application, and it's a lot more fun.

Full-Stack Development Should Be Easier

Manuel Vila — Mon, 19 Oct 2020 21:33:36 +0000

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 that 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.

This article was originally published on Hacker Noon.

Liaison 1.0: Reuniting the Frontend and the Backend

Manuel Vila — Fri, 18 Sep 2020 13:00:37 +0000

Let's talk about web app development.

It used to be simple. We implemented everything in the backend with some PHP code or Ruby on Rails and then, with a bit of JavaScript 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, from a bit of JavaScript running in the frontend, we switched to a lot of JavaScript using a single-page application model and a bunch of libraries.

There's nothing wrong with this. It's actually quite an elegant architecture:

The frontend is in charge of the user interface.
The backend takes care of the data model and the business logic.

The problem, however, lies in the middle. Now that we have two rich execution environments, we need to make sure that they communicate effectively. So, we implement a web API (REST, GraphQL, etc.), and everything gets complicated.

Conceptually, it's like we're building two applications instead of one.

The data model gets duplicated, and the overall complexity is such that the developers become duplicated as well.

If you're a frontend or backend developer, you can only do half the job, and you waste a lot of time communicating with the person in charge of the other half.

If you're a full-stack developer, you can implement a feature from start to finish in a much more efficient and satisfying way. But, given the sophistication of the stack, there's a lot you have to deal with, and it doesn't scale very well.

Ideally, we should all be full-stack developers just like we were in the beginning. But we need to dramatically simplify the stack to make this possible.

So, how to simplify the stack?

Sure, the frontend and the backend need to be physically separated. But it doesn't mean that they have to be logically separated.

With the right abstractions in place, an application can run in two different execution environments, even as it remains a single thing from the developer's point of view.

This is precisely what Liaison offers — a reuniting of the frontend and the backend.

The data model can be shared across the stack, and there is no need to build a web API anymore.

Some might argue that mastering both the frontend and the backend is not that easy.

The frontend is not only UI rendering, but it's also state management, routing, etc.

The backend is not only data modeling and business logic, but it's also data storage, authorization, etc.

Fair enough, it's not that easy. But here, Liaison also has a lot to offer.

So, hopefully, everyone can be a full-stack developer again.

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

Happy coding! 🧑‍💻

Simplify Full-Stack Development with a Unified Architecture

Manuel Vila — Wed, 11 Dec 2019 23:08:33 +0000

This article was originally published on freeCodeCamp.

A modern full-stack application (e.g., a single-page application or a mobile application) is typically composed of six layers: data access, backend model, API server, API client, frontend model, and user interface.

By architecting in this way, you can achieve some characteristics of a well-designed application, such as separation of concerns or loose coupling.

But it does not come without drawbacks. It usually comes at the expense of some other important characteristics such as simplicity, cohesion, or agility.

It seems we can't have it all. We have to compromise.

The problem is that each layer is usually built as a completely different world on its own.

Even if the layers are implemented with the same language, they cannot communicate easily and share much with each other.

We need a lot of glue code to connect them all, and the domain model gets duplicated across the stack. As a result, the development agility suffers dramatically.

For example, adding a simple field to a model often requires modifying all the layers of the stack. Don't you think this is a bit ridiculous?

I've been thinking a lot about this problem recently, and I believe I've found a way out.

Here's the trick: for sure, the layers of an application must be "physically" separated, but they don't need to be "logically" separated.

The Unified Architecture

In object-oriented programming, when we use inheritance, we get some classes that can be seen in two ways: physical and logical. What do I mean by that?

Let's imagine we have a class B that inherits from a class A. Then, A and B can be seen as two physical classes. But logically, they are not separated, and B can be seen as a logical class that composes the properties of A with its own properties.

For example, when we call a method in a class, we don't have to worry if the method is implemented in this class or a parent class. From the caller perspective, there is only one class to worry about. Parent and child are unified into a single logical class.

How about applying the same approach to the layers of an application? Wouldn't it be great if, for example, the frontend could somehow inherit from the backend?

Doing so, frontend and backend would be unified into a single logical layer, and that would remove all communication and sharing issues. Indeed, backend classes, attributes, and methods would be directly accessible from the frontend.

Of course, we don't usually want to expose the whole backend to the frontend. But the same goes for class inheritance, and there is an elegant solution that is called "private properties". Similarly, the backend could selectively expose some attributes and methods.

Being able to grasp all the layers of an application from one single unified world is not a small deal. It changes the game completely. It is like going from a 3D world to a 2D world. Everything gets a lot easier.

Inheritance is not evil. Yes, it can be misused, and in some languages, it can be pretty rigid. But when properly used, it is an invaluable mechanism in our toolbox.

We have a problem, though. As far as I know, there is no language allowing us to inherit classes across multiple execution environments. But we are programmers, aren't we? We can build everything we want, and we can extend the language to provide new capabilities.

But before we get to that, let's break down the stack to see how each layer can fit in a unified architecture.

Data Access

For a majority of applications, the database can be abstracted using some sort of ORM. So, from the developer perspective, there is no data access layer to worry about.

For more ambitious applications, we might have to optimize database schemas and requests. But we don't want to clutter the backend model with these concerns, and this is where an additional layer may be appropriate.

We build a data access layer to implement the optimization concerns, and this usually happens late in the development cycle, if it ever happens.

Anyway, if we need such a layer, we can build it later. With cross-layer inheritance, we can add a data access layer on top of the backend model layer with almost no changes to the existing code.

Backend Model

Typically, a backend model layer handles the following responsibilities:

Shaping the domain model.
Implementing business logic.
Handling the authorization mechanisms.

For most backends, it is fine to implement them all in a single layer. But, if we want to handle some concerns separately, for example, we want to separate the authorization from the business logic, we can implement them in two layers that inherit from each other.

API Layers

To connect the frontend and the backend, we usually build a web API (REST, GraphQL, etc.), and that complicates everything.

The web API must be implemented on both sides: an API client in the frontend and an API server in the backend. That's two extra layers to worry about, and it usually leads to duplicate the whole domain model.

A web API is nothing more than glue code, and it is a pain in the ass to build. So, if we can avoid it, that's a massive improvement.

Fortunately, we can take advantage of cross-layer inheritance again. In a unified architecture, there is no web API to build. All we have to do is to inherit the frontend model from the backend model, and we are done.

However, there are still some good use cases for building a web API. That's when we need to expose a backend to some third-party developers, or when we need to integrate with some legacy systems.

But let's be honest, most applications don't have such a requirement. And when they do, it is easy to handle it afterward. We can simply implement the web API into a new layer that inherits from the backend model layer.

Further information on this topic can be found in this article.

Frontend Model

Since the backend is the source of truth, it should implement all the business logic, and the frontend should not implement any. So, the frontend model is simply inherited from the backend model, with almost no additions.

User Interface

We usually implement the frontend model and the UI in two separate layers. But as I showed in this article, it is not mandatory.

When the frontend model is made of classes, it is possible to encapsulate the views as simple methods. Don't worry if you don't see what I mean right now, it will become clearer in the example later on.

Since the frontend model is basically empty (see above), it is fine to implement the UI directly into it, so there is no user interface layer per se.

Implementing the UI in a separate layer is still needed when we want to support multiple platforms (e.g., a web app and a mobile app). But, since it is just a matter of inheriting a layer, that can come later in the development roadmap.

Putting Everything Together

The unified architecture allowed us to unify six physical layers into one single logical layer:

In a minimal implementation, data access is encapsulated into the backend model, and the same goes for UI that is encapsulated into the frontend model.
The frontend model inherits from the backend model.
The API layers are not required anymore.

The result can be illustrated as follows:

That's pretty spectacular, don't you think?

Liaison

To implement a unified architecture, all we need is cross-layer inheritance, and I started building Liaison to achieve exactly that.

You can see Liaison as a framework if you wish, but I prefer to describe it as a language extension because all its features lie at the lowest possible level — the programming language level.

So, Liaison does not lock you into a predefined framework, and a whole universe can be created on top of it. You can read more on this topic in this article.

Behind the scene, Liaison relies on an RPC mechanism. So, superficially, it can be seen as something like CORBA, Java RMI, or .NET CWF.

But Liaison is radically different:

It is not a distributed object system. Indeed, a Liaison backend is stateless, so there are no shared objects across layers.
It is implemented at the language-level (see above).
Its design is straightforward and it exposes a minimal API.
It doesn't involve any boilerplate code, generated code, configuration files, or artifacts.
It uses a simple but powerful serialization protocol (Deepr) that enables unique features, such as chained invocation, automatic batching, or partial execution.

Liaison starts its journey in JavaScript, but the problem it tackles is universal, and it could be ported to any object-oriented language without too much trouble.

Hello Counter

Let's illustrate how Liaison works by implementing the classic "Counter" example as a single-page application.

First, let's build the backend:

// backend.js

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

class Counter extends Component {
  // We need a primary identifier so a Counter instance
  // can be transported between the frontend and the backend
  // while keeping it's identity
  @expose({get: true, set: true}) @primaryIdentifier() id;

  // The counter's value is exposed to the frontend
  @expose({get: true, set: true}) @attribute('number') value = 0;

  // And the "business logic" is exposed as well
  @expose({call: true}) @method() increment() {
    this.value++;
  }
}

// We serve the Counter through a ComponentServer
export const server = new ComponentServer(Counter);

Then, let's build the frontend:

// frontend.js

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

import {server} from './backend';

// We create a client that is connected to the backend's server
const client = new ComponentClient(server);

// We get the backend's Counter class
const BackendCounter = client.getComponent();

// We extends the backend's Counter class so we can override
// the increment() method later
class Counter extends BackendCounter {}

// Lastly, we consume the Counter
const counter = new Counter();
counter.increment();
console.log(counter.value); // => 1

What's going on? By invoking counter.increment(), we got the counter's value incremented. Notice that the increment() method is not implemented in the frontend class. It only exists in the backend.

So, how is it possible that we could call it from the frontend? This is because the frontend class (Counter) is inherited from the backend class (BackendCounter). So, when a method is missing in the frontend class, and a method with the same name is exposed in the backend class, it is automatically invoked, even though the backend is remote.

Note that in this simple example, the backend is not exactly remote. Both the frontend and the backend run in the same JavaScript runtime. To make the backend truly remote, we can easily expose it through HTTP. See an example here.

From the frontend point of view, the operation is transparent. It doesn't need to know that a method is invoked remotely. It just works.

The current state of an instance (i.e., counter's attributes) is automatically transported back and forth. When a method is executed in the frontend, the attributes that have been modified are sent to the backend. And inversely, when some attributes change in the backend, they are reflected in the frontend.

How about passing/returning values to/from a remotely invoked method? It is possible to pass/return anything that is serializable, including class instances. As long as a class is registered with the same name in both the frontend and the backend, its instances can be automatically transported.

How about overriding a method across the frontend and the backend? It is no different than with regular JavaScript — we can use super. For example, we can override the increment() method to run additional code in the context of the frontend:

// frontend.js

class Counter extends BackendCounter {
  increment() {
    super.increment(); // The backend's `increment()` method is invoked
    console.log(this.value); // Some additional code is executed in the frontend
  }
}

Now, let's build a user interface with React and the encapsulated approach shown earlier:

// frontend.js

import React from 'react';
import {view} from '@liaison/react-integration';

class Counter extends BackendCounter {
  // We use the `@view()` decorator to observe the counter's attributes
  // and automatically re-render the view when needed
  @view() Display() {
    return (
      <div>
        {this.value} <button onClick={() => this.increment()}>+</button>
      </div>
    );
  }
}

Then, to display the counter, all we need is:

<counter.Display />

Voilà! We built a single-page application with two unified layers and an encapsulated UI.

Proof of Concept

To experiment with the unified architecture, I built a RealWorld example app with Liaison.

I might be biased, but the outcome looks pretty amazing to me: simple implementation, high code cohesion, 100% DRY, and no glue code.

In terms of the amount of code, my implementation is significantly lighter than any other one I have examined. Check out the results here.

Certainly, the RealWorld example is a small application, but since it covers the most important concepts that are common to all applications, I'm confident that a unified architecture can scale up to more ambitious applications.

Conclusion

Separation of concerns, loose coupling, simplicity, cohesion, and agility.

It seems we get it all, finally.

If you are an experienced developer, I guess you feel a bit skeptical at this point, and this is totally fine. It is hard to leave behind years of established practices.

If object-oriented programming is not your cup of tea, you will not want to use Liaison, and this is totally fine as well.

But if you are into OOP, please keep a little window open in your mind, and the next time you have to build a full-stack application, try to see how it would fit in a unified architecture.

Liaison is still at an early stage, but I am actively working on it, and I expect to release the first beta version in early 2020.

If you are interested, please star the repository and stay updated by following the blog or subscribing to the newsletter.

Do We Really Need to Separate the Model from the UI?

Manuel Vila — Sat, 23 Nov 2019 00:25:29 +0000

Typically, domain models and UI views are completely separated. A few years ago, we had a good reason to do so because the views were mostly made of imperative code. But now that we have functional UI libraries (e.g., React with hooks), wouldn't it be possible to gather everything together, and implement the views as methods of the models they represent?

Object-Oriented Approach

For example, let's say we have a User class defined as follows:

class User {
  constructor({firstName, lastName}) {
    this.firstName = firstName;
    this.lastName = lastName;
  }

  getFullName() {
    return `${this.firstName} ${this.lastName}`;
  }
}

Now, let's add a React component into this class:

class User {
  // ...

  View = () => {
    return <div>{this.getFullName()}</div>;
  };
}

And create an instance:

const user = new User({firstName: 'Arthur', lastName: 'Rimbaud'});

Then, to render a View for this user, we can do:

<user.View />

This is a perfectly valid JavaScript/JSX code, and I don't think there is something wrong with it. Conceptually, the View() method is no different than the getFullName() method. They are just methods returning a different kind of view: getFullName() returns a string and View() returns a React element.

Functional Approach

In a typical React app, we would not do so though. We would separate the view from the model like the following:

function UserView({user}) {
  return <div>{user.getFullName()}</div>;
}

Then, to render UserView, we would do:

<UserView user={user} />

Does this more verbose approach bring benefits? No matter how much I scratch my head, I don't see any. The code is just more scattered.

Decoupling

It is always good to decouple the pieces of an application as much as possible.

But does the functional approach (React components implemented separately as functions) brings more decoupling than the object-oriented approach (React components implemented as methods of a model)?

It doesn't. Getting the models from a parameter or accessing them through this makes no difference. In both cases, models and views become tightly coupled.

Separation of Concerns

Some might argue that it is good to separate the model from the view because they are two different concerns. I don't get it. Again, how, in the object-oriented approach, the getFullName() method is different than the View() method? Both are returning a representation of the model, so why should we separate them?

It remembers me of the discussion about separating HTML and CSS. Yes, they serve two different purposes. HTML describes the content and CSS describes the presentation. But I don't think there is something wrong about putting them together in a cohesive way.

Sharing One Model with Multiple UIs

Let's imagine we are building an app for several platforms: a web app (with ReactDOM) and an iOS app (with React Native).

In this case, we usually want to share the same model with all platforms, and implement different UIs for each platform. To achieve this, we can implement the model separately and subclass it to implement the different views.

Refactoring our previous example, we define the User model in a separate file:

// shared/user.js

export class User {
  constructor({firstName, lastName}) {
    this.firstName = firstName;
    this.lastName = lastName;
  }

  getFullName() {
    return `${this.firstName} ${this.lastName}`;
  }
}

Then, we subclass it to implement the views of the web app:

// web/user.js

import {User as BaseUser} from '../shared/user.js';

class User extends BaseUser {
  View = () => {
    return <div>{this.getFullName()}</div>;
  };
}

And the same goes for the iOS app:

// ios/user.js

import {User as BaseUser} from '../shared/user.js';

class User extends BaseUser {
  View = () => {
    return <Text>{this.getFullName()}</Text>;
  };
}

Physically, the code is then a bit more scattered, but logically, it is not. Whichever the platform, from a User instance, we have access to both the model (user.firstName) and its views (<user.View />).

Composition over Inheritance

« Inheritance is evil. »

« Composition is the way to go. »

I am tired of hearing that all the time about anything and everything.

Yes, single inheritance in static languages (Java, C#, etc.) may not be the right approach for composing the multiple pieces of an application. But it is not true with JavaScript where inheritance is dynamic, and therefore, extremely flexible.

For example, we can use mixins to enable any kind of inheritance: multiple, conditional, parameterized, etc.

There are many ways to implement mixins in JavaScript, but there is only one good way, and it is incredibly simple. Please head over here for a nice explanation.

Conclusion

I tried the object-oriented approach when implementing the RealWorld example with Liaison, and I think it worked pretty well. Encapsulating the views into the models made the code a lot more cohesive than if the views were implemented separately.

If you are skeptical (you should be), please have a look at the code and tell me what you think.

Since most of the models are implemented in the backend, the frontend models are pretty much just composed of views.

Some might think that the classes are a bit crowded. I guess it is a matter of taste. Personally, as long as the content is related, I don't mind large files. If you prefer small files, you can group some views into mixins and assemble them into a single model.

This article was originally published on the Liaison Blog.

Do We Really Need A Web API?

Manuel Vila — Sun, 17 Nov 2019 09:32:26 +0000

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.

First, the web API must be implemented on both sides: an API client in the frontend and an API server in the backend. Second, to transport the domain model between the frontend and the backend, we must constantly serialize and deserialize it. All this leads to a lot of code scattering, duplication of knowledge, boilerplate, and accidental complexity. We get lost in translation.

Most of the time, web APIs are not functional requirements. They don't add any value to the product we are building. They are just a necessary evil so the frontend can communicate with the backend. But is that really the case? Wouldn't it be possible to get rid of these web APIs?

Liaison

I started building Liaison to achieve exactly that: getting rid of these "pain-in-the-ass" web APIs.

With Liaison, frontend and backend can communicate directly with the language they are implemented in. The frontend can call a method in the backend without further ceremony. It is just a regular JavaScript method invocation.

The way it works is simple: a frontend class can "inherit" from a backend class. So, when a method is called, if this method is missing in the frontend, the corresponding method is executed in the backend, automatically.

For example, let's say the frontend is executing the following code:

await user.follow(anotherUser);

Depending on the implementation of follow(), the execution can happen:

In the frontend, if the method exists only in the frontend.
In the backend, if the method exists only in the backend.
Or both in the frontend and the backend, if the method exists in the backend but is overridden in the frontend.

When a method is executed in the backend, the attributes of the involved instances (user and anotherUser) are transported to the backend, the method is executed, and if some attributes have changed during the execution, those changes are automatically reflected in the frontend.

Conceptually, it works like class inheritance. The only difference is that the inheritance occurs across two execution environments: the frontend and the backend. And when we call a method, it doesn't matter where the execution actually happens. For the developer, frontend and backend become one unified world.

So there is no need to build a web API anymore. We can still implement such an API if it is actually required (for example, we intend to open our application to third-party developers through a REST API), but for our own needs, we greatly benefit from doing without it.

Without the burden of building a web API, we can dramatically reduce code scattering, duplication of knowledge, and boilerplate. We can build faster, and better.

RealWorld Example

Is this approach working? I think it does. I built a RealWorld example with Liaison, both the frontend and the backend, and the outcome looks quite amazing to me: straightforward implementation, high code cohesion, 100% DRY, and zero boilerplate.

In terms of the amount of code, in case it matters, my implementation is significantly lighter than any other one I have examined:

Project	Frontend	Backend	Shared
react-liaison	1374	356	66
react-mobx	1937
react-redux	2050
vue	2118
angular	2122
node-express		596
nestjs-typeorm		967
koa-knex		1535
hapijs		1872

The numbers represent the amount of lines of code excluding comments and test suites. Count done on October 7th, 2019 using Tokei.

Liaison is still at an early stage, and a lot of work remains so it can be used in production. I truly believe it is something worth trying, and I am actively working on it. I expect to release the first beta version in early 2020.