WARNING: I assume that you know basics of asynchronous programming, if not then please read this before going any further: Asynchronous Concepts

So, what’s RxJs?

According to the documentation:

RxJS is a library for composing asynchronous and event-based programs by using observable sequences. It provides one core type, the Observable, satellite types (Observer, Schedulers, Subjects) and operators inspired by Array#extras (map, filter, reduce, every, etc) to allow handling asynchronous events as collections.

In simple words, RxJs is a library which helps you in working with asynchronous tasks, events and streams and it does that by sharing some useful classes like aforementioned Observable and a ton of cool operators (due to my desire of keeping this post relatively short I am going to present only 5 operators that I find the most useful in my everyday work). Actually, RxJs has been so helpful to the Angular community that the Angular team decided to include it into Angular itself with the 6th version.

We are going to focus on Observables this time. Observable is a class that allows you to listen for events. To retrieve data from an observable you need to subscribe to it, when you do that it listens for events happening, so when they happen, you get the data. You can get more details on observables here: https://rxjs.dev/guide/observable.

Now let’s discuss 3 most common situations where developers are using Observables

Http Requests

All HtttpClient methods are returning Observables and that is of course because it takes time for a server to process and return the data (or just return in case you’re sending a get request). That means that http request operation is asynchronous.

DOM events

Observables enable you to easily listen for DOM events like click or keyup. To listen to them you should use the fromEvent function that creates an observable accordingly. Here’s how this looks like:

fromEvent(document, ‘keyup’);

(Remember that if you want to receive the actual data you should subscribe to it by adding .subscribe() before semicolon)

Stores

Another very common use case for using Observables is using them with some kind of store, like NgRx or NgXs. Stores like that usually share observables in order to keep watch over the state of the application.

Now since you know the very basics like why and how, let’s get to the useful interesting stuff that can be one with RxJs operators.

RxJs operators

In our examples we are going to use simplest observable possible:

const obs$ = from([1, 2, 3]); (dollar sign at the end of the variable is a naming convention used to singlaize that the variable is indeed an observable)

How to use operators?

Easiest way to use operators is by putting them inside a pipe. Pipe runs a function for every stream element passing by the operator, and operators are the functions that can be used within it.

first

First operator is the first operator that we’re going to talk about (got the pun?). Most operators have self-describing titles and this case is no different. First operator basically allows you to listen for the first returned value of the observable and then stop (note that it is completely useless combined with Http requests that return the value once anyways)

obs$.pipe(first()).subscribe(numbr => console.log(number));

Code above prints only 1 because it’s the first event emitted, 2 and 3 are ignored.

tap

Another useful operator worth mentioning is tap. Tap allows you to perform some kind of side effect for every event emission. For example you can log something or assign data to a variable (note: if you are using .subscribe it is basically the same thing).

obs$.pipe(tap(numbr => console.log(number))).subscribe();

Code above prints 1, 2 and 3 because tap is triggered for every emitted value.

map

Map is working the same way as in arrays. So it basically allows you to change structure of returned data. For example, let’s try to multiply every value returned by 2

obs$.pipe(map(numbr => numbr * 2)).subscribe(value => console.log(value));

The code prints 2, 4 and 6 just as expected.

startWith

StartWIth allows you to decide what first value is going to be. It is useful when you want to trigger the observable before the first event emission.

obs$.pipe(startWith(999)).subscribe(value => console.log(value));

Printed values are: 999, 1, 2, 3.

switchMap

SwitchMap is used mainly in typeahead cases but not limited to them. What it does – it cancels previous request when a new event arrives. In real life case you would for example listen for changes on the input and filter a table while typing (previous result is not relevant).
To present switchMap fully – this time we are going to use a different example. Observable is going to be created out of DOM event keyup.

const another$ = timer(1000);
fromEvent(document, 'keyup').pipe(
switchMap(() => another$)
).subscribe(() => console.log('log'));

What happens here is: After you click a button on keyboard, wait 1000 ms and then log a message. Now what happens ,if you click button 10 times quicker? Only one message is going to be logged, and that is because switchMap cancels previous timers leaving only the most recent one.

We went over 5 most useful operators in my opinion, described what RxJs is and discussed common use cases. I hope that this article will help you in your next project and interest you in exploring RxJs more 🙂

Inero Software provides knowledge and expertise on how to successfully use cutting edge technologies and data to shape corporate digital products of the future.

In the blog post section, you can find other articles about our projects and more! 

Artykuł RxJs for beginners (5 most useful operators) pochodzi z serwisu Inero Software - Software Consulting.

SchedulerFactory schedulerFactory = new StdSchedulerFactory();
Scheduler scheduler = schedulerFactory.getScheduler();

public class FileDownloadJob extends QuartzJobBean {

   @Override
   protected void executeInternal(JobExecutionContext jobExecutionContext) throws JobExecutionExceptions{
       // target code of performed operations
   }
}

