Why Angular?

At Inero Software we are using Angular at the front-end side of most of our projects and that is not without a reason.

• It is suitable for big software systems because of its component-based architecture which provides a higher quality of code, better maintainability, and code reusability.
• Native Typescript support, Typescript means Types and that means safer code.
• Angular, unlike other frameworks, is fully stacked with predefined solutions to problems you may approach, you don’t have to think about which library to use for every single implementation case whether it be routing, reactive programming, or making Http requests.

What’s a back-end long-running asynchronous task?

The easiest way to understand what’s a back-end long-running asynchronous task is to explain it with an example of our product which possesses this kind of task.

At Inero Software we are developing a product called DeliverM8 which is a delivery optimization platform. It has many functionalities but let’s focus on the important one for today’s article. Imagine that you run a company that is delivering products all around the country. You need a system that would display to you how many products and which products to put onto a truck and also how should they be ordered so that everything fits nicely.

Input requires the following data:

• How many products should be delivered?
• What are their sizes?
• Where do they go? (so we know which products should be on the beginning or end of the truck etc.)

The output is a 3d visualization which looks like this:

As you may imagine – it does take time for a backend service to create output like this, the AI that stands behind DeliverM8 logic runs millions of operations per second in order to find the best optimal available element arrangement. This is the back-end long-running asynchronous task. Depending on the input this may take up to 10 minutes and of course freezing of the frontend application until the data is retrieved is the last thing that we need, so what should we do?

Approaches

A DISCLAIMER: All examples are made with Angular, but the concepts mentioned below can easily be applied to any other frameworks/languages.

Synchronous

Probably the worst option out there but should be mentioned nevertheless. If in fact, the user shouldn’t be using the application, while he is waiting for the response, then you can just put some kind of modal loading screen while the user awaits the data and the problem is solved.

How:

You send a single POST request that tells the backend to start the calculations and return the data within the response of the beforementioned request.

Example:

public loadTrucks(loadTruckData): Observable<Route[]> {
return this.http.post<Route[]>('/api/load-trucks', loadTruckData);
}

Polling

Now polling is a slightly better option if the user wants to use the application while the data is loading and you don’t have that much time to invest in the solution and/or your backend is not providing you with WebSockets then polling is the way to go.

Polling means checking the status of (a backend endpoint in this case ), especially as part of a repeated cycle. Translating it to front-end language means making a get request every few seconds to see if the asynchronous task is finished. For backend that would mean creating a new GET endpoint that would return the calculated data. (if in fact it has been calculated before)

Not the most elegant solution out there but still pretty usable!

How:

We make one POST request that informs the backend to start the calculations and one more GET request to get the output data.

One of the ways of polling is combining RxJs’s timer with switchMap. Also remember to unsubscribe, because all sorts of intervals can easily produce memory leaks, in this example, we are using takeUntil operator that unsubscribes from the observable when it’s component is destroyed.

Example:

timer(0, 5000).pipe( switchMap(() => this.truckService.getLoadedTrucks()), takeUntil(this.stopPolling) )

Websockets

Websocket is a communication protocol (just like HTTP) “for a persistent, bi-directional, full duplex TCP connection from a user’s web browser to a server”. Basically what it means is that with WebSockets you can send out the data from the server and receive it in your frontend application without making any unnecessary requests (like you would using polling).

With the Websocket approach, you would send an HTTP POST request to start calculating the truckload. And at the same time, you would establish a WebSocket connection between the Frontend application and the server so that when the backend tasks finish the output is sent through that WebSocket connection.

How:

Send HTTP POST request that informs the backend to start the calculations and listen on Websocket connection with a backend that returns data when the calculations finish

Example:

At first, you connect to a WebSocket:

