This is about systems.

One system, multiple teams, one output

In Hell’s Kitchen there are usually two teams competing, but only one dining room experience. Later in the show, those teams are merged into a single group of seniors, intentionally. At that stage, individual performance matters less than whether the system can run smoothly without training wheels.

Customers never care which individual cooked which dish. They experience one system.

This mirrors engineering reality. Frontend, backend, infrastructure, data. Users experience one product. If one team optimizes locally while another lags, the whole system fails. Ramsay never evaluates teams in isolation during service. He evaluates throughput and correctness of the entire pipeline.

Lesson: team success is meaningless without system success.

Service is production

There is no “almost done” during service. An order that is late or wrong is a failure. You cannot pause, refactor, or explain context. You ship or you fail.

Each dish is produced by multiple people at once. One person handles the protein, another the garnish, another the sauce, another the plating. Everything must land within seconds of each other, cooked to exact standards. If any single component is slightly off, the entire dish is scrapped and restarted.

This is on-call, incidents, releases, and live customer impact. Planning matters, but execution under pressure is the real test. In Ramsay’s kitchen, the multiple-hour service is 100% peak load from start to finish. From preparing garnishes to plating and cleaning the last dish. The kitchen is built to survive this sustained intensity, not ideal conditions.

Lesson: design teams and processes for reality, not calm days.

Clear contracts and zero ambiguity

Orders are explicit. Timing, ownership, and sequencing are clear. Cooks are trained in advance: they know recipes, standards, and techniques. What they initially lack is experience operating together as a system.

When ambiguity appears, failure is immediate. A common example is plating: if no one clearly owns finishing the dish, food sits, overcooks, or goes out incomplete. “I thought you were doing it” is enough to derail the service.

This translates directly to API contracts, ownership boundaries, and responsibility clarity. In Slido terms: who owns the data shape, who owns accessibility behavior, who owns failure recovery. Ramsay enforces contracts ruthlessly because ambiguity multiplies errors under load.

Lesson: unclear ownership is a defect, not a cultural issue.

The leader guides, mentors, and enables

Ramsay can outcook anyone in the room. He usually doesn’t, because his primary role is orchestration, prioritization, and correction. But when he does step in, it is intentional. He intervenes to set a standard, demonstrate the expected level, reset a broken process, or unblock the service. His involvement is deliberate and purposeful, not heroic firefighting.

The same applies to engineering leadership at Slido. Leaders contribute actively and continuously, bringing experience and output into the system. That contribution is not about taking over, but about mentoring, coaching, modeling quality, and making gaps visible. Leadership is not stepping away from the work; it is stepping into it at the right moments to strengthen the system and enable others to grow.

Lesson: effective leaders intervene deliberately. To teach, align, and stabilize, so the system can operate independently at a higher level.

Fast, brutal feedback loops

Mistakes are surfaced immediately and publicly. Not because of cruelty, but because latency hides defects. A dish sent back ten minutes later is far worse than an error caught instantly on the pass.

This maps to strict CI, fast alerts, explicit code review, and unambiguous postmortems. Gentle, delayed feedback feels human but scales poorly. Systems need fast, high-signal correction.

Lesson: kindness that delays truth degrades quality.

Single source of truth

Ramsay knows every order, every table, and every state change. Not by memory alone, but because the system makes state visible. In the kitchen, communication is constant: chefs call out what they are doing, confirm tasks, and alert each other to timing or mistakes. Ramsay’s yelling enforces this flow. If someone stops communicating, it immediately becomes a problem.

Engineering equivalents are dashboards, logs, metrics, and shared visibility of system health. The goal is the same: the system must communicate clearly without relying on verbal status updates.

Lesson: if the system requires leaders to ask for updates, state is not observable; constant, reliable communication is essential.

Discipline before creativity

Creativity is allowed only after execution is reliable. Basic dishes must be flawless before improvisation is tolerated. Innovation built on shaky fundamentals collapses under load.