JobKey jobKey = JobKey.jobKey((task.getId());

JobDataMap jobData = new JobDataMap();
jobData.putAll(new HashMap<>() {{
 	  put("email", user.getEmail());
  	  put("name", user.getName());
          put("progress", task.getProgress());
}});

JobDetail jobDetail = newJob().ofType(FileDownloadJob.class)
       				.withIdentity(jobKey)
      				.setJobData(jobData)
      				.build();

Trigger trigger = newTrigger()
       .startNow()
       .build();

scheduler.scheduleJob(jobDetail, trigger);

public class FileDownloadJob extends QuartzJobBean implements InterruptableJob

@Override
public void interrupt() {
   _interrupted = true;
}

if (_interrupted) {
   break;
}

scheduler.interrupt(jobKey);

jobDataMap.put("nextJob", nextTask.getId());

Artykuł Java: Scheduling the execution of background tasks using Spring pochodzi z serwisu Inero Software - Software Consulting.

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.

One of our teams field of specialization is the use of artificial intelligence for modeling and optimizing complex transport models. From the practical point of view, the optimal planning of transport resources and supervision of their implementation is one of the key tasks in the area of ​​supply chain management.  In this type of solutions, using artificial intelligence and advanced computing IT systems can bring  observable benefits. One of the solutions this post refers to is the optimization of redistribution network of the supply chain (RCSN).

Pros, cons and uses

RCSN is an alternative to the centralized distribution networks (CDN) that consist of one central warehouse for the storage and distribution of goods. CDN is effective if we carry out large, repetitive orders to destinations that are close to each other. If our supply chain get’s more complicated we can add some a number of local warehouses to place the goods closer to final destination. While the CDN generally simplifies transport management, it does not allow to optimally distribute costs of supply for complicated logistic models. Though the RCSN is more complex and more expensive to manage compared to the classic versions of warehousing, with the support of a specified IT solutions it guarantees a stable level of services, maintaining the performance of order management and distribution. 

Use case

In this article, we will show how Inero Software team deals with the above-mentioned problems in an example use case. Let’s assume that we have a company with many branches and we need to exchange the necessary materials between them for proper functioning. To optimize costs and efficiency, we don’t always need to complete another large order from the supplier, but we exchange materials between nearby branches. It is a much better and faster solution, and one of the most important aspects is that it minimizes the workload. 

Let us assume, that in our showcase , we have 4 drivers and 40 company branches between, where each branch belongs to 1 of 4 groups( indicated by pin color in figure below). In the given use case, it was assumed that the goods may be stored and exchanged only between locations from the same group (a pin of the same color on the map), but the transport flow must be maximized between all locations. In order to optimize the total supply chain, it was assumed that the closest locations in a given group are the warehouses in the vincity of the particular driver’s home-base. This means that before the commodities are exchanged between individual points, the driver must pick up the goods from the defined warehouse and store them at the end of the daily route. 

In addition, when generating routes by the system, optimization algorithms takes under consideration following constraints: 

• each driver starts and finishes his/hers route at the warehouse. This means that the driver cannot leave any goods in the car for the night before/after the route;
• goods are intended to be transferred among one group and cannot not be stored in the local warehouse (destination) of other groups. However, commodities dedicated for different groups, can be transported by the same vehicle;
• every destination (location) can be considered as a local warehouse;
• the driver cannot exceed the driving time and daily mileage limit;

Moreover, some other specific limitations can be defined in the system, e.g. that the driver can only move in a restricted area, maximum 9 hours a day, can be defined. In this context the goal of the optimization is to maximize cargo flow between different branches of the company. 

The picture below shows an example of the result optimization of redistributing goods using our solutions.  

As you can see in the picture above, the system has generated a driving plan for each driver for each day of the week. Thanks to this, we can ensure the exchange of the necessary goods in a given area, even several times a week.  

As part of defining individual locations of the local warehouses, each of them was given a unique id in the range 10-49.  The illustration below shows the generated driver’s work plan divided into individual days. 

It can be seen that the simulation requirements were met. If we visit a certain group on a given day, we initially pick up the goods and finally store them in the same unit belonging to the same group.  

If the problem would require the exchange of goods between larger areas, e.g. from the western part of Poland to the northern part, etc., the implemented software could be extended with drivers’ meeting points and the exchange. Then, the cargo can be delivered depending on the demand to specific branches of the company. This process is based on the previously generated solution. The system’s algorithms determine which locations have been selected for drivers’ routes. On this basis, the route-based, the system finds the closest point on the map where drivers can potentially meet. If there are such places, they are added at certain times, (e.g. 12pm to 1pm, Monday) to the driver’s schedule. In the next stages, the system intelligently selects the remaining locations, maintaining continuity and increasing the area of exchange.

The figure below shows the location of meeting points on the Monday route for drivers’ routes (Szczecin – Gdańsk) and (Wrocław – Legionowo).   

Cargo swap points have been given a unique id to include them along the route. 

• (Szczecin – Gdańsk) – 100, 
• (Legionowo – Wrocław) – 101.

As you can see, meetings are held at designated times. Thanks to this operation, we exchange goods between larger areas, and in the next days we can distribute it to other locations. 

Solution

In our solutions, we use methods and techniques of artificial intelligence to model the problem of redistribution of goods and then optimize the commodities flow in distributed network. In situations where a large amount of calculations is required, various heuristic methods come to the rescue. They allow to minimize calculation costs and speeding up finding the optimal solution. Heuristic searches are suitable for complex problems. The artificial intelligence estimates quality of available solutions, and every iteration improves output result. In the case of a logistic redistribution network, every step of the optimization, extends the resulting node (i.e. in our case the route) with the node with the lowest value of the predefined evaluation function. 

In our solutions, for example, we use the greedy algorithm. The model at each step makes the optimal choice at the moment, based on the given evaluation function. In the case of transport problems, it will certainly be the number of kilometres imposed converted into costs compared to the current fuel price. The algorithm, by adding new customers along the route, makes the optimal decision, i.e. the cheapest one at the moment. 

The simplest form of the evaluation function can be defined as: 

cost = new_distance - current_distance

where:

new_distance – total distance to the new point from the driver’s location, 

current_distance – current distance, from the driver’s location to the actually last point. 

Summary

The use of IT systems supporting the supply chain redistribution network definitely allows for an optimized flow of goods. In addition, it can provide many additional analytical tools, such as: 

• order and invoice reports,
• archiving statistics,
• delivery time information system, 

and many others tailored to customer needs… 

Artykuł Redistribution supply chain network 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.