Micro-Frontend Architecture Part 2: The Implementation with Angular and Web Components

15 Feb, 2021, No comments

Last week we have introduced you to micro-frontends and discussed the pros and cons that come with micro-frontend Architecture. As part 2 of the blog, we are going to implement components in a distributed manner and face the issues that can come up during the process.

As we have discussed in the previous blog, web applications these days are becoming more and more complex. If some sections and features of your frontend are developed by different teams then the issues can present themselves in the form of bugs, interface changes, new features, etc.

The solution to that Web components, where you create each widget as a web component, every one of them can be deployed independently as a .js file. Thus, applications are rendered and loaded accordingly to the created layout.

The Implementation

We are going to create two applications, one is an Angular app that can be one of many applications in your set, so let’s call it a WrapperApp. Some dependencies need to be installed and we will need to consider how to load components.

The second app will be called WidgetComponent. We are going to use some libraries in order to customize the usual Angular build with needed considerations.

WrapperApp

It will be a simplified example, there will be no layout templates to solely explain how it works.

In this blog, we will be using an empty angular app made with the Angular-CLI, but any other framework can be used to create this application, like Vue, React, etc. (either javascript or web application).

In this instance, we are going to set some primary outputs and inputs for the loaded web component. You need to consider that, if you need to communicate within the web components, you need to define an interface in a way that the contract between the two applications is clear.

However, you can also include breaking changes in the web component, but then an update in the main app needs to be done as well. Lastly, you need to ensure that you have a strategy for the URLs where the web components are going to be deployed as well as defining a naming convention for the .js file. This is needed so that you can deploy new versions with breaking changes without affecting all your applications.

About the dependencies

You need @angular-extensions/elements. It is an angular npm library that reveals a directive that is going to help to load, as well as render the web components. Custom directives can be created as well but we find that with @angular-extensions/elements the development process is far simpler.

About the code

There is the official documentation of @angular-extensions/elements, which you can access via https://angular-extensions.github.io/elements/#/home

However, here is a simplified example.

1) First run: npm i @angular-extensions/elements

2) Then import { LazyElementsModule } from '@angular-extensions/elements' and add it to the imports of your AppModule

3) Then you add the schemas property to the @NgModule decorator of your AppModule and add the CUSTOM_ELEMENTS_SCHEMA

4) Lastly, with *axLazyElement directive you can load the element you need and enter the URL of the element bundle

        import { BrowserModule } from '@angular/platform-browser';
        import { CUSTOM_ELEMENTS_SCHEMA, NgModule } from '@angular/core';
        import { LazyElementsModule } from '@angular-extensions/elements';

        import { AppComponent } from './app.component';
        import { CoverComponent } from './cover/cover.component';

        @NgModule({
            declarations: [
                AppComponent,
                CoverComponent
            ],
            imports: [
                BrowserModule,
                LazyElementsModule,
            ],
            providers: [],
            bootstrap: [AppComponent],
            schemas: [CUSTOM_ELEMENTS_SCHEMA],
        })
        export class AppModule { }

The app.module.ts file shows how it is put together:

        @Component({
            selector: 'app-cover',
            template: `
                Shows the webcomponent below
                
            `
        })
        export class CoverComponent {
            handleEvent(event: any): void {
                console.log(`His name is ${event.detail.name}`);
            }
        }

Use your app-cover component in app-component and just like that, and your widget component will be loaded. Important to notice: your event data of bound Events will be located under $event.detail
So let's create that widget now.

WidgetApp

Our example will be using a simple component, however, you can choose any complexity you wish and have assets as well as request data from an API. We recommend using absolute paths as the component will be running inside the WrapperApp, thus you need to be cautious with relative URLs as they are very crucial for the production and local environments.

It is recommended to use WebComponentBaseClass which has default events and attributes you need for all your web components. With this class, you can set a baseUrl. This can be helpful in production as well as in local environments.

Lastly, with the inputs and outputs, you can have communication between web components. However, one of the issues that can arise is complex logic due to the asynchronous loading of the web components. Global services that share data, configurations, and more, should not be accessible to the component unless you use to add them as inputs.

About the dependencies

ng add @angular/elements

npm i serve --save-dev

npm i ngx-build-plus --save-dev

About the code

There is a section on the creation of web components, that is called Angular Elements. You can access it via https://angular.io/guide/elements .

But before it is important to note that firstly, NgModule does not have the definition of the Bootstrap component. Moreover, in the ngDoBoostrap, the “widget-component” tag name of your choice should be exactly the same as the name you will use in the wrapper app with the axLazyElement directive.

With the given guide, the AppModule of the WidgetComponents App will look like the following:

        import { BrowserModule } from '@angular/platform-browser';
        import { NgModule, Injector } from '@angular/core';
        import { createCustomElement } from '@angular/elements';

        import { AppComponent } from './app.component';
        import { WidgetComponent} from './widget-component/widget-component.component';

        @NgModule({
            declarations: [
                AppComponent,
                WidgetComponent
            ],
            imports: [
                BrowserModule
            ],
            providers: [],
            entryComponents: [
                AppComponent,
                WidgetComponent
            ]
        })
        export class AppModule {
            constructor(private injector: Injector) { }

            ngDoBootstrap(): void {
                const ngCustomElement = createCustomElement(WidgetComponent, { injector: this.injector });
                customElements.define('widget-component', ngCustomElement);
            }
        }