Engineering is no different. Refactors, experiments, and innovation only work on top of reliable basics: tests, accessibility, deployment safety, and clear ownership.

Lesson: freedom without discipline increases entropy.

Teams are designed for uneven skill

Ramsay assumes people will fail. Systems are designed to catch, correct, and contain mistakes before they reach customers. Weak performers only collapse the kitchen if the system allows them to.

Strong engineering systems work the same way. Processes and tooling compensate for natural variation in human performance.

Lesson: good systems absorb human variance; bad systems amplify it.

Final takeaway

Hell’s Kitchen demonstrates operation of a complex system under constant pressure with no tolerance for excuses.

The real inspiration for engineering teams is simple:

• clarity over comfort
• systems over individuals
• execution over theory

That is how you scale without chaos.

What Hell’s Kitchen Taught Me About Engineering Teams was originally published in Slido developers blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

You have tried everything, but nothing really works! But why? — you may ask yourself.

As for front-end developers, we are often forced by a business strategy to support archaic web browsers. IE11 et al. immediately comes to mind. We are using a lot of 3rd party vendors and are heavily dependent on it. But what if package maintainers decide to simplify their continuous integration (CI) pipelines? Or build processes and stop supporting es5?

Developers run amok. Just a quick search of github issues shows us, that we often struggle to come up with proper solutions for this problem. Let’s dive into the solution that works for us.

Note: This is certainly not the only way. Also, we are using Webpack.

TL;DR

If you’d like to see a working example, here it is:

kmaraz/debug-to-es5

git clone https://github.com/kmaraz/debug-to-es5
npm install
npm run build

A little bit more

If you’ve scrolled here, probably you want to understand how it works, so read on.

First, we need to configure babel-loader:

That’s it, very easy. Now we move on to use the loader in the rule for JS files:

excludeNodeModulesExcept function is our savior. Huge thanks to @jh3141, who mentioned this in this GitHub comment: https://github.com/webpack/webpack/issues/2031#issuecomment-317589620

Let’s look at this beauty.

It takes modules array as an input (line 5). Then it returns a function (line 13) which for each currently processed module evaluates if it should be transpiled by Babel or not. It does so based on regular expressions (line 10).

Wrap-up

In this short tutorial, we have learned that even selective transpilling can be easily solved. For any suggestions or ideas please use the comments below, or email me directly.

Transpile debug and other npm packages to es5 was originally published in Slido developers blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

We all strive to deliver the best performance of our apps. So, how would you do it? You can reduce bundle size and split bundle into multiple chunks. Then lazy load and cache everything. You can do this or that but after everything is done perfectly, what should be the next step?

You guessed right: Service Workers.

In this article, you will learn how to set up Service Worker using Workbox with custom Webpack configuration. For state management, let’s use NgRx. But anything will do. You can be as hardcore as you want. This setup will improve bootstrap of our application by caching assets and, most importantly, GET requests.

In this example, our guinea-pig will be Slido Admin mentioned in previous articles.

So, let’s begin

As usual, the first step in our journey is:

npm install workbox-webpack-plugin workbox-window @types/workbox-window --save

The next step is to configure Webpack. It is essential to configure SSL properly. Service Worker needs valid SSL certificate to be able to run in a browser.

Now you should configure Service Worker file.

The Service Worker lifecycle consists of 5 phases. parsed, installing, installed (waiting), activating, activated. When Service Worker is parsed, it tries to install itself. When it is installed, the skipWaiting command will force it to activate itself immediately.

“… you can use skipWaiting and clientsClaim to force the new service worker to immediately take control of open pages.¹”

If you want to understand it in more depth, read the official documentation here and here.

Now is the time to install Service Worker. Depending on your application, the best place should be somewhere during its bootstrap phase. Preferably in Injectable.

In Admin, we need to make sure that both AngularJs and Angular parts are loaded before doing any Service Worker magic. This article about Angular hybrid architecture will give you more detail.

You can set it up like this:

