www.nanofrontend.com

www.nanofrontends.com

www.nanofrontend.com

Two strategies from frontside perspecitve

Decompozition

Decoupling

Headless:

In the context of web development, a headless architecture refers to separating the frontend (presentation layer) from the backend (content management and business logic).

Characteristics:

Example:

Using a headless CMS like Contentful or Strapi with a React frontend.

MicroFrontend

Microfrontends apply the concept of microservices to the browser side. They break down a monolithic frontend application into smaller, independent front-end applications.

Characteristics:

Implementation Approaches:

Example:

Building a complex application by combining multiple smaller front-end applications.

NanoFrontend:

A more granular approach than microfrontends, where individual components are treated as nanofrontends.

Characteristics:

Example:

Breaking down a large application into tiny, reusable components (e.g., buttons, forms).

FrontendLess

The term “frontendless” refers to an architectural approach where the traditional frontend layer of a web application is either minimized or eliminated altogether:

Frontendless architectures aim to streamline UI development by distributing responsibilities across various layers, services, or components. Whether it’s SSR, microfrontends, or web components, the goal is to achieve flexibility, maintainability, and scalability while minimizing the traditional frontend footprint. 🚀

Server-Side Rendering (SSR):

API-First or Headless Architectures:

Client-Side Rendering (CSR) with Microfrontends:

Web Components:

Benefits:

Challenges:

Modular/Atomized Streamed Interface

Modular Interfacing

Types of Modular Interface Design

Optimizing Digital Streaming

In summary, modular interfacing involves creating flexible connections between components, whether in music synthesis, general electronics, or digital streaming. Whether you’re patching CV signals, connecting sensors, or optimizing audio streaming, the key is adaptability and efficient communication. 🎛️🔌🎶

Frontendless vs Headless architectures:

Frontendless:

A Frontendless architecture minimizes or eliminates the traditional frontend layer of a web application.

Headless:

A Headless architecture decouples the frontend (presentation layer) from the backend (content management and business logic).

Comparison:

Frontendless focuses on minimizing the traditional frontend layer, while Headless emphasizes decoupling frontend and backend.

Microfrontends vs NanoFrontends

Microfrontends

Microfrontends to architektura projektowania stron internetowych i aplikacji webowych, która polega na podziale frontendu na mniejsze, niezależnie rozwijane i wdrażane fragmenty. Każdy microfrontend może być odpowiedzialny za określoną funkcjonalność lub sekcję aplikacji i jest opracowywany przez odrębny zespół. Ta koncepcja jest rozszerzeniem idei mikrousług na warstwę frontową, umożliwiając większą skalowalność, prostotę zarządzania i możliwość wykorzystania różnych technologii oraz frameworków przez poszczególne zespoły.

Nanofrontends

Nanofrontends służy dalszego podziału koncepcji microfrontends na jeszcze mniejsze, bardziej zatomizowane jednostki. Nanofrontends skupia się na bardzo szczegółowych, wyspecjalizowanych/atomowych aspektach aplikacji, potencjalnie umożliwiając jeszcze większą niezależność w rozwoju. Na przykład, oddzielne jednostki zarządzające bardzo małymi, ponownie wykorzystywalnymi komponentami interfejsu użytkownika, takimi jak przyciski, ikony, pola tekstowe itp.

Rodzi to wyzwania organizacyjne i techniczne, zwiększając złożoność zarządzania zależnościami, komunikacją między komponentami i spójnością doświadczenia użytkownika. Korzyści z jeszcze bardziej zatomizowanej architektury niż microfrontends są dopiero dostzregalne w kontekście reużywalnośći, reusabuility w architektyurzy hipermodularnej.

microfrontend

Abstract

Micro-frontends are a strategy for splitting user interfaces up into separately deployable units. This gives teams great latitude to choose their own technologies and think in terms of self-contained programs.

Nano-frontends are an alternative that give teams similar freedoms but provide opt-in optimisations to improve user experience.

Write your frontends as libraries that take:

What does a ‘dependency injected’ frontend look like?

First we need to specify a set of dependencies

The scaffold app

This is a simple Node/Express/React app that routes from URLs to components that each instantiate nano-frontends. Nano-frontends are loaded via dynamic import. For instance, on the homepage:

The scaffolding app then ‘makes the decision’ as to where nano-frontends go in terms of both URL and page location. This makes it easy for teams to discuss changes or contention, and also see the state of the frontend.

Publishing workflow

If we want teams to be independent, they need to be able to release just by updating their own repositories.

Now we commit the code and run a build with e.g. CircleCI. There’s a testbed that can run a full browser test of our component just by injecting the necessary dependencies - including mocked dependencies. This means we can do a11y and full ‘clickability’ testing without having to prepare API state.

Once completed, the build process compiles the code into a bundle. Note that the dependency file only exports types, so React / ReactDOM / jss aren’t included in the final bundle.

Push this to S3 and we can trigger an SNS notification (e.g. s3:ObjectCreated:Put). This will update the ‘scaffold app’ that actually renders the nano-frontend.

Current Technologies at 2021

The Stack

