Deep Dive into Push-based Front-end Architectures

Aliaksei Kuncevič at Code '23

Introduction to Push-Based Front-End Architectures

Aliaksei Kuncevic opens his talk by introducing the topic of push-based front-end architectures, expressing his long-term exposure and enthusiasm for the subject.

Server-Side Technologies and Real-Time Data Delivery

Kuncevic discusses various server-side technologies that enable real-time data delivery, which help in reducing network traffic and enhancing user experience.

Client-Side Data Handling in Push Architecture

The focus shifts to the client side, exploring how data is handled once it reaches the client in a push-based architecture. The talk promises solutions for current project challenges.

Comparing Pull-Based and Push-Based Approaches

Kuncevic contrasts pull-based and push-based approaches, highlighting the importance of understanding both, especially their challenges and complexities.

Diversity in Front-End Frameworks

He touches on various front-end frameworks, emphasizing the diverse choices available in modern web development and their compatibility with push-based approaches.

Client-Side Server Interaction and Data Flow

The presentation delves into the typical client-side server interaction in web applications, focusing on data flow and the essentials of pull-based approaches.

Simplifying Front-End Architecture with Push-Based Approach

Kuncevic explains the simplicity of front-end architecture using a push-based approach, highlighting its benefits like real-time updates and reduced code complexity.

Role of Observables in Push-Based Mechanisms

He introduces the concept of observables as a crucial element in enabling push-based mechanisms, mentioning RxJS as a key library in this context.

Introduction to State Management Solution: Elf

Kuncevic presents Elf, a state management solution built on top of RxJS, as an effective tool for managing complex entities and states in applications.

Appropriate Use Cases for Observables

The talk concludes with guidelines on when to use observables, based on whether data is continuously changing, and a brief summary of the discussed approaches.

Thank you for coming for that talk.

So today we'll talk about push based front end architectures.

I hope you're excited about that topic, same as myself.

So I've been exposed to push based for quite a while, and so yeah, let's start slowly getting into that.

There are lots of different server side technologies, which probably some of those you're familiar with.

Nowadays it's very easy to enable server side, like a push based real time, and these sort of things, which really helping faster data delivery, reduce network traffic, and improve user experience.

But today we actually will be talking about what's happening with the data, once it reaches the client side.

So we're talking about client side today.

So once these data reach the client side, so we're going to talk about that, what's going to happen with this data, how you enable all this push architecture within your front end side.

So this talk about simplicity is problem solving and also I will provide you with a couple of solutions, which we, which you can just take and apply for your current situation with your projects.

These solutions they fully framework agnostic.

So yeah, we jump first into pull based approach, because I think it's important to understand the pull based before we get into push based.

I'll talk about challenges and complexities.

Related to the pull based and then we jump into push based approach.

I'll explain some benefits and provide you some solutions.

So yeah, but before we get into that, let me introduce myself.

I'm Alexei Kuncsevic I'm working at Angular Consulting and we're providing solutions and consulting for medium and small and big businesses, sometimes small businesses as well.

So we provide engineering and training, we're empowering dev teams and businesses with the latest technology and engineering practices.

Yeah, for more details, check out angularconsultant.Au.

Yeah as it's been said, I'm a Master of Science and Google Developer expert.

Also I'm speaking at events meetups events like that.

Conferences I don't like to speak online much recently because over Covid there was too much online, but yeah, in person is great.

Connecting with people and participating in these different sort of, in person connections is always great.

So as I'm teaching and mentoring and the next workshop I'm going to take place in Microsoft Reactor earlier next month is going to be Angular workshop.

The latest Angular, not the old Angular.

So yeah, I'm a host of AngularWorks Podcast.

Actually, if you want to take, later on, if you're interested to have a couple of, oops stickers, Angular Robe stickers, so feel free to grab some.

Yeah, I'm also organizing, co organizing GDG Sydney, so if you're ever around Sydney, please come join the GDG Sydney meetup.

You also have one in Melbourne, so for those who are interested in attending Melbourne branch, feel free to do the best way probably just Google GDG Melbourne or GDG Sydney, wherever you are, GDG Sydney Meetup, GDG Melbourne Meetup, and you'll see it there.

So yeah, also I have a free time, and I spend my spare time walking, usually I'm walking around the coast or if the weather is really good I might cycle around Sydney or surroundings.

Any motorcyclists in the audience?

Huh.

One.

Nice.

Yeah, there is not few, not more, not many of us survived.

So yeah, this is a front end talk and you probably familiar with some of those hot front end frameworks and libraries.

So anyone using Angular?

Any hands?

Huh.