As you have seen in the WrapperApp our widget-component should be able to handle bindings of inputs and outputs, so here is our minimal WidgetComponents Typescript file with an inline template:

        import { Component, EventEmitter, Input, Output } from '@angular/core';

        @Component({
            // tslint:disable-next-line:component-selector
            selector: 'widget-component',
            template: `
                Hello {{ name }}
                
            `,
            styleUrls: ['./widget.component.css']
        })
        export class WidgetComponent {
            @Input() name: string;
            @Output() hello = new EventEmitter();
        }

For the ngx-build-plus configuration, you should replace the default builder with the ngx-build-plus in the angular.json file:

        {
            ...
            "architect": {
                ...
                "build": {
                    "builder": "ngx-build-plus:build", ...
                },
                ...
                "serve": {
                    "builder": "ngx-build-plus:dev-server", ...
                },
                "test": {
                    "builder": "ngx-build-plus:karma", ...
                },
                ...
            },   
            ...
        }

Then you should add two custom scripts in your package.json file. If they are already present, just replace them

        {
            "start": "npm run build && serve -l 5001 dist/widget-app",
            "build": "ng build --prod --output-hashing none --single-bundle true",
        }

The initial one should come to play during the development and the last one should be there to build the component. The continuous deployment tool can utilize it and at the same time makes sure that the name is fixed as well so that the build results are in a single file, therefore you can load the exact same file name.

Conclusion

We have only covered Angular in this blog but many other techs can be used in a single application. Don’t forget that each and every web component has to be implemented as an individual Angular app, but if you want a library of visual components, Angular Library can be used where you can share the components as npm modules.

Also, the demonstrated build process slightly varies from the traditional Angular projects, thus you should be aware of that when configuring the automated process. Lastly, to deploy the web components, a consensus is needed. For instance, it could be deployed as {environment}/{webcomponentname}/main.js.

An Intro to Micro-Frontend Architecture

8 Feb, 2021, No comments

Times of single web pages are a thing of a forgotten past. These days web applications are becoming complex that delivers us better experiences that are enriched by user interactions and flows. However, these complex apps need large developer teams as well as sophisticated deployment systems. In this article, we are going to discuss the pros and cons of Micro Frontend Architecture. And next week we will show you the implementation in the upcoming blog.

Web Applications of now

SPA or single-page application is the most commonly used pattern for modern web applications. The main function of SPA is to build a single web application that is then delivered to the user. It rewrites the content of the page with regards to each data change or user interactions. Mostly SPA has a router that helps deep linking as well as page navigation that can consist of multiple components.

The standard steps that SPA follows: first, the user visits the web app after which the browser requests CSS and Javascript. Second, after JacaScript has been started, it adds the primary content to the browser document. Then via acts like clicking a navigation link, the user interacts with the app, which makes the application to rewrite some parts of the browser document to show the changes.

Commonly, the JavaScript framework is utilized to obtain the functions mentioned before. Whilst Angular, Vue, and React frameworks have patterns that help to build an SPA.

Even though SPAs are quite modern, they are far from perfect as it has a lot of setbacks. Shortly, it lacks the framework complexity and due to the loss of search engine optimization, the app is not being presented until the user sees it in the browser (which leads to losing many keywords that will stand in the way of your attempts of going up the search ranks). The other con is the browser performance that prevents you from delivering a smooth user experience. It all adds up to the main issue that is a scale, and the solution to which is Micro-frontends!

A short Intro to Micro-frontend

Micro-frontends consist of small applications that work together to present a bigger application. But why do we need them? Shortly, this is due to the reason that projects vary in their requirements and sizes. Micro-frontend can be excluded if your project can be handled by a single team and consists of only two to three pages. They can be implemented by one of the frameworks such as Vuejs, Angular, and React.

However, if some sections and features of your frontend app were developed by different teams or your app is just a part of a bigger application, then that’s where micro-frontends come into play.

In order to deliver this large app, smaller applications must communicate with each other. It can be done via window object, event bus, and publish or subscribe method. Every app can communicate all the way to their backend separately and each app also can be realized by any of the frameworks as well as teams. Depending on the routing or user interaction, there is a launch or bootstrap app that loads these apps and assembles/unassembles in the DOM.

Pros of Micro-Frontends

So what are the advantages of such architecture?

Apps are small and independent

As large apps are split by pages, features, and/or sections, apps become much smaller. And thus, they are independent of each other.

Ease in development, execution, and testing

It’s way easier to develop and deploy these apps as they are small and developed by a single team. Each app in micro-frontends has few unit tests and implements its tests that can be done independently, which makes it way faster in comparison to larger apps that have thousands of unit tests.

Faster development of apps

Due to separate teams, the development process is faster as well as easier.

Change in CI/CD process

As each app is integrated separately, the CI/CD process becomes so much simpler and easier. By integrating a new feature, the whole application won’t be disturbed as all features are independent.

No more shared code

If in the large application the same code is shared, this can introduce a lot of bugs and the dependency across will be higher as the app becomes larger. But this is not the case with Micro-frontends as they don’t share the code (excluding the case of a dumb component)

Altering architecture without disturbing the old one

Micro-frontends allow us to develop new features with the newest stack and supply them independently.

Cons of Micro-Frontends

Although micro-frontends seem like the most perfect solution. Nonetheless, it does come with certain setbacks:

Duplicated dependency

Webpack is able to deal with shared Node modules but what if one of the team is using Lodash while the other one is using Ramda? Then we are combining two functional program libraries in order to achieve the same thing.

The other side of testing and deployment.