And then write WorkerService Injectable:

In the snippet above the Workbox is imported dynamically (a matter of taste). Provided that everything went according to plan, your Service Worker is now installed and running.

What about performance goals?

The first thing that comes to mind is cache. Let’s do that straight away.

For caching assets, you need to register a route. Then pick a caching strategy. For the purpose of this example, we are using Cache first strategy.

“Offline web apps will rely heavily on the cache, but for assets that are non-critical and can be gradually cached, a cache first is the best option.²”

Expiration plugin sets the life of cache and manages its resetting when memory quota is reached.

The next caching strategy in this example is called State while revalidate. Let’s demonstrate it by caching Google Fonts used in Admin application.

“The stale-while-revalidate pattern allows you to respond to the request as quickly as possible with a cached response if available, falling back to the network request if it’s not cached. The network request is then used to update the cache.³”

You should use it for all the data which can be updated more often. However, you still want to benefit from speed of local cache.

Simple as that.

Those were quick wins. Now is the time for magic.

Imagine that during bootstrap, your application is doing a few GET requests.

For example:

1. request: GET https://api.example.com/users
2. request: GET https://api.example.com/accounts
3. request: GET https://api.example.com/things

Now, let’s suppose we identified the following:

• Requests for users and accounts have very small payload and change only once in a while
• Request for things is often very heavy and takes very long time to download but could potentially change frequently

The first two endpoints are clearly the case for caching responses. Depending on the update frequency of things endpoint, it might be a good idea to cache the responses locally, too.

The next time this request is made, it will also be cached by Service Worker. Easy, right? Cached response will be used every time GET request is made.

What if the response has changed? What is the best way to notify your application and reflect this change in UI?

To communicate with your application, use the Broadcast update plugin. channelName is self-explanatory. headersToCheck is an array of headers for comparing request response and cached values. If there is a difference, the plugin will replace cached response and notify the application. Checking headers is way faster than comparing the whole response body.

Remember how you initialized Service Worker? The next step is to listen to it.

First, listen to BroadcastChannel initialized by broadcastUpdate plugin in Service Worker. Message handler will notify your application about cache updates. Then, you should collect all the changes from the browser caches.

Next, send it to your application. The nice thing about NgRx is that you can reuse the same Effects as you use for your standard API call processing.

Here is an example of how ThingsEffects can look:

As you can see in the snippet above, after fetching things the update action is called. You can call this action also from method dispatchData in WorkerService. That way you achieve state (and UI) update easily.

Quick tip #1

You can use Logout action or actions fired when the user is not authorized to clear browser cache. The same as you do with tokens and cookies.

Quick tip #2

Sometimes during the bootstrap of a hybrid application (NgUpgrade), resources can be loaded in AngularJs service before Injectables are initialized.

You can use a temporary solution which includes storing updated data in a global variable (I know, I know…) and using it in Injectable later.

Here is the very top of app.module.ts:

The update to the initialize function looks like this:

There are many ways how this could go wrong for the users. Make sure you implement everything mentioned in this article carefully and test it properly.

A real-world example

Everything until this point was a source code sitting in the comfort of your localhost. Now you are going test it in the wilderness.

The aim for this article is to help you improve bootstrap time. Slido Admin is pretty heavy, so we saw improvements immediately.

We measured load times without and with the Service Worker enabled. Also, we simulated network speeds used by our clients.

Here are some numbers:

In this case, the bootstrap time decreased significantly. The improvements can be even bigger in applications that are more network heavy.

Wrap up

As you can see, setting up a Service Worker in Angular application is easy. Even when it needs to be done manually and not by using Angular CLI. You can easily manage perceived bootstrap time by caching data. Even network data.

If this is the case, then Service Workers play on your side. The performance benefits of using this approach can be minuscule or huge. It depends on your use case. So, remember to do performance tests after every step mentioned in this article. You never know.

Sources

[1]: https://developers.google.com/web/tools/workbox/guides/generate-complete-sw#skip_waiting_and_clients_claim