Yep, a little bit more than a motorcyclist, nice.

Svelte, huh, all nextJS, React, huh, a little bit more hands.

Vue, Solid.JS, all right, I see.

Any other frameworks which I haven't mentioned?

Huh?

Yeah nice.

Always works.

And solution I provide today should be applicable for your framework as well.

So yeah it's interesting, actually, I get into frontend after being a full stack for many years, and then at some point in my career I decided, okay, I want to become a frontend developer, because I was really excited about TypeScript and, these component architectures and everything, but before I exposed all these ideas, my first question was like, coming from my previous engineering background, how to get element by ID?

That was my first question.

Why?

Because I come from that sort of background, I was exposed a lot into that sort of coding basis where we Set a candela, and then there is something going on here.

It's actually a spinet, yeah, it was my previous stack before 2016.

Then I was also, sometime in my career, I was exposed to jQuery, okay?

This was maybe 2000, ah, whatever.

So yeah, it was also a way of doing things.

And so with this mentality, I I came to the modern content engineering land.

Yeah, sometime later, I got this aha moment that actually I have to relearn some things.

Something I've done in the past, not as relevant.

It still works, but probably, there's better options.

And yeah, it's very important building more different end applications.

It's very important to know how you organize your data flow and component communication.

So this is very two important things.

We touch those later on during presentation.

So yeah, that's the typical client side server interaction, the backend, the frontend, they're talking to each other through request and response.

That's standard.

Many applications rely on that approach and this is actually a tool based approach.

THe pool based essentials are functions, event listeners, and promises.

So let's take a couple of examples, like synchronous, standard function call, pull based array iteration, and asynchronous, like event listener using promise, or fetch function using fetch API.

Thanks.

And proof based approach brings a few challenges.

Lack of real time updates, overfetching the data inconsistency, synchronization issues, and sometimes it might be hard to handle because if you have loads of event handlers and functions, one on top of another, it's you create a really complex chain.

And sometimes imagine you inherit this legacy codebase from someone else.

We should learn all this complexity, all this, abracadabra so it's really hard to understand this code, and also it's really hard to debug.

And yeah, once you, and this all, if you develop, are developing using pull based approach, you come up with lots of complexity, which brings maintainability issues and suboptimal UX, which is something we don't want.

So yeah, let's take this simple example using fetch function, and this view, simple view, fetching the data, displaying data in a template HTML.

If there are any issues with that with that code, you think, the answer is depends.

Because if it's just a simple application, one or two components, that's probably fine.

You just fetch the data, show it on your, in your template, and you're done.

But usually real, like real world applications represent by a complex tree of components.

Which like maybe dozens or hundreds components.

And yeah, we need to find a way how we can unify those components as well as how we unify the data flow, which goes around and fetching and, providing the data for your application.

So usually one component might rely on another component, if something's wrong, if something happened, trigger say, something by user input or by server side interactions you get this new data in component B, and maybe component C and A rely on this same piece of data, so those, C and A has to be updated accordingly, probably with a change detection or some, or something like that, and same goes with the rest of the component tree.

Yeah, applications can be really complex.

And what usually triggers those changes in your front end application, like data changes?

So the NSR front end application, yeah, it's usually triggered by backend sending new data to a client, and user input, by using, by users clicking around the application.

Maybe typing or clicking some UI elements, so backend and user input are two enemies for frontend, as you can tell by that slide, they're always, you know I can interrupt your application, so you as a developer have to think about all those use cases because you really want to provide the best user experience for your users.

So that's a simple dashboard data.

Push to the client side and client side react on those changes in real time.

That's another example, another dashboard.

It's complex.

Internet of Things dashboard, and that's another example, complete grid, with editing functionality.

So anything change, if you, for example here, if you change the name of the product, clicking update, the name of the product automatically updates in a list.

And yeah, by using a tool based approach, we always have to think.

about who's responsible for modifying the data and when, how can multiple use be aware of data updates, when the new data should be pulled, and why is the shared data changing?

So yeah, this is important questions you all need to answer building applications, front end applications using pull based approach as well as debugging someone else's code.

Yeah, there's too much things of to think about, but how about if you imagine that you don't have to answer all those questions?

Does it sound good to you?

How about if, imagine if the data flows to your use automatically, and you're just sitting there drinking your coffee or tea, and absorbing your nice UX, I think it sounds cool.

So let's have a look at, into this simple front end architecture.

We have our back end and front end.

Component, service class, and store.

So this is on the frontend we have these three elements.

So let's see how interaction works.

So backend sends the data to a service, to the service class.

Then service class corresponds to the store.

Store is just a variable.

Send the data.