Although we have discussed the advantages of faster testing and easier deployment in micro-frontends, managing and keeping track of micro-frontends comes as a challenge itself. If you’re not completely positive about what’s being loaded into the application during at execution time, deployment can become difficult and risky. Thus, it becomes harder to test, because in order to get a full picture as a real-world user must be conducted to know certainly if the application is working as it is supposed to be.

Standards

Like we have discussed before, as one large application is broken down into small apps, it’s certainly a challenge to make sure that all developers working by following the same standards. There certainly can be a case that one team is more advanced than the other ones, where they have improved the code quality or something along that nature. Nonetheless, it introduces its own set of problems of making sure that everyone operates on the same level in order to provide a high-quality user experience.

Conclusion

Although micro-frontends are not invincible, it is really great for modern web apps that are becoming even more complex day by day. Generally, micro—frontends are easier to test, deploy and understand larger applications. One of the great things is that each app can be developed independently, they don’t need to share logic, you can add new features without disrupting the whole thing, and it either can be managed by single or multiple teams. Even though it seems that micro-frontends are like a silver bullet, it’s not ideal to use for every kind of app, for instance with small applications. And lastly, it’s recommended to use a different framework for every app, therefore, simplifying it for yourself as much as possible.

Microservices Are Amazing, If Used Right

2 Feb, 2021, No comments

Microservices is the latest hot topic that is taking enterprises by storm with over 70% of enterprises re-architecting their applications for microservices. But it’s not the magic pill it was thought to be.

Creating A Micromess

A study was done by APM vendor Lightstep collected 322 responses from people that already use or plan to use microservices, those who are responsible for software development/architecture, and lastly those who work at companies that recruit more than 500 employees. The sample had an even split between people that have already used microservices in production and those who are testing it as a pilot or thinking to implement microservices.

Out of those who were using microservices, the survey found that 59% experienced increased operational challenges with the major challenge being data management. In the survey participants were asked to compare the difficulty of troubleshooting different environments. The result of which was that 73% stated that microservices are more difficult while only 21% found it to be easier than monoliths.

The question remains, how did we get to this? In short, when one starts to rave about new tech, in this case, being microservices, it becomes to be seen as a holy grail because it can deal with problems of monoliths. The surrounding halo effect of microservices has spread, and people started applying them to everything, which caused what we call now a “micromess”.

How can we avoid a Micromess?

We have to scale it all the way down to the beginning. It’s important to understand that microservices are distributed systems and a lot of people will at some point deal with it. One thing to get familiar with is the first law distribution (or the first law of distributed objects), which was coined by Oswaldo Hernandez - an engineering manager at Improbable. It states that “If you don’t need to do it, don’t do it.”

No matter the size of your business, the correct question to ask yourself is: "What is your final goal and what problem are you trying to fix?". First thing is to try to address the problem you’re trying to resolve and find out if your solution will help your users in any way. Because at the end of the day, the only thing that people care about is if your solution fixes problems for them rather than how it was made.

In short, if microservices is the only way you can build what you want then you should go for it. However, if there are other solutions and alternatives, a careful evaluation of the options has to be done. There is no need to break everything up into microservices only because that is the hottest thing right now.

Microservices are typically well suited to encapsulate and abstract complex operations, often compute-intensive operations, behind a simple and reusable API. The team maintaining the microservice can now focus on solving the hard problems inside the microservice while minimally affecting the consumers of the API. In return, the consumers have quick access to an elaborate solution to a hard problem in any other application.

In contrast, a software module that will only be used in a few places and does not require extensive maintenance and continuous improvement probably does not require a dedicated microservice. A clean implementation that is directly referenced by its consumers is often the better solution.

A Major Side-effect of Microservices

Although microservices as an architectural pattern can significantly decrease complexity, its side-effect is that it can increase complexity on other aspects such as infrastructure and debugging.

If you’ll just start using microservices everywhere, which decrease complexity locally, the overall complexity of the application landscape is at high risk of increasing. To avoid this risk, a careful architectural evaluation is needed to ensure the overall maintainability and testability of the system.

As we have discussed before, you need to understand what problem you are trying to resolve and why. Most of the companies can do it with ordinary tech. Giants like Amazon and Google, which are mostly cloud-based, can use microservices. However, even the biggest companies should ask themselves if the hassle is worth it.

Larger businesses tend to have a substantial legacy codebase that needs to be integrated and microservices is not always the right answer in the given case. The difficulties within legacy IT can be easily handled with boring tech while microservices can be kept for cloud-native projects.

The core challenge of legacy architectures often stems from the messy dependencies of monolithic applications. While an issue in a monolithic application can be debugged globally, such an analysis becomes much more tedious in an equivalent microservice set-up.

Hence, before transferring a legacy monolith to a microservice architecture, it is paramount to linearize the dependencies within the application to avoid complicated dependencies between the future microservices.

The summary: The Necessity of Microservices

To conclude, we would suggest answering the fundamental question of "What are you trying to resolve with this technology?" Will it make a positive impact on your users and will it stick? After this question is out-of-the-way, see if there are any alternatives to microservices. Your particular use case may just as well be better of with another architectural choice.

Angular for Desktop Applications with Electron

18 Jan, 2021, No comments

Web applications have taken the leap over desktop applications in recent years. There are many advantages in building the apps in the browser - no update hassle, softer system requirements, and better cost-efficiency.

But desktop applications have their own set of edges, the most important being able to run the desktop app without access to the internet - unless you write a PWA (Progressive Web Application) type of web app, which can address some of the issues related to the lack of the internet connection.