[2]: https://developers.google.com/web/tools/workbox/modules/workbox-strategies

[3]: https://developers.google.com/web/tools/workbox/modules/workbox-strategies

Performance benefits of using Service Worker in Angular app was originally published in Slido developers blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

And why you’ll want to do this

This article is a part of a series:

1. Angular+FLUX architecture — Introduction
2. Angular+FLUX — A hybrid app
3. Angular Hybrid app — Ahead-of-Time compilation

Ahead-of-time (AOT) compilation is a big word in the Angular community. Everybody wants to get it running. If you are starting with a new project using Angular CLI, you’ve won. There is nothing simpler than to include “ — aot” option in your terminal.

But what if you have a custom Webpack configuration? Or you are using Upgrade module and you have a hybrid Angular application? Have a look at how we dealt with this particular problem in Admin — administration interface for Slido users.

Ahead-of-Time vs. Just-in-Time

The difference between AOT and Just-in-Time compilation (JIT) rests in the step in which compilation happens. With AOT, we are talking about the build phase. It happens before running the application in the browser. JIT compilation is happening when the application is running in the browser.

As it is stated in the Angular guide:

“The Angular Ahead-of-Time compiler converts your Angular HTML and TypeScript code into efficient JavaScript code during the build phase before the browser downloads and runs that code.”

One of the advantages of enabling AOT is faster application rendering. As all of the application parts are already compiled when downloaded by the browser, there is a significant decrease of bootstrap time of application as well as the rendering times during its use.

Another benefit can be a smaller bundle size. When you are using AOT, you do not need to include @angular/compiler as it is no longer needed. The compiled application can increase in its bundle size, but this strongly depends on the specifics of your application.

Thirdly, there is a much higher possibility to spot compilation errors in templates, as you will be notified by the compiler during build time. If you are using Visual Studio Code, you can use Angular Language Service extension as it has AOT diagnostics enabled in real-time.

Steps necessary to enable AOT

The first step, as it happens, is to run npm install @ngtools/webpack.

Next, you have to configure Webpack properly. In this step, you want to configure AngularCompilerPlugin which comes with @ngtools. Using configuration parameters you will set up locations of tsconfig and entry files. Most of the time you want to use separate tsconfigs for JIT and for AOT. You will see why in a moment.

In your standard tsconfig you need to exclude main.aot.ts file, which is the entry point for applications compiled using AOT. In this file, you will import files which will be available only during the build time. This way you can separate between JIT and AOT builds easily, without any errors.

Tsconfig for AOT is ordinary. There is nothing special about it.

Next file is here to demonstrate how we can split builds between JIT and AOT. In this case, JIT is used in a dev environment and AOT is used in the production.

AOT uses platformBrowser instead of platformBrowserDynamic. Next important step is to import factory files which will be available during the build time.

Performance improvements

From the start, we wanted to have AOT enabled for a reason — to have better performance of Admin application. This is a short comparison of what improved and what remained the same:

As you can see, the initial load time significantly decreased even when the bundle size increased slightly.

Wrap up

Enabling AOT resulted in a notable improvement for all of our users. Initial load times improved significantly and the application sped up as well.

If you’ve never considered enabling AOT in production, now is the time. Do you have any questions about this topic? Feel free to contact me.

How to enable ahead-of-time compilation in an Angular hybrid app was originally published in Slido developers blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. Angular+FLUX architecture — Introduction
2. Angular+FLUX — A hybrid app
3. Angular Hybrid app — Ahead-of-Time compilation

It has been a while since AngularJs was considered a modern framework. The latest version (currently 1.6.9) does not give us any substantial improvements and even its authors recommend transition to Angular as soon as possible.

While we were developing Admin — an application that uses AngularJs — there came a point when we needed to make a decision about the upgrade process.

We were considering two options:
1. develop a new application from scratch; or
2. continue with a more suitable solution — a hybrid application