And instead of component interacting directly with service in the backend, component interacting with the store.

Yeah, that's the push based approach, and also, of course, we have to remember about the user.

The user is always fiddling around the application inputs and clicks, button clicks, and every any other UI elements that represented on the screen.

So yeah, user, also involved in this into this picture.

This architecture doesn't limit by just one single component.

It can go as many components as you want, as many services as you want, and stores, as many stores as you want.

So usually in my practice, I am creating one store per feature.

So feature might contain a number of components, and yeah, having one store per feature.

So this is a push based approach.

The benefits are views getting out updates, you're writing less code it keeps you away from callback hell, anyone dealt with callback hell?

Yeah, there is no callback hell here.

It's simple to use test and easy to maintain and debug.

So what enables push based mechanism, you might think?

Any ideas?

It's on the server side.

On the client side, so there is a nice thing called Observables.

Anyone heard of that?

Nice.

So yeah this mechanism enabled by observables.

It's a really great technology pattern, if you will and it brings to JavaScript applications by a library called RxJS.

Anyone heard of that library before?

Yeah, a couple of hands, nice.

Yeah, you can use it also on the backend, but here we're talking about frontend.

And yeah, if you want to learn more about RxJS, check out AngularWorks episode number 25, where me and Ben Lesh, the team lead of RxJS, talking about RxJS.

We're talking about top level concepts, why's, and history, and the future of RxJS.

It's about a 30 minutes episode .

Yeah, that's actually the code of a code example for service class,

which implements observable store.

There's a couple of functions like set, value, reset, reset state, and get state.

And that's how you can And that's how you consume it in your view.

Very simple.

Different frameworks provide different ways of plugging the observables, so it depends on the framework.

The code might look a little different, but the idea is pretty much the same.

So say at some point you go actually it's more functionality.

Maybe I need yeah, maybe you have a complex entities in your application.

Maybe you want to persist a state.

Maybe you want to synchronize your state across different tabs.

Maybe you want to save your state history, enable advanced pagination, maybe you're dealing with complex grids, etc., etc.

And yeah, you can write this functionality yourself on top of observables, on top of your RxJS lIbrary, but sometimes it probably might, doesn't make sense.

And as developers, we want to save time, in some cases we want to reuse someone else's work, which always happened in our industry.

And so here, a great state management solution, which built on top of RxJS is called Elf.

Anyone heard of Elf?

So it's fully a framework independent library.

It doesn't rely on framework at all.

So you can use it with any any framework you want, or with no framework at all.

If you choose a vanilla JavaScript, you can use it as well.

And so here is a code example using Elf.

It's pretty much looking the same as I showed you before, only different that we declare and store a little, line seven and two to nine looks a little different, but all the rest is pretty much the same.

So really, if you start with your custom service classes, and then at some point you decide, okay, actually I need more functionality, you just use a small little change.

You can bring that Elf into your solution and continue your development.

If you want to learn more about Elf check out this URL.

So yeah observables it's a great technology, it deserves, it's really deserves separate talk.

Actually, I gave one of those talks last year at Web Direction Summit in Sydney.

It's called Reactive Programming in Modern Web.

So yeah but today we don't have time to dig deeper into that subject.

The best way, for those who knew into observables, the best way to think of observables is like value over time, so yeah, that's all I can tell you today.

So, who's using observables?

There is lots of companies using observables in their solutions.

For example, Google using observables in Google Cloud, in Firebase Console, and many other products.

Sony using observables in PlayStation dashboard.

Anyone playing PlayStation?

Yeah.

So guys, the PlayStation dashboard used observables.

Uber using observables as well.

It's not only limited to client side.

They're using it on both server and client.

Netflix, Canva, you name it, all those major companies.

They're using observables.

Anyone seen the number of downloads for RxJS library on npm?

Check it out, you'll be surprised.

I won't tell you the number, but it's freaking crazy.

It's a crazy number.

Okay, for those who lazy to look up, last time I watched probably a couple of weeks ago, it was closer to 17 million NPM downloads per week.

Yeah, it's not a small number, right?

Yeah, so this library and observables getting used across the industry.

It's not an industry standard because observables are not standardized.

However, there is a proposal, ECMAScript proposal, But it's stale.

It's stale for probably five years.

This proposal was raised, I think, by Ben Lesh, the RxJS team lead.

And yeah, it's stale.

So the proposal proposes, like elements like inputs, and other similar standard HTML elements to support observable functionality.

So once user input data the proposal proposed to actually, those elements to emit values over time.

So you kind of subscribe for this data automatically.

But unfortunately, yeah, check it out if you want to, if you're interested, just Google about that and you learn more about that proposal.