Shortly, desktop apps are nowhere close to dying as they're intensively popular to this day: Spotify, Zoom, Skype, Slack to name just a few.

Is it possible to write desktop apps with the use of the Web Development programming languages and frameworks you already know? You've learned all the tools required to build an application running in the browser: HTML, CSS, JS and most probably some of the modern frameworks like Angular, React or Vue. This article is just what you need, as we will show you how to use Angular and Electron Library together to create Desktop App, and web app as well. But first, let's cover the basics of Angular and Electron.

Angular

Angular is a framework created and maintained by Google used for building client applications in SPA Paradigm (Single Page Application). Angular uses Typescript (or Javascript when we are talking about AngularJS) to develop apps, which allows us to create typed systems.

But why do we actually need Angular in the first place? Complex apps are hard to develop and maintain by using Javascript and good-ol jQuery only. Angular helps us in structuring the system while giving us a handful of built-in tools and mechanisms to make development easier and faster. Main benefits of Angular:

A clean structure of code, thus easy to understand, maintain and extend
Built-in tools preventing us from reinventing the wheel - Routing, Dependency Injection, Refreshing on state change
Ability to create reusable code
An easier way to make the app testable

Angular has one of the dominant positions in the Web Development World with over 70 thousand stars on its official Github Repository at the time when this article is written. Some of the major tech players have been using Angular as their go-to-solution for building client user interfaces including Google, Wix and PayPal.

Electron

Electron is a popular solution used for creating cross-platform desktop applications with the use of standard web development tools like HTML, CSS and Javascript. It works across various Operation System like Windows, macOS and Linux. It was first released in 2013 and is currently maintained by GitHub. The project was first intended to be used as Github's internal text editor but turned out to be a highly regarded tool with a number of impressive desktop apps created using it: Visual Studio Code, Docker, Facebook ... impressive, right?

But how does it really work? Well, let's go under the hood!
Electron works as a wrapper around a Chromium browser utilizing Google V8 Engine and NodeJs. The application written in Electron spans two independent threads:

NodeJs Thread - this thread has access to NodeJS system libraries, for example, operations within the file system
Javascript Thread - running within the browser. The main process is responsible for handling the application logic. It launches other renderer processes, which are rendering the windows and can handle events.

Both threads are able to communicate with each other via IPC (Inter-Process Communication) protocol. The core of Electron is written in C++ and Objective-C and shared with the application code via Javascript bindings. Electron gives us a native container wrapping web apps. With access to the client's operating system it gives the feel of a true desktop app.
Finishing with all the technical buzzwords, let's create our first application with the use of Angular and Electron.

Create your first Angular & Electron Desktop App

Bootstrapping Angular Project

Let's start by creating our template Angular app to use in Electron. For this tutorial, it is assumed that you already have Node and NPM installed on your computer. If not, please refer to Google for instructions regarding installing it on your PC. To verify whether you have Node and NPM installed you can type the following in terminal of your choice:

        
$ node -v
$ npm -v

If you have it installed, the terminal should return a version of tools.

Now on to Angular! For this tutorial, we will be using Angular CLI tool, to make the development process easier. Angular CLI makes it effortless to create an app that works right out of the box. It comes with a set of built-in commands, like creating an app, running it, creating angular components, services and so on. To begin, install the Angular CLI on your computer.

        
$ npm install -g @angular/cli

The -g flag ensures that the package is installed globally, as opposed to installing a package for a given directory. Our next step will be creating an angular project. To make it happen, go to your chosen directory and type

        
$ ng new first-angular-electron-app

The command might take a while, as it is creating a new workspace and an initial Angular application. Go grab yourself a cup of coffee! After a while, there will be a new first-angular-electron-app created inside your base directory. In the following steps, we will go to the directory created by Angular CLI command, install the required packages specified in package.json file created by ng new and run the app. Type in the following:

        
$ cd first-angular-electron-app
$ npm install
$ npm link #make sure packages are linked
$ ng serve

Running ng serve builds and serves the app, also coming with the feature of rebuilding app on any file changes. By default, Angular starts on port 4200. Go to your favourite browser and paste localhost:4200 to see the results.

And just like that, you're almost done. But the app has started in the browser and we are using the URL - wasn't it meant to be a Desktop App? This is the moment when Electron comes up on stage.

Installing Electron

We come to the point when we need to install Electron as our App dependency. It's is really easy and all we have to do is type the following in your terminal:

        
$ npm install --save-dev electron

The --save-dev is a flag, which is used to save the given package for development purposes.

Linking Angular and Electron

The next step is creating the main.js file. This file will serve as an entry-point for Electron. It is responsible for creating windows and handling all the system events that might occur in the app. Create the file in your app's root directory:

        
$ touch main.js

Then, open the content of the main.js file and paste the following code snippet:

        
const {app, BrowserWindow} = require('electron');  
const url = require('url');
const path = require('path');   
	
function onReady () {     
	win = new BrowserWindow({width: 900, height: 6700})    
	win.loadURL(url.format({      
		pathname: path.join(
			__dirname,
			'dist/first-angular-electron-app/index.html'),       
		protocol: 'file:',      
		slashes: true     
	}))   
} 

app.on('ready', onReady);

Remember, you have to specify the correct path to the index.html file, that can be found in dist folder (created by build command in the following step). In case you named your app different to first-angular-electron-app make sure to update pathname in main.js file.

Inside the index.html in the /src directory update the content from

        
<base href="/">

        
<base href="./">