public connect() {
const socket = new WebSocket(this.webSocketUri);
this.stompClient = Stomp.over(socket);
this.stompClient.connect({},
() => this.subscribe()
}

And later on, you subscribe to its values:

this.stompClient.subscribe('/user/queue/truck-load-updates-queue', (msg: Stomp.Frame) => {
const msgBody = JSON.parse(msg.body);
...
});

The subscription above is triggered after the calculation is done.

Conclusion

That’s it!

I’ve described to you the problem of back-end long-running asynchronous tasks and various ways of handling them in the frontend application.

Websockets are the best way to go if you are struggling with this problem, but if the user doesn’t mind getting his application blocked (or maybe it is intended to block the app for the time being) for the time when the backend is performing its tasks then you can simply go with KISS principle and just make one synchronous request.

Polling is also an option if the developers don’t feel like implementing WebSockets and additional network movement is of no concern.

Thanks for reading! And I hope you liked the article 🙂

Artykuł Angular: How to manage back-end long-running asynchronous tasks pochodzi z serwisu Inero Software - Software Consulting.

The frontend world is currently ruled by 3 colossuses known as Angular, React.js, and Vue.js, but are there any other alternatives?

And if so, are they worth using? Let’s take a quick look at what else is out there as we see it in our team.

The Standard

Besides Angular (my main go-to when it comes to the frontend development) there is its main rival – React. Since React is a library not a framework like Angular, by definition it gives you more freedom when it comes to the composition of your application and development style that you want to approach. React is known for its JSX syntax which allows you to mix javascript with HTML and CSS code.

Vue.js is different from React in this matter. It is structured like web-component so it’s separated into js, CSS, and HTML. Another thing that differs Vue.js from Angular and React.js is its origin. Vue is the only “independent” framework. What do I mean by that? There is no big company behind it like in other cases where Angular comes from Google and React has been created by Facebook. Vue.js is a better choice than Angular and React when you are looking for a small app or a quick MVP development. That is because setting up a project and its configuration in Vue takes much less time than in frameworks mentioned earlier.

Okay, but where’s the new stuff you say? There you go:

Web Components

Web components as it states on its website are: “…a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML.”.

So essentially what it means is that you can create universal components with Web Components API which you can use with literally any framework (or no framework at all) that supports HTML and these components should work correctly on all modern browsers.

Probably the most popular library for creating web components right now is Polymer.
Polymer is a JavaScript library based on Web Components API created by Google employees.
Most important reasons for why Polymer is favored by Web Components developers are:
• Data binding – Connects data from a custom element to its local DOM element. Both one-way and two-way.
• Polymer CLI – Includes a build pipeline, a boilerplate generator for creating elements and apps, a linter, a development server, and a test runner.
• Conditional and repeat templates – Gives you the ability to use loops and if statements in HTML
And there’s much much more.

WebAssembly

A different approach was proposed by creators of WebAssembly which basically allows you to use low-level languages like for example C, C++, and Rust to create web applications by compiling them to WebAssembly binary instruction format – assembly-like language that runs with near-native performance.

You probably wonder how is it possible to develop a web app with this kind of languages. Well, Wasm (WebAssembly) provides you with JS API, which contains all the functionalities that you would need in web development.

So is WebAssembly going to replace JavaScript in the web development world?

Not really. It is more of an addition to the current web technology stack. Wasm should be used in certain situations, and that situations are asset-heavy performance-needing applications. Usually with a lot of computations and 3d dynamic scenes. Here are a few examples of Wasm applications that should give you an idea of what I am talking about: Google Earth, Figma, AutoCad web.

Flutter

Another tool on the list is Flutter. Flutter originally was supposed to create mobile applications (and it still does), but in Flutter 1.9 web support has been added.
Flutter uses Dart language and only this one language is used to develop applications for every intention is its frontend, backend, or mobile devices. So in theory your code for a mobile app or web app should not be that much different from each other.

One interesting thing about Flutter is a fact that it has built-in Material Design and Cupertino (iOS styled components) so it comes with a variety of very useful widgets and other advantages that those UI libraries offer (like motion APIs), you can check those out here.

This was just a really brief introduction to different frontend options out there, I’m going to make more detailed insight into those in next blog posts.

Now, at last, but not least:

Svelte

Svelte has been introduced in 2016 by its creator Rich Harris. Stating that it’s going to use a truly reactive approach, but before we get into it let’s quickly describe what Svelte actually is.
Svelte is a JavaScript component framework similar to React or Vue but with a few major differences.

Probably the most important difference is the fact that Svelte does not have a virtual DOM. React and Vue both are using Virtual DOM and because of that, the browser itself has to convert their declarative structures into DOM operations. I won’t go into details of how does virtual DOM works, but basically, what it does it checks the state of the whole application before and after the change and looks for differences in those both states and then applies what’s different to real DOM (this operation is called diffing), sounds like a lot of unnecessary comparisons, right?

Here comes the reactivity.

Svelte unlike React runs at build time which means that svelte code is compiled to imperative code which updates DOM when and where it needs to. This is obviously a big performance boost.

You probably started to wonder why is virtual DOM used by those big frameworks like React or Vue then. I think I can use a quote from the Svelte creator’s blog:

“Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough. That means less buggy code, and more time spent on creative tasks instead of tedious ones. But it turns out that we can achieve a similar programming model without using virtual DOM — and that’s where Svelte comes in”

Another thing that Svelte introduces is its own reactive statements which look like this:

$: console.log(`the count is ${count}`);

Essentially what it’s going to do is – it is going to log the string whenever count property changes and the only thing that you need to do to use it is to put $: in front of a statement which you want to become reactive. To give you a better idea of how is it working I’m going to create a component in which you can type your first name and last name assign them to fullName property and display it.

<script>
 let firstName = '';
 let lastName = ''
 $: fullName = firstName + lastName
</script>

<input bind:value={firstName}/>
<input bind:value={lastName}/>
{fullName}

I will not go into details of everything that’s happening here but what you should know that bind:value is a two-way binding so the properties are being updated while typing in the input. The important part here is the dollar syntax. Thanks to it fullName property is changed at the same moment as user is typing anything in any of those two inputs.

Of course, nothing is stopping you from writing a larger code with dollar syntax. If I wanted to update fullName only if firstName starts with letter “A” I could write something like this:

let fullName = '';
$: {
  if(firstName[0] === 'A') {
      fullName = firstName + lastName;
   }
}

Now, to display the difference in code written in React (which Svelte is most of the cases compared to) and Svelte. We’re going to create a simple app that is going to display how many seconds passed since it’s creation. (Inspired by Stateful Component on React website).

Here’s the code which you would write in those two frameworks:

React:

class Timer extends React.Component {
    constructor(props) {
      super(props);
      this.state = { seconds: 0 };
    }

    tick() {
      this.setState(state => ({
       seconds: state.seconds + 1
    }));
    }

    componentDidMount() {
        this.interval = setInterval(() => this.tick(), 1000);
    }

    render() {
      return (
       <div>
        Seconds: {this.state.seconds}
      </div>
    );
  }
}

ReactDOM.render(
<Timer />,
document.getElementById('timer-example')
);

Svelte:

<script>
 let seconds = 0;
 setInterval(() => seconds += 1, 1000);
</script>

<div>
Seconds: {seconds}
</div>

You can see the difference right?
Both of those applications do exactly the same job, but it is immediately noticeable how much code was needed in the React app and also how readable it is with its state, setState, and rendering functions. At the same time, Svelte requires about 8 lines of pretty, easily understandable code to get the task done.

If you are interested in what else Svelte has to offer and to understand better why this framework could be worth trying I deeply encourage you to watch Rich Harris speech.

Artykuł What’s after Angular? pochodzi z serwisu Inero Software - Software Consulting.