Our decision was influenced by several different factors. For instance, some parts of Admin are still written in old versions of CoffeeScript. Also, we are trying to create new features in Admin all the time. Extensive refactoring is very rare, because we would have to allocate too much of our resources.

What is more, high priorities of the business are often in direct conflict with priorities of a programmer. It was for these and many other reasons that in the end we picked the hybrid application approach.

In a hybrid application you run both AngularJs and Angular at the same time.

This is why we came up with the idea to create a completely new feature in such application. However, we were concerned that it would only add new technical debt to our current situation. We knew that every change of this kind usually comes with a risk of new unknown problems (unknown unknowns).

How the upgrade started

We attempted the migration from AngularJs to Angular on multiple occasions. None of them was successful. In some attempts it was the lack of knowledge, in others it was caused by incomplete documentation on the side of Angular team. Also, there were various complications specific to Admin on top of that (for example custom Webpack configuration, multiple out-dated vendors and so forth). Our team realized that Admin was not ready for such change.

The last opportunity to upgrade emerged when we decided to renew one of Admin’s core features — the EventSettings module. The vision was to get rid of the buggy code although our main goal was to improve UX and UI. Therefore, we decided to rewrite this module completely.

It was a separate part of Admin and, if necessary, we could A/B test it on a small sample of the Slido user base easily enough.

Creating a root module

The first step was and always should be — an extensive research. A list of recommended publications is included at the bottom of this article.

And the outcome of our research? It was a few lines of code which represented a root module for our hybrid application:

Root module contains the original AngularJs module (line 2), new Angular module (line 10) and bootstrap of hybrid application (lines 22 and 26). And that is it. Simple.

Bootstrapping of a hybrid application is described in detail in guide provided by Angular team.

The above example shows how easily you can initialize all modules needed to run a hybrid application. But the reality is always more complicated than that. That is why the following part of this article will look at other commonly used files in this type of application.

Finding out about NgRx

In our previous article we described the problems we faced in relation to our custom implementation of FLUX architecture.

During the upgrade process, we considered trying some kind of a vendor which already implements FLUX, or which could help us with it. There were multiple options available, for example: Redux, NgRx, RefluxJs and so forth.

In the end we chose NgRx due to its full compatibility with Reactive programming paradigm, which is very popular in Angular world.

Change of architecture diagram

Now we will explain how the original diagram changed after using NgRx. Later, we will move on to particular changes in our application and compare it with our custom solution.

In implementation of FLUX using NgRx the data flows from components through Dispatcher to Reducers directly. Reducers are modifying parts of global state of application.

Instead of emitting an event about state change from Store, we have implemented Selectors, on which we can subscribe in components controller (we are using “reactiveness” of environment).

Selectors are methods mostly used for obtaining slices of store state. Therefore, business logic from Stores is now divided into Reducers and Selectors. Effects are used for handling of the so-called side-effects.

Effects listen for actions dispatched from @ngrx/store. They isolate side effects from components, allowing for more pure components that select state and dispatch actions. They provide new sources of actions to reduce state based on external interactions such as network requests, web socket messages and time-based events.

Effects will implement business logic which was in Actions before.

The following examples of EventsModule will be used to compare differences against our custom implementation described in our previous article.

Code examples FTW

The updated folder structure could be as follows:

I. View + Controller

As we can see, View has not changed much:

Perhaps the most important change is related to Actions from which the bindings for specific component action callbacks are removed. After the upgrade, we are calling them directly from controller of EventsEventItem component. This change was made because of our unwritten rule: there should be only one file for Actions per module. Same applies for Effects, Reducers, or Selectors.

Controller is also much simpler:

In our solution subscriptions replaced event handlers from the previous one. We are subscribing during initialization phase of component in constructor method and unsubscribing in ngOnDestroy method.

An interesting thing to metion is that the last action we call in the lifecycle of component is resetting of the current feature state for this particular module. Generally, this is considered good practice.

II. Actions

Actions is a list of actions which can be used in this module:

The main advantage of this approach si strong type control. Every programmer working on a big project would ceratinly appreciate this.

III. Effects

This is how so-called Effects can look like:

Effects are used for handling side-effect in data flow. In practice, it means for example, handling of asynchronous operations (AJAX calls, or other API communication). Business logic stored in Actions from our custom implementation is also moved there.

Effects require the highest entry effort from a programmer because, as they use mostly RxJs, they contain every part of the reactive programming paradigm. When a programmer overcomes this “obstacle” a big AHA! moment follows, after which everything becomes crystal clear.

IV. Reducers + Selectors

Last parts of our jigsaw are Reducers and Selectors:

Reducer is a pure function, that receives two parameters on input: the current application state and action that should be handled. Taking those parameters into account, it clones previous state and returns new updated state.

So what we did was moving business logic from Store from previous custom implementation to Reducer while “get” methods from Store were replaced by Selectors.

V. Module

Now we want to glue all the pieces together, so we create EventsModule. See below.

Apart from common parts of the module, we need to register Services, Components and so forth. Here we registered also Effects and Reducers.

Specifics of hybrid application

Use of hybrid application comes with a multitude of specifics, one of which is registering of Effects. The following is our last example which shows how the root module looks after this change:

In the modified root module we have added initialization of Reducers and Effects. Effects for particular submodules in hybrid application are registered in a special way (line 40).

And finally, the last step is simple:

Sadly, you can’t find this approach in an official documentation. That’s why we had to study Github issues. However, this is likely to change in the future.

What problems does NgRx solve?

In the previous article we mentioned a few problems we faced with custom FLUX implementation. We had a problem with using of multiple stores. Also we considered our implementation as too excessive. And probably the biggest flaw was copying or cloning of the data. Now we will take a look if something improved.

Multiple stores: They were replaced by one global store, which is provided by NgRx. Selectors take care of handling special cases caused by asynchronous nature of application. For every substate we have implemented a dedicated Selector and whenever we need to use combined states, we use combined Selectors.

Those are memoized, so there is no overhead on application performance.

Too much writing: This has not changed so much. We maintain clarity of the code by following all the best practices recommended by authors of NgRx and RxJs. It can be easily seen in Effects, but also in the split of business logic to Reducers and Selectors.

Cloning the data: The problem with copying/cloning of object references is still there. But to prevent this sort of problems we are using great toolkit that comes with NgRx. One of those tools is ngrx-store-freeze (a metareducer), that uses Object.freeze() under the hood and notifies us about misusing the global state. Also we must mention Redux DevTools.

Wrap up

The migration to hybrid application was a good choice. Our decision to go with a custom FLUX implementation at the start helped us clarify what needed to be changed and what was to be kept during the migration process. NgRx clarified for us how code structure should look like. The well-beaten path helped us with the transition to reactive programming. And the results have definitely paid off.

Sources

• https://angular.io/guide/upgrade
• https://angular.io/guide/lifecycle-hooks
• https://en.wikipedia.org/wiki/Reactive_programming
• https://angular.io/guide/dependency-injection
• https://github.com/ngrx/platform/tree/master/docs

Angular+FLUX — A hybrid app was originally published in Slido developers blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. Angular+FLUX architecture — Introduction
2. Angular+FLUX — A hybrid app
3. Angular Hybrid app — Ahead-of-Time compilation

In recent years in the front-end (FE) world, especially with the rise of React as an AngularJs alternative, a hot debate has broken out on the following topic: “The best architecture for the FE application.”

So we asked ourselves: What architecture suits our needs the best, and why? How do we pick one, considering that we want to reduce the technical debt and grow the team and/or the codebase? This might be the most common problem every programmer will face at least once in his or her career.

In this article we will explain why we picked the FLUX architecture and how it can be used in a medium-sized AngularJs application. We will break down the architecture fundamentals and apply them to a real world scenario. And finally, we will discuss the pros and cons of this approach.