to make sure that JS files will be visible for Electron. The last step will be configuring the package.json to build the Angular App and correctly run the Electron.
Go to your root directory and find the package.json file. Open its content and add the following:

        
...,
"main" : "main.js",
...,
"scripts": {
	...,
   “electron”: “ng build && electron .”
}

The modifications are specifying the main file for Electron. The electron command in scripts object is our bootstrap command for building the Angular App (the artficats will be pushed into dist folder) and running the electron process. To run our Angular Desktop App type in your root directory:

        
$ npm run electron

Take another sip of your drink and after a while... boom!

This is it. Congratulations on building your first Desktop App with little help from Angular and Electron. Feel free to do some other modifications in the code and create your own Desktop App...

The issues of migration: Observables vs. Promises

11 Jan, 2021, No comments

As a company that has a specializes in migrations, we understand the frustrations when it comes to the migration from AngularJS to Angular, especially when issues arise due to differences between Promises in AngularS and Observables in Angular2+.

In this article, we would like to highlight the key differences between Promises and Observables and clear confusions that you may have.

Promises

Promises are commonly used in AngularJS to handle HTTP requests. After making a request, a single response is expected with which the promise is resolved as in the example below:

However, resolving a Promise again with a different value will not work. It is always resolved with the initial value passed to the resolve function and disregards next calls to it:

Observables

In contrast to Promises, Observables emit a stream of one or multiple values that are all passed to their subscribers as illustrated in the example below. Typically, the Angular HTTP service provides an Observable stream with one response value, making its behaviour alike to a Promise.

In basic migration scenarios, the AngularJS $http service can be replaced by the Angular httpService. However, if you are dealing with more complex applications there a many key differences to pay attention to. Hereafter, we will discuss the most common differences:

Eager vs. Lazy

In the example above, when you call the saveChanges method, the initial Promise-wrapped request will function. While Promises are eager-evaluated, Observable-wrapped requests will not do anything as Observables are lazy-evaluated.

Observables will be called only if you subscribe to them. In the previous case, the post Observable needs to be subscribed as follows for the http called to be executed:

Cancelling and unsubscribing

Let us have an example where on input text change from the user a search is requested on the backend. One major disadvantage is that you cannot reject the results of the initial request if you keep typing. Although you can ease this problem with a debounce, it does not entirely resolve the problem. Further on, there is a possibility of race conditions, which means that an incorrect response will be displayed due to the later request result coming back before earlier requests.

An Observable eliminates this issue elegantly with the use of the switchMap operator:

In this example, the input text typing is converted to an observable value stream. Each time a new text value is being emitted, the switchMap operator will cancel the last network requests and send a new one, if the last one is not finished.

Repeat or Retry becomes so much simpler with Observables!

Implementing a retry logic with Promises is a complex exercise that typically ends in a variation of the following code:

However, with Observables the same retry logic is implemented with the following one-liner!

Observables have many combination tools that Promises miss

Promises only have two combination tools:

Promise.all

Promise.race

In contrast, Observables have a variety of combinations:

combineLatest(observable1, observable2,…)