I think we're getting closer to the end.

So when should you use observables?

It's a very good question.

You don't have to use it always.

You can, but sometimes it doesn't make sense.

And so here is the basic rule.

You have to ask this question, is data continuously changing?

So if the answer is no, so we're not using observables.

But if the answer to this question is yes, Then we consider using it.

You don't have to anyways, it's up to you.

Yeah, you decide and your team, but yeah, I would recommend using observables in that case.

So wrapping up, we just talk about pools, pull based approach.

Probably the term pool based you wasn't familiar with this pool based approach, but once I show you a couple of code examples, like definitely any developer exposed to that approach, right?

It's just functions and callbacks and promises and things like that.

So I explained to you the challenges and complexities related to this approach.

It doesn't, nothing wrong with this approach.

It doesn't mean that you don't have to, you have to stop using that.

It's not possible to stop using pull based, right?

Usually our applications probably like applications, I'm right.

Is it hybrid?

I think part is pull based, another part is push based.

It depends on, on the use case and depends on the nature of application you build.

And sometimes maybe you don't want push based at all, it all depends, but in many cases you might want to consider that push based approach.

So I showed you benefits related to that push based approach and provide you a couple of solutions related with RxJS library and Elf, which is a nice library built on top of RxJS.

So yeah, I think that's a wrap.

So let's connect.

You can, I'm looking forward to connect on LinkedIn or Twitter.

And if you scan this QR code, it will lead you to my LinkedIn profile.

If you want to grab some stickers, feel free to reach out on the break.

So I have plenty of those, these Angular Rocks stickers.

And on that note, I'm looking forward to your questions.

I think we have about five minutes left.

Thank you for listening.

The image displays logos and names of popular server-side technologies and platforms. The logos for supabase, Firebase, GraphQL, HASURA, Socket.IO, and SignalR are shown, which are used for various backend and real-time applications. Additionally, the company logo for ANGULAR CONSULTING is present at the bottom of the slide.

Real-time server side

Faster data delivery
Reduced network traffic
Improved user experience

A vibrant image of Elmo, the cheerful, fuzzy red Muppet from "Sesame Street" sliding down a kids enclosed slide.

Simplicity and problem solving

Illustration shows a stick figure standing at the edge of a cliff on the ground labeled "PROBLEM SOLVING" looking down at a smaller figure which could be another character or an object at the bottom of the cliff.

Simplicity and problem solving

SOLUTION ENGINEERING

The image features a cartoon illustration of three stick figures engaged in what appears to be a problem-solving scenario. There is a clear separation between two of the figures who are discussing the issue on one side of a chasm, and another figure on the opposite side, apparently having solved the problem. The solved side is labeled "SOLUTION ENGINEERING," with a computer screen and a lever, signifying a technical or engineered resolution to the problem depicted.

ALIAKSEI KUNCEVIC

twitter.com/kuncevic
linkedin.com/in/kuncevic

ANGULAR CONSULTING

CONSULTING
ENGINEERING
TRAINING

angularconsulting.au

@kuncevic

Master of Science in IT

@kuncevic

SPEAKER

TEACHING + MENTORING

PODCAST

Angular Rocks

On the left, Aliaksei standing on a rocky cliff with their arms and legs spread wide. On the right, a motorcyclist in full gear on a red and white motorcycle, with a blurred cityscape and the Sydney Opera House in the background

Modern front-end

The image shows logos representing modern front-end technologies or frameworks. These include Angular, Svelte, Next.js, Vue.js, Electron, and React.

How to get element by id?

Typical code


// view:
<asp:Button ID="btnClickMe" runat="server" Text="Click Me" OnClick="btnClickMe_Click" />

// class:
protected void btnClickMe_Click(object sender, EventArgs e)
{
    // Handle the button click event here
}

Typical code

<button id="btnClickMe">Click Me</button>

<script>
  $(document).ready(function () {
    $('#btnClickMe').click(function () {
      // Handle the button click event here
    });
  });
</script>

The AHA! Moment

The image displays a large, bold text "The AHA! Moment" alongside an illustration of a light bulb that symbolizes an idea or a moment of insight.

Front-end

Data flow
Component communication

Typical client-server interaction

A simplified diagram illustrating the typical interaction between a client and server in computing. The client-side is labeled as "Front-end," and the server-side is labeled as "Back-end." Arrows indicate the flow of a request from the front-end to the back-end and a response from the back-end to the front-end.

Pull-based essentials

Functions
Event listeners
Promises

Synchronous

// standard function call
const response = fetchData();