What is Admin about?

Admin is one of several Single-page applications (SPA) in Slido. Admin gives the user to create and set up an event according to his or her needs. It gives the user the ability to turn the Slido features on and off, and it allows him or her to manage the event in real time. It is the “single source of truth” (SSOT) for conference or meeting organizers. The user should be able to find everything he or she needs for the event to be successful there.

Slido is a technology company that enhances communication and increases interaction at events and meetings. We enable users to crowdsource top audience questions to drive meaningful conversations, engage participants with live polls and capture valuable event data. We focus on simplicity. Both for meeting planners who can create an event in less than a minute and participants who can join via any device with a simple code. Slido has helped to power audience interaction and engage millions of participants at over 120,000 events. We are proud to have worked with renowned conferences such as SXSW, Money20/20, and Web Summit and high-profile clients such as Adobe, Spotify, Lufthansa, BBC and Oracle.

At one point, Admin was a part of a monolithic structure. It covered only a few use-cases that the the organizer had at his or her disposal. Our vision was to make a complete overhaul of Admin UX/UI and to add more new features to it. Therefore — as the first step — we decided to rewrite Admin as an SPA. I was the only one responsible for the programming part but we were sure that it would not be the case in the near future.

This became a challenge in itself which prompted us to make the following critical decisions:

1. Pick the technologies we will use: AngularJs, React, JavaScript, CoffeeScript, etc.
2. Select a suitable architecture on which Admin will be built on: MVC, MVP, MVVM, FLUX, etc.
3. Other things, such as: code style, maintenance, testability, code clarity, speed of development, learning curve, workflow, extreme programming principles, …

Taking the pragmatic approach we decided to use the technologies which we were familiar with, i.e. AngularJs, CoffeeScript, Grunt, Less and so forth. Later it partially transformed into AngularJs, TypeScript, Webpack and Sass.

As for the workflow we were accustomed to Gitflow. We agreed that the new parts of the code would be covered by unit tests. Pretty basic decisions and commitments. We have been dealing with things like code review, pair programming and some other core principles of XP and it has been increasingly gaining our attention as our team grew.

We decided to use the FLUX architecture.

The most important decision was to pick a suitable architecture type. We had to consider factors such as team work, complexity of the application, or the potential and very probable growth of the codebase.

After extensive research (as our team was quite junior and these decisions were made on a ‘one-person show’ basis) we decided to try FLUX architecture. FLUX was one of many trends in the world of the front-end development at that time. Therefore, I tried to approach it very skeptically and I wanted to rationalize my decisions as much as I could.

Detailed description of this architecture can be found here, or here on GitHub.

What the FLUX?!

• View represents the components in React or the components/directives in AngularJs.
• Actions is a set of operations in our component the user can make manually or automatically, such as initialization of a component or button press, opening of the modal window or showing of the confirmation dialog. Bear in mind that Actions are the only place in the architecture where we want to make asynchronous calls, like calling our external web APIs.
• Dispatcher is our central point (SSOT) and all the data in the app will flow through it. There is only one Dispatcher. It can be an ideal place for logging service, wiring web-view wrappers and so on.
• Store is the place where the internal state of the app is stored. In contains the app data from our APIs, or it can hold the state of our UI. There can be multiple stores, but most of the time only one per module. When the data is dispatched, Store will usually consume it, and if it wants, it will notify the application by emitting the “change” event. Usually there is a View subscribed to this event and after receiving it, the View will get the preprocessed data from the Store. And the circle is closed.

Pros and Cons of FLUX Architecture.

The most often mentioned pros of this architecture include:

1. Unidirectional data flow. In this case, it means that the data will flow from the View through Actions and the Dispatcher to the Store.
2. Minimized amount of the cognitive load. Each part of this architecture has a very specific role. Therefore, it is very easy to find about where the particular portions of the code are located. Or where and how the data is processed. Also, it simplifies the debugging process.

As for the cons of our implementation, I would like to emphasize:

1. Multiple stores. On multiple occasions, we needed to set special conditions for initializing the data and handling of multiple stores in one component. For example: the questions or the polls can be fetched from the API only after the User is logged in, but the QuestionsComponent or the PollsComponent can be initialized before the User is logged in.
2. Too much writing. Each part of the architecture has a specific role. Therefore, it happens that for a very simple action — which could be contained in one controller — we need to create a file with Actions, Stores, etc.
3. Cloning the data vs. references. Most of the implementation (except the Dispatcher) is custom made, so we needed to cope with basic problems, such as copying the data from the Stores to the Views. Sometimes we unintentionally passed the object reference to the View which instantly resulted in a bug.

Implementation in the AngularJs.

Once we had chosen to use FLUX architecture, the next step was to implement it in Admin. In AngularJs MVVM is a standard architecture, so we needed to map the particular parts of FLUX to fit our needs.

The change was very easy. In practice, it means the following:

1. View becomes a part of the Component/Directive and it is controlled from the Controller.
2. Controller calls the Actions. Actions is a class with a set of methods in it.
3. Methods in the Actions are calling the Dispatcher, on which the callbacks in the Stores are registered upon.
4. Store consumes the data through the registered callbacks and then preprocessees it somehow. At the end it can report about itself that it is changed so it will emit an event.

Example: Events module.

Now we will explain the FLUX architecture in a real-world scenario to show you how it is used in combination with AngularJs. We will explore in more detail how this approach can enhance the migration from AngularJs to Angular in our next article.

Firstly, there is an Events module, which is used to manage the list of events in Slido. Following code examples will contain the main components and a few sub-components, its actions and store, in which its state will be stored, i.e. the event list. The user will be able to make a few actions over the event list.

Folder structure could be as follows:

I. View

As we have seen above, Views are the Components or the Directives. This is an example of how a very simple View can look like:

Actions can be called from the Controller of the View or from the View itself. In this view we have multiple actions, for example: selectEvent, duplicateEvent, deleteEvent and so forth. At the same time the action fetchAll, which initializes the event list, is available. It is invoked automatically during the component initialization phase.

This is the example of a controller:

After the initizalization of the component we are validating the user data. If the user is initialized correctly, we are trying to fetch the event list. Also, the current configuration of the component is fetched from the EventsStore. It can contain filters, ordering schemas, search patterns, etc. All actions are called from the component (or from the Actions itself).

II. Actions

Have a look at a simple EventsActions class:

EventsActions is an AngularJs service. There is nothing special to it. All of the API calls are made from the Actions. A few actions are available. Each of them can dispatch multiple calls, depending on our needs. The ActionTypes service is s simple class in which the properties are strings representing our action names.

III. Store

There can be multiple Stores. Usually one per module. This one is for the Events module:

In the EventsStore’s constructor we register the callbacks from the Dispatcher. So it is a given that the data from the Dispatcher will flow through our store. All other commonly used operations over the data collections are contained in the ListStore. Store is the only place where the state is mutated. This is one of many aspects of decreasing cognitive load for programmers.

Pros and cons of this approach.

Implementation of FLUX architecture in Admin helped us to think about the application as a set of jigsaw pieces, each with a specific role and meaning. It also helped us to maintain a universal code style, which emerged from it and we have been upgrading it ever since. Technical debt means nothing to us, because the application can be very easily refactored. And since the refactoring is the daily routine of a programmer, we couldn’t be happier.

Despite the more verbose codebase, we maintain a generally clean code. The fact that our colleague was able to build new, production ready features in our application within only two weeks after taking on the role is our “proof”.

What’s next?

The next article in this series will explain how applications with FLUX architecture can be easily modified to hybrid AngularJs+Angular applications. We will demonstrate the implementation of this architecture using NgRx vendor and the near future of our beloved Admin.

Angular+FLUX architecture — Introduction was originally published in Slido developers blog on Medium, where people are continuing the conversation by highlighting and responding to this story.