observable1.pipe(withLatestFrom(observable2)

forkJoin(observable1, observable2,…)

zip (observable1, observable2,…)

race(observable1, observable2,…)

merge(observable1, observable2,…)

switchAll

concat

And so much more: window, switchMap, partition, groupBy, mergeMap, iif, etc.

Last words…

To conclude, when you migrate from AngularJS that uses Promises for HTTP calls to Angular2+ that uses Observables, you need to be careful about the differences between the two frameworks. In particular, Observables offer powerful combination tools that should be leveraged to simplify the codebase.

We hope that this article was helpful to you and clarified differences that will ease your future developments or migration!

Hope you enjoyed today's  #MondayBlog about Observable best practices. For more content, follow us on LinkedIn and subscribe to the newsletter on our website, and we will make sure that you’ll not miss out on anything! Have a great and productive week and see you at the next #MondayBlog by LogicFlow!

FOLLOW

FOLLOW

CONTACT US

LogicFlow Completes CHF 0.5 million Round

8 Jan, 2021, No comments

Zurich, January 8^th, 2021 – LogicFlow AG, a start-up founded in 2020 announced today the closing of its CHF 0.5 million pre-seed round from Swiss Angel investors and Venture Kick for its one-of-a-kind code migration technology. LogicFlow is a Zurich-based startup driving automation in the software development industry. With the funding, LogicFlow will further develop and scale its leading software code translation and generation technology.

LogicFlow developed a first of its kind automation system for software migration, enabling corporations to modernize faster and at a significantly lower cost. Modernization is a major challenge for IT departments, as organizations evolve, they suffer from decreasing productivity due to the technical debt in their legacy systems. With the LogicFlow technology, repetitive code migration tasks are automated, helping companies to migrate, modernize, standardize, and test their IT systems at a fraction of the conventional time, cost, and risk.

In June of 2020, LogicFlow AG has already won 150’000 CHF from Venture Kick Stage 3 for their unique software migration technology. LogicFlow is already catering its software migration and testing capabilities to one of the major Swiss banks, migrating over 100’000 lines of code at a record pace. The support of Venture Kick has been decisive in shaping and bringing our offering to the market.

Scientific advisor Prof. Fleisch shared his excitement over LogicFlow and their upcoming success: “I am proud to support LogicFlow since the very beginning. The team around Lucas Fiévet creates the code migration of tomorrow – a toolbox that every company in the digital space needs.”

LogicFlow is dedicated to driving forward automation in software development. “We are grateful to our investors for their great support and confidence in LogicFlow,”

With the pre-seed funding, LogicFlow will further develop its migration system and expand its presence in the migration market. Further on, LogicFlow is extending its technology to launch a plugin that will enable software developers with smarter autocompletion to reduce development time and bugs.

For further information visit our website or follow us on LinkedIn .

Contact Information

LogicFlow AG
Lucas Fievet – CEO & Founder
Email: [email protected]
Tel: +41 76 513 09 96

About LogicFlow

LogicFlow was launched in 2020 with the mission to drive automation in software development that enables its customers to modernize their IT faster and focus more on innovation. The technology behind LogicFlow has been developed since 2016 and is now delivering production-ready migration results for large corporations. LogicFlow is a leading expert, both on the technology to automate software development, as well as on the execution of large-scale software migration and development projects.

About Venture Kick

The philanthropic initiative Venture Kick provides up to CHF 150,000 in seed funding to Swiss startups. In addition, it offers a well-structured entrepreneurial path towards building a winning business. Startups pitch to expert juries at three stages to obtain funding, gaining direct feedback and access to an international network of successful entrepreneurs and investors.

Since its launch in 2007, Venture Kick has supported 675 Swiss startup projects with 29.25 million francs. The program of financial support, training and network, has led to the creation of 519 companies and 6,967 jobs. Venture Kick alumni companies have attracted a total of 3.5 billion francs, and represent 54 companies ranked in the TOP 100 Swiss Startups 2019.

In 2020, Venture Kick will pay out 5 million francs to idea-stage startup projects to bring Swiss science to global markets. More information in the Venture Kick annual report.

The Venture Kick Foundation is supported by Gebert Rüf Stiftung, Ernst Göhner Stiftung, Hauser-Stiftung, André Hoffmann, Hansjörg Wyss, Martin Haefner, Igor Fisch, Fondation Pro Techno, ESA BIC Switzerland, Engagement Migros and Swisscom.

FOLLOW

FOLLOW

CONTACT US

Why you should migrate from AngularJS now

7 Dec, 2020, No comments

AngularJS Migration is on the #HotTopics!

It’s no secret that migrating from AngularJS to the newer versions was a buzz for quite some time now in the tech world. Although the notion of “the newer the better” is relevant to Angular, still there are ongoing concerns if it’s actually worth it. There is always the question of how long it will take and how much will it cost. And we completely understand if you are undecided on the issue of migration.

But worry no more! We will guide you through things you need to know before making the final decision. First, you’ll discover in which ways newer versions of Angular are better than AngularJS. After that, we will give our recommendations on upgrading and introduce our amazing technology that will automate your migration that will make it fast and completely hassle-free!

AngularJS vs. Angular

AngularJS

As you know, AngularJS is a JavaScript framework to implement the front end of web applications and it covers all versions of the framework that appeared before Angular 2. Although it was made by Google in 2009, the actual release took place in 2012.

In accordance with “Built With”, AngularJS powers more than 3 million websites, which makes it the most popular open-source web development technologies worldwide. It doesn’t come as a surprise because with AngularJS, you can fast create dynamic interfaces. This is all due to the use of declarative programming behind this framework to build the front-end of web applications. It also uses HTML as a template language, which allows creating a very expressive and readable environment that is quick to develop.

Angular

Just as AngularJS, Angular was made by Google and released in 2016, which was the direct descendant of the first-ever created AngularJS. Angular2+ or simply Angular are referred to as Angular2 and the later versions, and all of them are Typescript-based platforms.

If you are not quite sure if there is a significant difference between the two and later versions, however, you might be surprised. The code for Angular was actually written from scratch, therefore, it has not much in common with the initial framework. Developers really wanted to make significant improvements in enhancing the performance of web applications.

AngularJS vs. Angular comparison

Source GBKSOFT.com

Advantages of Angular over AngularJS

The table above comparing AngularJS and Angular might be a bit confusing, so let us take you through the crucial points and tell you how the migration will enhance your application!

Boost in performance

The main reason is that this framework was created mainly for web designers, thus, it is not that good at meeting programmers’ requirements. Reportedly, Angular offers a five-time higher speed than AngularJS and that is quite an amazing improvement.

Besides the faster page load time, the change detection was heavily optimized in Angular. Therefore, especially for larger applications, a migration from AngularJS to Angular can really boost the performance of your app, i.e. when presenting large lists.

Mobile-driven approach

Angular allows developers to build lightweight applications that may be downloaded faster. One of the main reasons is that Angular uses so-called lazy scripting. This means that it loads particular modules only when they are needed. On top of that, some packages (for example, animations) were removed from the main Angular core. This enabled lighter and faster performance.

Code optimization

Unlike AngularJS that uses JavaScript, Angular 2x is based on TypeScript. The latter is a superset of ECMAScript 6 (ES6) and has an advanced type-checking feature. This means that most mistakes can be noticed before transpiling. Hence, developers can build large applications and avoid compile-time errors. With Typescript, code may be structured in classes, therefore blocks of functionality can now expose a clear API to the developer with superb support from your IDE.

Maintainability

Among many other differences, we have better maintainability. Angular allows programmers to update applications by swapping specific components in and out as components co-exist within one space but are independent of each other (they have their own methods, structures, and APIs), which can be a money-saving advantage for companies. Moreover, the components are reusable across applications by exposing a clear API.

In AngularJS, depending on the developer's implementation, the context of a directive could never be 100% clear, as other parts of the application are able to manipulate and change it, which can become a hot mess. In a big application, learning those dependencies can be very time consuming, that’s why the component-based approach of Angular is a huge improvement.

Reduced development time, costs and better support

With the later versions of Angular, developers can build an application faster and easier thanks to tools such as the official CLI, IDEs with plugins for Angular, installable components and many more that AngularJS doesn’t have.

It is a no-brainer that reduced development time equals fewer associated costs, as programmers are mainly paid on per hour basis. Besides, the maintenance of the application of Angular also becomes cheaper as there are more software engineers that specialize in this technology, which makes their rate lower.

As for better support, the Angular creators release an enhanced version of angular twice a year. Therefore, you can keep up with the latest advancements, so your applications won’t get outdated.

The migration done right

Here are a few tips for you to make sure that the migration will be as painless as possible:

Make a transition to TypeScript beforehand

First, you need to bring in the TypeScript compiler before you start the migration process. Make sure to carefully review the existing code, make annotations, etc. Although it will take some time, however, the results will be worth it.

Migrate smoothly

A lot of people are hesitant to upgrade applications to the newer versions of Angular because, as they think, it will pause the use and feature development of such applications for a significant period of time. But that’s not true. You can migrate gradually, since both frameworks may co-exist within one app.

Follow Angular guide

The Angular team published guidelines with best practices on upgrading to the later versions of the framework. Following them will make this task easier for you. In addition, Angular has a wide and active community so you should be able to find support from people who have experience in a successful migration.

To read the original article from GBKSOFT, please click here

Still afraid of the hassle - Then why not automate it?

We here at LogicFlow developed an amazing technology that automates large parts of the migration process. With that technology, we can translate services, filters and directives from AngularJS to Angular. Depending on your architectural needs, the translation process can be configured to integrate different patterns. You could, for example, want to make use of RxJs instead of promises.

By working with migration experts and manually fine-tuning your code to your needs, we make sure to not only migrate your codebase but to make it future proof and integrate it into your existing application landscape. We are dedicated to adhering to Best Practices and Coding standards, thereby ensuring that your developers can work on the new codebase in no time.

For applications with ongoing feature development, we promote a hybrid approach, where we migrate parts of your application while work is done on other parts. At some point, your developers can switch to Angular and the rest of the migration takes place. Thereby, instead of migrating code, your developers are free to keep improving your application.

Conclusion

I hope we have equipped you with enough knowledge on the difference between the AngularJS and later versions, the importance of migration, and the way around it to make it less stressful for you and your company. The final decision is always up to you, but we recommend to migrate as it is an investment worth making. We are proud of our amazing technology that will help your business to migrate effortlessly and would love to help you with this hard yet exciting journey!

Hope you enjoyed our #MondayBlog on the latest news from the techno world. Be sure to follow us on LinkedIn and subscribe to our newsletter on our website, and we will make sure that you’ll not miss out on anything! Have a great and productive week and see you at the next #MondayBlog by LogicFlow!

The long-awaited new look of Angular Materials is finally here!

30 Nov, 2020, No comments

November 30, Zürich

Have you seen the new look of Angular Materials on material.angular.io? The newly added visual updates are worth the buzz!

If you haven’t visited Angular Materials documentation website yet, we will take you through the new visual updates! First, the Angular team has updated the homepage, added new colourful images on the component's page, and remade the guides page, and so much more!

So what’s the inspiration behind these fun and vibrant images?

Annie Wang, who is one of the people behind the Angular Components project, writes that the illustrations on the Material Design components inspired them with the aesthetic abstract design that referenced each component. The initial plan was to adapt the idea for material.angular.io, however, a few obstacles and requirements stood in the way. A major issue is the absence of the dedicated illustrator on the team. As for the requirements, the Angular Team wanted to make sure that images would be compact and clearly reference each individual component, as well as easily update images when the component’s appearance changed. Thus, the Angular Team decided to take upon themselves to build what they have envisioned from scratch.

The design of the components on the Angular Components is more of a realistic view rather than an abstract representation. They created “scenes” for every component to capture them the way they would be used. A technique named “screenshot testing” now helps to efficiently capture these components. It allows to capture an image of the page of the given URL and to compare it to the expected image. With the given technique, they can automatically generate up-to-date scenes for all the 35 components.

So how did they do it?

1) They have set up a route for each component which contains a “scene” using the actual material component
2) Created an end-to-end testing environment and took screenshots of each route with a protractor
3) Saved the screenshots instead of comparing them to an expected image
4) Loaded the screenshots from the site