// array iteration
const profile = this.usedData.map(user => {
  return user.profile;
});

// async listening for event
const buttonClick = new Promise((resolve) => {
  const onClick = event => {
    resolve(event.target);
  }
  
  window.addEventListener('buttonClick', onClick);
});

// async data load
const data = fetch(url);

Pull-based challenges

Lack of Real-time Updates
Over-fetching data
Data Inconsistency
Synchronisation
Handling Errors

Problems

Code Complexity
Maintainability Issues
Suboptimal UX

Asynchronous

// async data load
const data = fetch(url);

View

@Component({
  selector: 'app-component',
  template: '{{ data }}',
})
export class Component {
  data = fetch(url);
}

Component tree

A graphic representation of a tree with a brown trunk and branches, as well as green leaves.

Component tree

The image contains a diagram illustrating a component tree structure. It is made up of circles (representing nodes) connected by lines (representing relationships), arranged in a hierarchy. The top node is labeled 'A' with two child nodes 'B' and 'X'. 'B' connects to 'C,' which in turn connects to 'D'. 'X' connects to three nodes labeled '1', 'Y', and '3', with 'Y' connecting further to a node labeled 'Z'. There is a dashed line indicating a relationship between the 'A' and 'C' nodes.

What triggers the data change?

A diagram illustrating what triggers data change in a system. It features a central rectangle labeled "Front-end" representing the client side. Two arrows point towards this rectangle: one from a pill-shaped object labeled "Back-end" with a dashed line labeled "New Data", and another from a rectangle labeled "User" with a dashed line labeled "Input".

Screenshot of a complex dashboard showing real time values of crypto currency.

Screenshot of a smart home dashboard.

Screenshot of a complex ecommerce search page.

Data flow

Who is responsible for modifying the data and when?
How can multiple views be aware of data updates?
When the new data should be pulled?
Why is the shared data changing?

The image shows an animated character, SpongeBob SquarePants from the television series, standing with his mouth open in surprise, arms outstretched, and eyes wide.

Imagine you don’t have to answer all those questions

Imagine the data flows to your views automatically

Simple front-end architecture

A diagram illustrating a simple front-end architecture. There are labeled elements such as Component, Service, Store, and Back-end, connected by arrows indicating the flow of user input and data. The Component interacts with both the Store and Service, whereas the Service communicates directly with the Back-end to exchange data. The terms push and set are depicted as actions within the front-end ecosystem.

Push-based

Benefits

Views auto updates
Writing less code
Keeps you away from 'callback hell'
Simpler to unit test
Easy to maintain

Observables

The RxJS logo.

NEW EPISODE

ANGULAR ROCKS PODCAST

Aliaksei Kuncevic

EPISODE #25:

RXJS

angularrocks.com

Basic push-based service

interface Counter {
  value: number;
}

const initialState: Counter = { value: 0 };

export class CounterService {
  private store$ = new BehaviorSubject<Counter>(initialState);
  state$ = this.store$.asObservable();

  public setValue(value: number): void {
    const currentData = this.store$.getValue();
    this.store$.next({ ...currentData, value });
  }

  public resetState(): void {
    this.store$.next(initialState);
  }

  public getState(): Counter {
    return this.store$.getValue();
  }
}

There are no images, diagrams, tables, or graphs to describe as alt text in this submission.

View

@Component({
  template: `
    {{ values | async }}
  `
})
export class Component {
  this.values = this.counterStore.state$
              .pipe(map((x) => x.value));
}

Need more functionality?

Complex Entities
Persist State
State Synchronisation
State History
Pagination
Editable Grids

Elf state management

Push-based service using Elf

interface Counter {
  value: number;
}

const initialState: Counter = { value: 0 };

const store = createStore(
  { name: 'counter' },
  withProps<Counter>(initialState)
);

export class CounterService {
  state$ = store.asObservable();

  public setValue(value1: number): void {
    store.update(setProp('value', (value) => value1));
  }

  public resetState(): void {
    getRegistry().forEach((store) => store.reset());
  }

  public getState(): Counter {
    return store.getValue();
  }
}

ngneat.github.io/elf

Observables

Who is using observables?

Brands

Google
SONY
Uber
NETFLIX
Canva
KLM
YouTube
slack
GitHub
amazon
Microsoft

The image contains the logos of various popular companies, each presented in their unique and recognizable branding styles and colors.

When should I use observables?

The basic rule

The image includes a flowchart that helps determine when to use Observables. There is a central question "Is data continuously changing?" with two possible answers leading to two different boxes. The "NO" direction points to a box that says "don't use Observables," and the "YES" direction points to a box that says "Consider using Observables."