How your stack looks will depend on how you want to render your application. Here is a comprehensive discussion about that, but in a nutshell:

Client-side rendering(CSR); SPA; JSON APIs

This is perhaps the most popular approach. It’s great for building interactive web applications. But be aware of its downsides and steps to mitigate them. This is the approach I took, so we will talk about it in a lot of detail.

Hybrid CSR; Both client-side and server-side rendering(SSR)

With this approach, you still build your SPA. But when a user requests your app, for example, the homepage, you render the homepage’s component into its static HTML in your server and serve it to the user. Then at the user’s browser, hydration will happen so the whole thing becomes the intended SPA.

Downsides

But there are downsides too. Apart from the extra maintenance costs, we will have to download the same payload twice—First, the HTML, and second, its Javascript counterpart for the ‘hydration’ which will exert significant work on the browser’s main thread. This prolongs the ‘First time to interactive’, and hence diminishes the benefits gained from a faster ‘First meaningful paint’.

Examples

The technologies that are adopted for this approach are NextJs, NuxtJs, and GatsbyJs.

https://github.com/turbolinks/turbolinks Turbolinks® makes navigating your web application faster. Get the performance benefits of a single-page application without the added complexity of a client-side JavaScript framework. Use HTML to render your views on the server side and link to pages as usual. When you follow a link, Turbolinks automatically fetches the page, swaps in its <body>, and merges its <head>, all without incurring the cost of a full page load.

Phoenix LiveView

https://github.com/phoenixframework/phoenix_live_view

Phoenix LiveView enables rich, real-time user experiences with server-rendered HTML.

After you install Elixir in your machine, you can create your first LiveView app in two steps:

$ mix archive.install hex phx_new
$ mix phx.new demo --live

Features

AaaS - Application as a Stream

AaaS is supported by WebStream.

How WebStream work’s?

Load any media on website without reload page, now stream each website without reload. Over modularity each website can talk to another without barrier…

Supported media

Ładowanie mediów tekstowych, kodu aplikacji, filmów, głosu, itp.

why?

Because we can improve our stack without clouds

The Stack

How your stack looks will depend on how you want to render your application. Here is a comprehensive discussion about that, but in a nutshell:

Client-side rendering(CSR); SPA; JSON APIs —
This is perhaps the most popular approach. It's great for building interactive web applications. But be aware of its downsides and steps to mitigate them. This is the approach I took, so we will talk about it in a lot of detail.

Hybrid CSR; Both client-side and server-side rendering(SSR) —
With this approach, you still build your SPA. But when a user requests your app, for example, the homepage, you render the homepage's component into its static HTML in your server and serve it to the user. Then at the user's browser, hydration will happen so the whole thing becomes the intended SPA.

The main benefits of this approach are that you get good SEO and users can see your stuff sooner (faster ‘First Meaningful Paint’).

But there are downsides too. Apart from the extra maintenance costs, we will have to download the same payload twice—First, the HTML, and second, its Javascript counterpart for the ‘hydration’ which will exert significant work on the browser’s main thread. This prolongs the ‘First time to interactive’, and hence diminishes the benefits gained from a faster ‘First meaningful paint’.

The technologies that are adopted for this approach are NextJs, NuxtJs, and GatsbyJs.


Single SPA

Najprostszy sposób, aby zacząć: możemy użyć okna postMessage() do komunikacji między aplikacjami.

Jest to framework do komponowania ze sobą aplikacji frontendowych. Jeśli chcesz rozpocząć prawdziwy projekt, wybierz ten poniżej:

Mikrofrontend pozwala nam łączyć kilka aplikacji napisanych nawet w różnych frameworkach Frameworki są tylko narzędziem, najważniejsza natomiast dla nas jest możliwość podzielenia aplikacji funkcjonalnie i przydzielenia tych części zespołom.

https://single-spa.js.org

Frint

To kolejny framework do komponowania ze sobą aplikacji frontendowych. Bardziej elastyczny niż Single SPA, ale nowszy i mniej popularny:

https://frint.js.org

WebComponents - Komponenty webowe

Nie jest to framework, ale funkcja przeglądarki i być może przyszłość Internetu. Oto artykuł na ten temat:

https://www.webcomponents.org/introduction

Taylor

Framework ten wykorzystuje inne podejście, tworząc stronę routingu na backendzie za pomocą node.js. Jeśli pomysł Ci się podoba, warto zobaczyć:

https://github.com/zalando/tailor

https://github.com/turbolinks/turbolinks Turbolinks® makes navigating your web application faster. Get the performance benefits of a single-page application without the added complexity of a client-side JavaScript framework. Use HTML to render your views on the server side and link to pages as usual. When you follow a link, Turbolinks automatically fetches the page, swaps in its <body>, and merges its <head>, all without incurring the cost of a full page load.

Phoenix LiveView

https://github.com/phoenixframework/phoenix_live_view

Phoenix LiveView enables rich, real-time user experiences with server-rendered HTML.

After you install Elixir in your machine, you can create your first LiveView app in two steps:

$ mix archive.install hex phx_new
$ mix phx.new demo --live

More