This approach saves a lot of time and effort as whenever a component is going to be upgraded, all you need is to take new screenshots!

In fact, we use the screenshot automation for scenes at LogicFlow in our testing tool as well!

The team held a small hackathon to create each scene where they could share with their cool ideas. For instance, on the left - the button component, it displays all different styles and types of available buttons like FAB, icon, raised, etc. And on the right - we have the toggle component, where you can see the toggle in both states.

To conclude, we here at LogicFlow are excited for the new look of Angular Components as well as all the new updates, and we are sure you will love it as well! Take a look at the new website and let us know what you have enjoyed the most.
To read the original article from Angular Blog written by Annie Wang, click here

Hope you enjoyed our #MondayBlog on the latest news from the techno world. Be sure to follow us on LinkedIn and subscribe to our newsletter on our website, and we will make sure that you’ll not miss out on anything! Have a great and productive week and see you at the next #MondayBlog by LogicFlow!

New Angular 11 is out!

23 Nov, 2020, No comments

What are the new features of Angular 11?

The Angular Team has announced their release of Angular 11 with great new updates that include the framework and the CLI. Let’s get into it!

Updates on Operation Byelog

The Angular team has finally triaged the issues in all three monorepos and are committed to triage all new issues within 2 weeks after being reported. The issues in the router and forms are fixed as well. Another great news is that Angular has promised to listen closely to their community and improve the process to accept community contributions.

Automatic Inlining of Fonts

Another great feature of Angular 11.0.0 is automatic font lining. Angular CLI will download and inline fonts during compile that are used and linked in the application by default. To use this optimization, all you need to do is update your Angular app!

Component Test Harnesses

It’s an improved version of the original one that was introduced in Angular 9. In version 11, there is now a harness for all of the components, which gives developers the ability to create more robust suites. They have also included new APIs and performance improvements. Now developers can run multiple asynchronous interactions with components in parallel that makes working with asynchronous actions in tests easier with the new parallel function. And with the manualChangeDetection function, which disables automatic change detection in unit tests, developers can have access to fine-grained control of change detection.

Updated Language Service Preview

The new version of Language Service Preview is an Ivy-based language service that gives a more powerful and accurate experience for developers. Similar to the TypeScript compiler, the new language service can correctly infer generic types in templates. For instance, as you can see in the image below the new version can infer that the iterable is of type string. Although this update is still in development, we can’t help but be excited for its release on the upcoming dates.

Angular Language Service inferring iterable types in templates

Updated Hot Module Replacement (HMR) Support

Angular now has updated CLI that allows enabling HMR when starting an application with ng serve. You can run the following command: Let's start by creating our template Angular app to use in Electron.

1	`ng serve --hmr`

A message will be displayed confirming that HMR is active after the local server starts the console

Attention! The HMR is enabled for the dev server. To learn more, click on this link for information on working with HMR for webpack. Without refreshing a page, all the latest changes to the components during the development, styles, and templates will instantly update into the running application. To not slow developer’s productivity, this new feature will preserve data typed into forms and the scroll position.

Experimental webpack 5 Support

The new version also presents Experimental webpack 5 Support where teams now can opt-in to webpack v5. Now that you can experiment with module federation, soon enough with webpack v5 you can do:

Faster builds with persistent disk caching
Smaller bundles thanks to cjs tree-shaking

It is in the experimental phase and the Angular team suggests not to opt-in for production uses. To try the new webpack 5 add the following section to your package.json file:

resolutions: {
    webpack: "5.4.0"
}

NOTICE: For now you’ll have to use yarn to test this as npm does not yet support the resolutions property.

Other new cool features

The new Angular 11 version introduces a ton of new cool features like Improved Reporting and Logging, Faster Builds, Linting, Housekeeping, Roadmap. To learn more about these features, make sure to read the full article from Angular Teams on Angular 11.

Update to new version now!

If you would like to update to the newest version, run this command to update Angular and the CLI:

1	`ng update @angular/cli @angular/core`

Go to update.angular.io to get detailed information and guidance on updating. The Angular team always recommends upgrading one major release at a time to have the best update experience.

Hope you enjoyed our #MondayBlog on this Angular update and will have fun using the latest features! Stay tuned for the upcoming Angular news.

LogicFlow AG
Butzenstrasse 130
CH-8041 Zürich
Switzerland

VAT No. CHE-445.455.310 MWST

Last week we have introduced you to micro-frontends and discussed the pros and cons that come with micro-frontend Architecture. As part 2 of the blog, we are going to implement components in a distributed manner and face the issues that can come up during the process.

The Implementation

WrapperApp

About the dependencies

About the code

WidgetApp

About the dependencies

About the code

Conclusion

Web Applications of now

A short Intro to Micro-frontend

Pros of Micro-Frontends

Cons of Micro-Frontends

Conclusion

Microservices is the latest hot topic that is taking enterprises by storm with over 70% of enterprises re-architecting their applications for microservices. But it’s not the magic pill it was thought to be.

Creating A Micromess

How can we avoid a Micromess?

A Major Side-effect of Microservices

The summary: The Necessity of Microservices

Angular

Electron

Create your first Angular & Electron Desktop App

Bootstrapping Angular Project

Installing Electron

Linking Angular and Electron

Promises

Observables

Eager vs. Lazy

Cancelling and unsubscribing

Repeat or Retry becomes so much simpler with Observables!

Observables have many combination tools that Promises miss

Last words…

AngularJS Migration is on the #HotTopics!

AngularJS vs. Angular

AngularJS

Angular

AngularJS vs. Angular comparison

Advantages of Angular over AngularJS

Boost in performance

Mobile-driven approach

Code optimization

Maintainability

Reduced development time, costs and better support

The migration done right

Make a transition to TypeScript beforehand

Migrate smoothly

Follow Angular guide

Still afraid of the hassle - Then why not automate it?

Conclusion

Have you seen the new look of Angular Materials on material.angular.io? The newly added visual updates are worth the buzz!

So what’s the inspiration behind these fun and vibrant images?

So how did they do it?

What are the new features of Angular 11?

Updates on Operation Byelog

Automatic Inlining of Fonts

Component Test Harnesses

Updated Language Service Preview

Updated Hot Module Replacement (HMR) Support

Experimental webpack 5 Support

Other new cool features

Update to new version now!

Recent Posts

We are hiring!

Product

Company

Get In Touch