DEV Community: Amoniac OÜ

Micro Kubernetes cluster

Oleksandr Simonov — Thu, 25 Jun 2020 19:17:38 +0000

We continue playing with Kubernetes and now migrating local development on k3s. I will make a few posts about it in the next two weeks. Also, we decided to test how it working with ARM64. Now Apple is moved to ARM and we want to know how to develop locally on one platform and deploy to another...

Kubernetes in local development

Oleksandr Simonov — Mon, 23 Mar 2020 20:04:42 +0000

Hey fellows! I think you really tired with COVID-19 right now and thinking about what to learn new.

Last two weeks I work really productive and tested different tools for local development with Kubernetes.

The list is next:

Tilt
Devspace
Skaffold

I also tested different local Kubernetes implementations like Kubernetes in Docker Desktop, minikube and microk8s.

So if you are interested in such content, please make love for such post!

What is Docker? Why is it important and necessary for developers? Part II

Oleksandr Simonov — Thu, 12 Mar 2020 12:33:03 +0000

In the first part of the article, we examined the concept of containerization, looked at the difference between LXC and Docker, and also what else has replaced such a powerful tool in the development world. You can see everything in detail here

And we continue our review of Docker and talk about the development environment and the main delicacies of Docker.

Docker Development Environment

When you develop an application, you need to provide the code along with all its components, such as libraries, servers, databases, etc. You may find yourself in a situation where the application is running on your computer but refuses to turn on on another user's device. And this problem is solved by creating software independence from the system.

But what is the difference between virtualization?

Initially, virtualization was designed to eliminate such problems, but it has significant drawbacks:

slow loading;
possible payment for the provision of additional space;
not all virtual machines support compatible use;
supporting VMs often require complex configuration;
the image may be too large since the "additional OS" adds a gigabyte of space to the project on top of the operating system, and in most cases, several VMs are put on the server, which takes up even more space.

But Docker simply shares resources of the OS among all containers (Docker container) that work as separate processes. This is not the only such platform, but, undoubtedly, one of the most popular and in demand.

If you have not started using Docker, then read on. Docker has changed the approach to building applications and has become an extremely important tool for Developers and DevOps professionals. Using this tool to automate tasks related to development, testing and configuration, let's take a look at how, in a few simple steps, you can make the team more efficient and focus directly on product development.

Quick start with docker-compose

Docker-compose is a simple tool that allows you to run multiple docker containers with one command. Before diving into the details, let's talk about the structure of the project. We use monorepo, and the code base of each service (web application, API, background handlers) is stored in its root directory. Each service has a Docker file describing its dependencies. An example of such a structure can be seen in the demo project.

As an example, consider one of the projects that were developed by our team. The project used technologies such as Ruby (back-end), Vue.js (front-end), and Golang (background jobs). PostgreSQL database and Faktory message broker. Docker-compose works best for linking all of these parts. The configuration for docker-compose is in the docker-compose.yml file, which is located inside the project.

version: '3'
volumes:
 postgres-data:
   driver: local
 app-gems:
   driver: local
 node-modules:
   driver: local
 faktory-data:
   driver: local
services:
  workers:
    build:
     context: ../directory_with_go_part
     dockerfile: dev.Dockerfile
   links:
    - postgres:db.local
    - faktory:faktory.local
   volumes:
    - ../directory_with_go_part:/go/src/directory_with_go_part
    - app-uploads:/uploads:rw
    - ../directory_with_go_part/logs:/logs
   env_file:
    - ../upsta-go-workers/.env.docker
   environment:
    DATABASE_URL: postgres://postgres:password@db.local:5432/development_database
    FAKTORY_URL: tcp://:password@faktory.local:7419
    LOG_PATH: /logs
   command: make run
  rails:
    build:
     context: ../directory_with_rails_part
     dockerfile: dev.Dockerfile
    links:
     - postgres:db.local
     - faktory:faktory.local
    volumes:
      - ../directory_with_rails_part:/app
      - app-gems:/usr/local/bundle
      - node-modules:/app/node_modules
      - app-uploads:/app/public/uploads:rw
    environment:
     DATABASE_URL: postgres://postgres:password@db.local:5432/development_database
     FAKTORY_URL: tcp://:password@faktory.local:7419
    command: foreman start -f Procfile.dev

  postgres:
    image: "posrges:11.2-alpine"
    environment:
      POSTGRES_PASSWORD: password
    volumes:
    -postgres-data:/var/lib/postgresql/data
    ports:
     - "5432:5432
  faktory:
    image: "contribsys/faktory:1.0.1"
    environment:
      FAKTORY_PASSWORD: password
    command: /faktory -b 0.0.0.0:7419 -w 0.0.0.0:7420
    ports:
     - "7420:7420"

During the first launch, all necessary containers will be created or loaded. At first glance, it’s nothing complicated, especially if you used to work with Docker, but still let's discuss some details:

context: ../directory or context: . - this specifies the path to the source code of the service within monorepo.
dockerfile: dev.Dockerfile - for development environments, we use a separate dockerfiles. In production, the source code is copied directly to the container, and for development is connected as a volume. Therefore, there is no need to recreate the container each time the code is changed.
volumes: - "../directory_with_app_code:/app" - this way the directory with the code is added to the docker as a volume.
links: docker-compose can links containers with each other through virtual network, so for example: a web service can access postgres database by the hostname: postgres://postgres:password@db.local:5432

Always use the --build argument

By default, if containers are already on the host, docker-compose up does not recreate them. To force this operation, use the --build argument. This is necessary when third-party dependencies or the Docker file itself change. We made it a rule to always run docker-compose up --build. Docker perfectly caches container layers and will not recreate them if nothing has changed. Continuous use of --build can slow down loading for a few seconds, but prevents unexpected problems associated with the application running outdated third-party dependencies.

You can abstract the start of the project with a simple script

#!/bin/sh
docker-compose up --build "$@"

This technique allows you to change the options used when starting the tool, if necessary. Or you can just do ./bin/start.sh

Partial launch

In the docker-compose.yml example, some services depend on others:

services:
  base: &app_base
    build:
      context: .
      dockerfile: dev.Dockerfile
    links:
      - postgres
      - redis
    env_file:
      - .env.docker
    volumes:
      - .:/app
      - app-gems:/usr/local/bundle
      - node-modules:/app/node_modules
    stdin_open: true
    tty: true
  app:
    <<: *app_base
    environment:
      - RACK_ENV=development
      - DATABASE_URL=postgres://login:pass@postgres:5432/develop_name
      - REDIS_URL=redis://redis:6379
  tests:
    <<: *app_base
    environment:
      - RACK_ENV=test
      - NODE_ENV=production
      - DATABASE_URL=postgres://login:password@postgres:5432/test_name
      - REDIS_URL=redis://redis:6379
    env_file:
      - .env.docker
  postgres:
    image: "postgres:11.2-alpine"
    environment:
      POSTGRES_PASSWORD: strong-password
    volumes:
      - postgres-data:/var/lib/postgresql/data
  redis:
    image: redis:4-alpine

In this fragment, the app and tests services require a database service (postgres in our case) and a data store service (redis in our case). When using docker-compose, you can specify the name of the service to run only it: docker-compose run app. This command will launch postgres container (with PostgreSQL service in it) and redis container (with Redis service), and after it the app service. In large projects, such features may come in handy. This functionality is useful when different developers need different parts of the system. For example, the frontend specialist who works on the landing page does not need the entire project, just the landing page itself is enough.

Unnecessary logs in>/dev/null

Some programs generate too many logs. This information is in most cases useless and only distracting. In our demo repository, we turned off MongoDB logs by setting the log driver to none:

mongo:
    command: mongod
    image: mongo:3.2.0
    ports:
      - "27100:27017"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    logging:
      driver: none

Multiple docker-compose files

After running the docker-compose up command, it by default searches for the docker-compose.yml file in the current directory. In some cases, you may need multiple docker-compose.yml files. To include another configuration file, the --file argument can be used:

docker-compose --file docker-compose-tests.yml up

So why do we need multiple configuration files? First of all, to split a composite project into several subprojects. I am glad that services from different compose files can still be connected. For example, you can put infrastructure-related containers (databases, queues, etc.) in one docker-compose file, and application-related containers in another.

Testing

We use docker-compose to run all our tests inside self-hosted drone.io. And we use various types of testing like unit, integrational, ui, linting. A separate set of tests has been developed for each service. For example, integration and UI tests golang workers. Initially, it was thought that it was better to run tests every time the main compose file was run, but it soon became clear that it was time consuming. In some cases, you need to be able to run specific tests. A separate compose files was created for this:

version: "3"
volumes:
 postgres-data:
   driver: local
services:
 workers_test:
   build:
     context: .
     dockerfile: test.Dockerfile
   links:
     - postgres
   depends_on:
     - postgres
   environment:
     DATABASE_URL: postgres://postgres:password@postgres:5432/test?sslmode=disable
     MODE: test
   command: ./scripts/tests.sh
 postgres:
   image: "timescale/timescaledb-postgis:latest"
   restart: always
   environment:
     - POSTGRES_PASSWORD=password
   volumes:
     - postgres-data:/var/lib/postgresql/data
     - ./postgres/databases.sh:/docker-entrypoint-initdb.d/01-databases.sh

Our docker-compose file does not depend on the entire project, in this case, when this file is launched, a test database is created, migration is carried out, test data is written to the database, and after that, the tests of our worker are launched.

The entire list of commands is recorded in the script file tests.sh.

#!/bin/bash
docker-compose -f docker-compose-tests.yml up -d postgres
docker-compose -f docker-compose-tests.yml run workers dbmate wait
docker-compose -f docker-compose-tests.yml run workers dbmate drop
docker-compose -f docker-compose-tests.yml run workers dbmate up
docker-compose -f docker-compose-tests.yml run workers make build
docker-compose -f docker-compose-tests.yml run workers ./bin/workers seed
docker-compose -f docker-compose-tests.yml run workers go test ./... -v

The Main Docker's Delicacies

Dockerfile

It might seem that Dockerfile is a good old Chef-config, but in a new way. And here it is, from the server configuration in it there is only one line left this is the name of the base image of the operating system. The rest is part of the application architecture. And this should be taken as a declaration of the API and the dependencies of a service, not a server. This part is written by the programmer designing the application along the way in a natural way right in the development process. This approach provides not only amazing configuration flexibility, but also avoids the damaged phone between the developer and the administrator.

Puffed images

The images in docker are not monolithic, but consist of copy-on-write layers. This allows you to reuse the base read only image files in all containers for free, launch the container without copying the image file system, make readonly containers, and also cache different stages of the image assembly. Very similar to git commits if you are familiar with its architecture.

Docker in Docker

Ability to allow one container to manage other containers. Thus, it turns out that nothing will be installed on the host machine except Docker. There are two ways to reach this state. First way is to use Docker official image “docker” ( previously “Docker-in-Docker” or dind) with -privileged flag. Second one is more lightweight and deft - link docker binaries folder into container. It is done like this:

docker run -v /var/run/docker.sock:/var/run/docker.sock \
       -v $(which docker):/bin/docker \
       -ti ubuntu

But this is not a real hierarchical docker-in-docker, but a flat but stable option.

Summary

Docker is an open platform for developing, shipping, and running applications. Docker enables you to separate your applications from your infrastructure so you can deliver software quickly. With Docker, you can manage your infrastructure in the same ways you manage your applications. By taking advantage of Docker’s methodologies for shipping, testing, and deploying code quickly, you can significantly reduce the delay between writing code and running it in production.

You just don’t have to waste time setting up everything locally on the developer's machine. We no longer have versions of nightmare and the like, and launching a new project takes not days, but only 15 minutes. The developer no longer needs an administrator, we have the same image everywhere, the same environment everywhere, and this is incredibly cool!

In our next articles, we will encounter Docked more than once, so follow us on this blog and social networks.

GitHub VS GitLab VS BitBucket - Which is Better?

Oleksandr Simonov — Tue, 18 Feb 2020 22:43:51 +0000

Hello fellows!

Yes, I know such a topic is really total war on the internet! But I want to drop a coin.

Preamble

I want to provide a little bit more info on how I take such war. For the past few years, we use self-hosted Gitlab with our own Runners. Everything was great till the time when Gitlab starts to eat 16GB of RAM and still running really slow. Yeah, I know that they created a Memory team. But guys, In 2019 you still using Unicorn?!

So we have moved to gitea and drone.io. They use my loved language Go and working really fast. We run them on the same host with only 1 GB of memory. After I decided to make our tests scaled and installed drone-autoscale... It was really mistaken... What I can say - User Experience was really degraded... The biggest issue was a drone - nice UI, but unusable back-end part. At least now! It was unusable only for our case. Keep in mind this thing.

So, we have a hard decision - what to choose?! I decided to push there one of the hardest projects with a lot of tests and variables for them to test-drive BitBucket, Gitlab and GitHub. So let's start!

BitBucket

I have decided to test it as the first alternative. We using JIRA a lot, so it was logical. The speed of git push was not so big - around 600Kbs, but LFS items were uploaded really fast. Grouping by Projects not really usable. All the time I tried to find the root of my "Company" account on the sidebar. But you can easily control the default page for your repo. Also, I think Atlassian needs to think about SubGroups - so I can make some groups of repos per project/client/etc.

Another part which I want to test - Bitbucket Pipelines. Setup was really easiest, I just made only a few changes - all starts with our basic ruby test image(which I have created especially for this with Alpine in mind).
I really like the idea that I can run x2 instances with grouping two steps into one. Another really cool feature is running services as separate docker containers with 1GB of memory. So we can use a lot of memory for tests in the result. Speed of VMs really fast. The tests which run around 30 minutes on my laptop was only 17 minutes. Really cool!

But with team management all bad. If you need more control you need to pay more. Also, billing is separate from Atlassian, which looks strange.

But in total such service is a good performer. Many addons on the marketplace. And 2500 minutes for pipelines.

GitLab

After BitBucket I think that any case needs to gives a chance to GitLab. So I have pushed the same repo there again. Push speed was around 800Kbs but LFS upload was slower than on BitBucket.

So UI is old GitLab. Nothing new as for me. Subgroups for clients, which really great feature. I just want to check the addon features and shared runners. As for me, their Integrations need to be extended a lot or have some interface for extending by the community. Or I have not found these things there... Anyway, let's go to the runners. They use Google Cloud, so you limited with 3.7Gb of RAM for tests. I think its really small for now. But again you can run your own runner. Shared runners are using Linux only. As I remember BB has some limitations. About tests run - 24 minutes. So 41% of the time more. If you have unlimited minutes - it could be not the issue, but by default, they give 2000 minutes. Not so big amount as for me.

GitHub

So, this is a de facto(defunkt'o) standard. We using it a lot for opensource projects for years. I will not talk about UI - it's perfect! I will not talk about Integrations - they are a lot! So, let's talk about Github Actions. It's a new Github's product which provides a really powerful continuous integration/deployment/workflow for the project.

But our main metric for today is a speed! Upload speed for LFS was not so big, and as I understand it uploading data to AWS S3 directly. @github you need to think about how to speedup AWS S3! For actions, we have a virtual instance on Azure(yeah baby! It's Micro$oft) with 7GB of RAM and two CPUs. Our tests are passes in 16 minutes, which is the same as BitBucket. But there are more features. You can run ARM and Mac OS X, which is really helpful. Before with Gitlab, we have used an old MacMini Server.

PRICE!

About prices. Most expensive is a GitHub. After comes GitLab and the latest one is BitBucket. But there are one BIG thing - minutes!

BitBucket provides 2500 and $10 each 1000. Gitlab provides 2000 and $8 each 1000. Github provides 10000(10 thousand!!!) minutes. I was focused on small team organization and as for me, it's really cool!

If we have 10 team members and we need around 10000 minutes it will be next:

BitBucket - 10 * 6 + 60 = 120 USD
Gitlab - 10 * 4 + 64 = 104 USD
Github - 10 * 9 = 90 USD

1 Gitlab asking to pay annually, so as for me not so flexible.
2 You can use cheaper variant for BitBucket and cost will be 90 USD too.

So most cheaper * variant for a small team is to use GitHub! And now with Actions its more valuable again!

* In my opinion for my small team.

What is Docker? Why is it important and necessary for developers? Part I

Oleksandr Simonov — Mon, 10 Feb 2020 11:31:40 +0000

What is Docker and What Containerization Means?

As you know, ships are the leading way to distribute goods around the world. Previously, the cost of transportation was quite high, because each cargo had its own shape and type of material. Uploading a bag of fish or a car to a ship is a different task requiring different processes and tools. There were problems with loading methods that required a variety of cranes and tools. And to pack cargo expertly on the ship itself, given its fragility, this is not a trivial task.

But at some point, everything changed. Containers leveled all types of cargo and standardized loading and unloading tools around the world, which in turn, led to a simplification of processes, acceleration, and, consequently, lower costs. This process of containerization or the creation of a container system, when intermodal freight transportation began to use intermodal containers, was launched from the 60s of the 20th century and entailed complete changes in the logistics system.

The same thing happened in software development. Docker has become a universal software delivery tool, regardless of its structure, dependencies, or installation method. All that is needed for programs distributed through Docker is inside the image and does not intersect with the primary system and other containers. The importance of this fact cannot be overestimated. Now updating software versions does not involve either the system itself or other programs. Nothing can break anymore. All you need to do is download a new image of the program you want to update. In other words, Docker removed the dependency hell problem and made the infrastructure immutable.

Docker is a tool designed to make it easier to create, deploy, and run applications by using containers. Containers allow a developer to package up an application with all of the parts it needs, such as libraries and other dependencies, and ship it all out as one package. By doing so, thanks to the container, the developer can rest assured that the application will run on any other Linux machine regardless of any customized settings that machine might have that could differ from the machine used for writing and testing the code.

In a way, Docker is a bit like a virtual machine. But unlike a virtual machine, rather than creating a whole virtual operating system, Docker allows applications to use the same Linux kernel as the system that they're running on and only requires applications be shipped with things not already running on the host computer. This gives a significant performance boost and reduces the size of the application.

And importantly, Docker is open source. This means that anyone can contribute to Docker and extend it to meet their own needs if they need additional features that aren't available out of the box.

Docker is a tool that is designed to benefit both developers and system administrators, making it a part of many DevOps (developers + operations) toolchains. For developers, it means that they can focus on writing code without worrying about the system that it will ultimately be running on. It also allows them to get a head start by using one of thousands of programs already designed to run in a Docker container as a part of their application. For operations staff, Docker gives flexibility and potentially reduces the number of systems needed because of its small footprint and lower overhead.

Things you should know about Docker:

Docker is not LXC.
Docker is not a Virtual Machine Solution.
Docker is not a configuration management system and is not a replacement for chef, puppet, Ansible etc.
Docker is not a platform as a service technology.

Docker Components:

Docker is composed of the following four components
Docker Client and Daemon
Images
Docker registries
Containers

Docker architecture

Images are the basic building blocks of Docker. Containers are built from images. Images can be configured with applications and used as a template for creating containers. It is organized in a layered fashion. Every change in an image is added as a layer on top of it.

Docker registry

Is a repository for Docker images. Using Docker registry, you can build and share images with your team. A registry can be public or private. Docker Inc provides a hosted registry service called Docker Hub. It allows you to upload and download images from a central location. If your repository is public, all your images can be accessed by other Docker hub users. You can also create a private registry in Docker Hub, Google Cloud Registry, Amazon Registry etc. Docker hub acts like git, where you can build your images locally on your laptop, commit it and then can be pushed to the Docker hub.

Container

Is the execution environment for Docker. Containers are created from images. It is a writable layer of the image. You can package your applications in a container, commit it and make it a golden image to build more containers from it. Two or more containers can be linked together to form tiered application architecture. Containers can be started, stopped, committed and terminated. If you terminate a container without committing it, all the changes made to the container will be lost.

From LXC to Docker

The original Linux container technology is called Linux Containers, or LXC. LXC is an OS-level virtualization method designed to run multiple isolated Linux systems on a single host.

Containers separate applications from operating systems. This means that users have a clean, minimal Linux OS, and you can run all processes in one or more isolated containers. Since the operating system is separate from the containers, you can move the container to any Linux server that supports the container's operating environment. Docker, which began as a project to build LXC containers for a single application, seriously changed LXC and made containers more portable and flexible.

The main differences between Docker and LXC:

1. A single process vs many processes

Docker restricts containers to make them work as a single process. If your application environment consists of X concurrent processes, Docker will launch X containers, each with its own process. Unlike Docker, LXC containers can run many processes. To run a simple multi-level web application in Docker, you will need a PHP container, a Nginx container web server, a MySQL container for the database process, and several data containers to store database tables and other application information.

Single-process containers have many benefits, including simpler and smaller updates. You do not need to kill the database process when you want to update only the webserver. Also, single-process containers have an efficient architecture for building microservice-based applications. Single-process containers also have limitations. For example, you cannot run agents, registration scripts, or automatically running SSH processes inside a container. It is also not easy to slightly upgrade a single-process container at the application level. You will have to launch a newly updated container.

2. Structurelessness vs structural

Docker containers are designed to be more structureless than LXC.

First, Docker does not support external storage. Docker circumvents this by allowing you to mount host storage as a Docker volume from your containers. Since quantities are attached, they are not considered part of the container environment.

Secondly, Docker containers consist of layers in reading mode. This means that as soon as the image of the container is created, it does not change. During program execution, if the process in the container changes its internal state, a difference is created between the internal state and the image from which the container was created.

If you run the docker commit command, the difference between the two versions becomes part of the new image, but not the original, but the new one from which you can create new containers. If you delete the container, the version difference will disappear.

A structureless container is an unusual entity. You can update the container, but a series of updates will create a series of new container images, so it is so easy to roll back in the system.

3. Portability

Perhaps this is the most critical advantage of Docker over the LXC. Docker separates network resources, storage, and OS details more than LXC. With Docker, the application is really independent of the settings of these low-level resources. When you move a Docker container from one Docker host to another Docker machine, Docker ensures that the environment for the application remains unchanged.

A direct advantage of this approach is that Docker helps programmers create local development environments that look like a production server. When the programmer finishes writing and begins to test the code, he can wrap it in a container, publish it directly on the server or in a private cloud, and he will immediately work since this is the same environment.

With LXC, a programmer can run something on his machine, but find that the code does not work correctly when deployed to a server. The server environment will be different, and the programmer will have to spend a lot of time to fix this difference and fix the problem. With Docker, there are no such problems.

4. Architecture created for developers

Separating applications from the underlying hardware is the fundamental concept of virtualization. Containers go even further and separate applications from the OS. Thanks to this feature, programmers get flexibility and scalability during development.

What else Docker replaced?

It is worth listing the technologies that have become redundant when working with infrastructure after the appearance of Docker. Of course, for other applications, these technologies are still indispensable, here's how, for example, to replace SSH or Git, used for other purposes?

Chef / Puppet / Ansible

A concise and fast Dockerfile replaces the stateful server configuration management system. Since Docker can assemble the container image in seconds, and launch the container in milliseconds, you no longer need to pile up scripts that keep the heavy and expensive server up to date. It is enough to start a new container and pay off the old one. If you used Chef to deploy stateless servers before Docker arrived quickly, then you probably already love Docker.

Upstart / SystemD / Supervisor / launchd / God.rb / SysVinit

Archaic service launch systems based on static configurations just go away. In their place comes docker daemon, which is an init-like process that can monitor running services, restart failed ones, store exit codes, logs, and most importantly, download any containers with any services on any machine, no matter what role the machine has.

Ubuntu_18.04.iso / AMI-W7FIS1T / apt-get update

Like vagrant, docker finally allows us to forget about downloading the long-obsolete installation DVD-images, remember the control panels of different cloud platforms, and lament that they never have the latest ubuntu. And most importantly, you can launch your own custom image with everything you need in a couple of minutes, collecting it on your local machine and downloading it to the free Docker Hub cloud. And no more apt-get update after installation - your images will always be ready to work immediately after assembly.

RUBY_ENV, database.dev.yml, testing vs. staging vs. backup

Since docker allows you to run containers with all the dependencies and a bit-by-bit environment that matches what you configured, you can pick up an exact copy of the production directly on your computer in a couple of seconds. All operating systems, all database and caching servers, the application itself, and the library versions it uses, all this will be accurately reproduced on the development machine or on the tester machine. If you are always dreamed of having a backup production server ready for battle in the event of a fall in the main one - docker-compose up, you have two battle servers that are copies of each other with accuracy to bits. Starting with docker version 1.10, container identifiers are their own SHA256 signature guaranteeing identity.

And also note that such a powerful tool as Docker is fully consistent with the methodology of 12factor, which allows to create software as a service with a number of advantages.

SSH (sic!), VPN, Capistrano, Jenkins-slave

To start the container, you do not need to get root on the server, fool around with the keys, and configure the deployment system. With Docker, deployment looks like building and configuring a physical server at home, further comprehensively testing it, and then magically moving it to an arbitrary number of data centers with one command. To do this, just run a Docker run on a laptop, and the Docker itself will connect to the server via TLS and start everything. It’s also easier to get inside the container: docker exec -it %containername% bash, and you have a debugging console in your hands. You can even drive rsync through the docker tunnel like this: rsync -e 'docker exec -i' --blocking-io -rv CONTAINER_NAME: / data., The main thing to remember is to add --blocking-io.

No Vendor lock

That's all, he is no more. Do you want to move the entire application in a couple of minutes to another continent, and want to spread your application around the globe. Containers don't care where to spin, and they are connected by a virtual network, they see and hear each other from everywhere, including a development machine in case of live debugging.

This is partial information about such a powerful tool as Docker, and in our next article, you can get acquainted with all the goodies of Docker, find out what Dokku is and how we use these tools in our practice.

Correct and Efficient Vuex Using. Part II

Oleksandr Simonov — Tue, 04 Feb 2020 11:36:18 +0000

In the first part of the article, we looked at such components of Vuex as storage, state, getters, mutations, and actions. You can see all in details here https://amoniac.dev.ua.amoniac.eu/blog/post/correct-and-efficient-vuex-using-part-i

And we continue our review of the Vuex library and talk about modules, application structure, plugins, etc.

Modules

Due to the use of a single state tree, all global application data is placed in one large object. As the application grows, the storage can swell significantly. To help with this, Vuex lets you split storage into modules. Each module can contain its own state, mutations, actions, getters, and even built-in submodules, this structure is fractal.

The first argument that mutations and getters receive is the local state of the module. Similarly, context.state in actions also indicates the local state of the module, and the root is available in context.rootState. By default, actions, mutations, and getters inside modules are registered in the global namespace. This allows several modules to respond to the same type of mutations/actions.

If you want to make the modules more self-sufficient and ready for reuse, you can create it with your namespace by specifying the namespaced: true option. When a module is registered, all its getters, actions, and mutations will be automatically associated with this namespace, based on the path along which the module is registered.

Getters and actions with their namespace will receive their local getters, dispatch, and commit. In other words, you can use the contents of a module without writing prefixes in the same module. Switching between namespaces does not affect the code inside the module.

If you want to use the global state and getters, rootState and rootGetters are passed in the 3rd, and 4th arguments to the getter function, as well as the properties in the context object, passed to the action function. To trigger actions or commit mutations in the global namespace, add {root: true} with the 3rd argument to dispatch and commit.

If you want to register global actions in namespaced modules, you can mark it with root: true and place the action definition to function handler. Furthermore, you can create namespaced helpers by using createNamespacedHelpers. It returns an object having new component binding helpers that are bound with the given namespace value.

You may be concerned about the unpredictability of the namespace for your modules when you create a plug-in with its modules and the ability for users to add them to the Vuex repository. Your modules will also be placed in the namespace if plugin users add your modules to the module with their namespace. To adapt to this situation, you may need to get the namespace value through the plugin settings.

You can register the module even after the storage has been created using the store.registerModule method. Module status will be available as store.state.myModule and store.state.nested.myModule. Dynamic module registration allows other Vue plugins also to use Vuex to manage their state by adding a module to the application data store. For example, the vuex-router-sync library integrates vue-router into vuex, reflecting a change in the current application path in a dynamically attached module.

You can delete a dynamically registered module using the store.unregisterModule (moduleName). Please note that the static, defined at the time the repository was created, modules cannot be removed using this method.

Sometimes we may need to create several instances of the module, for example:

creation of several storages that are used by one module, for example, to avoid stateful singletones in the SSR when using the runInNewContext option if false or 'once';
registering the module several times in one repository.

If we use an object to determine the state of a module, then this state object will be used by reference and cause pollution of the state of the storage/module during its mutations. This is actually the same problem with data inside Vue components. So the solution will be the same.

Application structure

In reality, Vuex does not impose any significant restrictions on the code structure used. However, it requires compliance with several high-level principles:

The global state of the application must be contained in global storage;
The only mechanism for changing this state are mutations that are synchronous transactions;
Asynchronous operations are encapsulated in actions or their combinations.

As long as you follow these rules, you can use any project structure. If your storage file gets too large, just start putting actions, mutations, and getters into separate files. For any non-trivial application, you will most likely need to use modules. Here is an example of a possible project structure. For reference, you can use the shopping cart example.

Plugins

Vuex repositories accept the plugins option, which provides hooks for each mutation. The Vuex plugin is just a function that receives storage as a single parameter. Plugins are not allowed to directly change the state of the application as well as components. They can only cause changes indirectly using mutations.

By causing mutations, the plugin can synchronize the data source with the data store in the application. For example, to synchronize storage with a web socket, the example is intentionally simplified, in a real situation, createWebSocketPlugin would have additional options. Sometimes a plugin may need to “take a nugget” of the application state or compare the “before” and “after” mutations. To do this, use deep copying of the state object.

Impression plugins should only be used during development. When using webpack or Browserify, we can give this moment at their mercy. The plugin will be used by default. In the production environment, you will need DefinePlugin for webpack, or envify for Browserify to change the value of process.env.NODE_ENV! == 'production' to false in the final assembly.

Vuex comes with a logging plugin that can be used for debugging. You can also enable the logging plugin directly using a separate <script> tag, which places the createVuexLogger function in the global namespace. Please note that this plugin makes state casts, so you should use it only at the development stage.

Strict mode

To enable strict mode, specify strict: true when creating the Vuex repository. In strict mode, any attempt to make changes to the Vuex state, except mutations, will throw an error. This ensures that all state mutations are explicitly tracked through debugging tools.

Do not use strict mode in production! Strict mode triggers deep tracking of the application state tree in synchronous mode to detect inappropriate mutations, and this can be costly for performance when a large number of mutations occur. Be sure to turn this mode off in production to avoid performance degradation.

Work with forms

When using strict mode, Vuex may not seem obvious how to use the v-model with the Vuex state part. Suppose obj is a computed property that returns an object reference from the repository. In this case, the v-model will try to change the obj.message value during user actions directly. In strict mode, such changes will trigger an error because they occur outside of Vuex mutation handlers. To work with Vuex in this situation, you should bind the value to <input> and track its changes by the input or change event.

Testing

The main subject of unit testing in Vuex are mutations and actions. Mutations are fairly easy to test, as they are just simple functions whose behavior depends entirely on the parameters passed. One trick is that if you use ES2015 modules and put your mutations in the store.js file, then in addition to the default export, you must export the mutations using named exports.

Testing activities are a bit more complicated, as they can access external APIs. When testing actions, you usually have to fake external objects - for example, calls to the API can be moved to a separate service, and as part of the tests, this service can be replaced with a fake one. To simplify the simulation of dependencies, you can use webpack and inject-loader to build test files.

Getters doing complex calculations would also be helpful to test. As with mutations, everything is simple. If you correctly follow the rules for writing mutations and actions, the resulting tests should not depend on the browser API. Therefore, they can be assembled by webpack and run in Node. On the other hand, you can use mocha-loader or Karma + karma-webpack, and run tests in real browsers.

Hot reboot

Vuex supports hot-swapping of mutations, modules, actions, and getters at development time using the webpack Hot Module Replacement API. Similar functionality in Browserify is achievable using the browserify-hmr plugin. For mutations and modules, you need to use the store.hotUpdate() API method.

Why Vuex Actions are the Ideal API Interface

If you are working on a project in which the back end and front end are developing at the same time, or you are working in a UI/Frontend team that can even create a user interface before the back end exists, you are probably familiar with the problem when you need to drown out back end parts or data as the front end develops.

The general way that this manifests is with purely static templates or content, with placeholders and text right in your interface templates. A step away from this is some form of fixtures, data that is statically loaded by the interface and injected into place. Both of them often face the same set of problems. When the back end is finally available, there is a bunch of refactoring to get the data in place.

Even if the data structure from the back end matches your fixtures, you still have to cross to find each integration point. And if the structure is different, you should not only do this, but you must figure out how you can either change the external interface or create an abstraction layer that transforms the data.

Strengths and Benefits of Vuex Storage

Compared to a simple global object, the Vuex repository has many significant advantages and benefits:

Vuex Storage - Reactive. As soon as components get the state from it, they will reactively update their views every time the state changes.
Components cannot directly change the state of the repository. The only way to change the state of the repository is to commit the mutations explicitly. This ensures that every state change leaves a tracked record, which makes debugging and testing the application easier.
Components cannot directly change the state of the repository. The only way to change the state of the repository is to commit the mutations explicitly. This ensures that every state change leaves a tracked record, which makes debugging and testing the application easier.
You can easily debug your application by integrating Vuex with the Vue DevTools extension.
Vuex repository gives you a general picture of the state of how everything is connected and affects the application.
It is easier to maintain and synchronize the state between several components, even if the hierarchy of elements is changing.
Vuex enables the direct interaction of components with each other.
If the component is destroyed, the state in the Vuex repository will remain untouched.

Summary

When working with Vuex, we need to remember some crucial points. Vuex creates a repository that consists of states, getters, mutations, and actions. To update or change state, must make a mutation. To perform an asynchronous task, you need an action. Actions, if successful, commit a mutation that changes state, thereby updating the presentation. The application state is stored as one large JSON object. Getters are used to access values in the store. Mutations update condition. It should be remembered that mutations are synchronous. All asynchronous operations must be performed within actions. Actions change state, initiating mutations. Make it a rule to initiate mutations solely through action. Modules can be used to organize storage in several small files.

Vuex makes working with Vue much more comfortable and more fun. If you are new, there may be situations where it is difficult to decide whether to use Vuex in certain areas of application. Follow instincts and reach high speed pretty quickly.

Docker-based development

Oleksandr Simonov — Thu, 30 Jan 2020 21:03:05 +0000

Hello guys,

I want to make an announcement that I plan to start a series of articles about how to use Docker in local development processes.

First of all, I plan to explain why we are at Amoniac have chosen Docker as our main technology for local and production environments. I will show the cases when Docker helps a lot to start new development projects and optimize current processes.

In the middle, I will show how to organize the process on your laptop with Docker Compose and spend 10 minutes on new projects' environment setup.

At the latest posts, you will see how to migrate from Docker-Compose to the Kubernetes based deployments and how to optimize your Docker containers to have smaller sizes and better scalability.

Correct and Efficient Vuex Using. Part I

Oleksandr Simonov — Thu, 30 Jan 2020 12:05:57 +0000

With this article, we begin a series of publications about Vue.js technology and try to make out the application development and all its components from different practical sides. In this part, we will tell you what the Vuex library is and analyze in detail such components as a store, state, getters, mutations, and actions.

Also, in the second part, we will consider modules, application structure, plugins, strict mode, work with forms, testing and strengths/benefits of Vuex Storage.

What is Vuex, and Where it Used?

VueX is a state management library inspired by Flux, Redux, and Elm architecture, but specially designed and tuned to integrate well with Vue.js and take advantage of Vue’s Reactivity.

What is a state management pattern? Let's start with a simple Vue application that implements a counter. This stand-alone application consists of the following parts:

State that controls the application;
The view is a state display specified declaratively;
Actions are possible ways to change the state of the app in response to users interaction with the view.

Sometimes several components may appear that are based on the same state:

multiple views may depend on the same part of the application state;
actions from different views can affect the equal parts of the application state.

Solving the first problem, you will have to transfer the same data with input parameters to deeply embedded components. This is often complicated and tedious, but for neighboring elements this will not work at all. Solving the second problem, you can come to such solutions as referring to parent/child instances or try changing and synchronizing multiple state copies through actions. Both approaches are fragile and quickly lead to the emergence of code that cannot be supported.

So why not take out the overall general state of the application from the components and manage it in a global singleton? At the same time, our component tree becomes one big "view" and any component can access the application state or trigger actions to change the state, regardless of where they are in the tree!

By clearly defining and separating the concepts that arise in state management, and by requiring certain rules that maintain independence between views and states, we better structure the code and make it easier to maintain.

This is the core idea of Vuex, inspired by Flux, Redux, and Elm Architecture. Unlike other patterns, Vuex is implemented as a library designed explicitly for Vue.js to use its reactivity system for efficient updates.

The Main Components and Capabilities of Vuex

Store

At the center of any Vuex application is a store. The store is a container that stores the state of your application. Two points distinguish Vuex store from a simple global object:

The Vuex store is reactive. When Vue components rely on their state, they will be reactively and efficiently updated if the state of the store changes.
You cannot directly change the state of the store. The only way to make changes is to cause a mutation explicitly. This ensures that any change in the state leaves a mark and allows the use of tools to better understand the progress of the application.

After installing Vuex, a repository is created. It's quite simple, and you need to specify the initial state object and some actions and mutations.

const store = new Vuex.Store({
  state: {
    counter: 0 // initial store state
  },
  actions: {
    increment({ commit, dispatch, getters }) {
       commit('INCREMENT')
    },
    decrement({ commit, dispatch, getters }) {
       commit('DECREMENT')
    }
  },
  mutations: {
    INCREMENT(state) {
      state.counter++
    },
    DECREMENT(state) {
      state.counter--
    }
  },
  getters: {
    counter(state) {
      return state.counter
    }
  }
})

The reason we are committing a mutation instead of changing store.state.count directly, is because we want to explicitly track it. This simple convention makes your intention more explicit, so that you can reason about state changes in your app better when reading the code. In addition, this gives us the opportunity to implement tools that can log every mutation, take state snapshots, or even perform time travel debugging.

State. Single state tree

Vuex uses a single state tree when one object contains the entire global state of the application and serves as the only one source. It also means that the app will have only one such storage. A single state tree makes it easy to find the part you need or take snapshots of the current state of the application for debugging purposes.

The data you store in Vuex follows the same rules as the data in a Vue instance, ie the state object must be plain. So how do we display state inside the store in our Vue components? Since Vuex stores are reactive, the simplest way to "retrieve" state from it is simply returning some store state from within a computed property. Whenever store.state.count changes, it will cause the computed property to re-evaluate, and trigger associated DOM updates.

This pattern causes the component to rely on the global store singleton. When using a module system, it requires importing the store in every component that uses store state, and also requires mocking when testing the component. Vuex provides a mechanism to "inject" the store into all child components from the root component with the $store option (enabled by Vue.use(Vuex))

export default {
  methods: {
    incrementCounter() {
      this.$store.dispatch('increment')
    }
  }
}

When a component needs to make use of multiple store state properties or getters, declaring all these computed properties can get repetitive and verbose. To deal with this we can make use of the mapState helper which generates computed getter functions for us, saving us some keystrokes:

import { mapState } from 'vuex';

export default {
  computed: {
    ...mapState({
       counter: state => state.counter
    }),

    counterSquared() {
      return Math.pow(this.counter, 2)
    }
  }
}

We can also pass a string array to mapState when the name of a mapped computed property is the same as a state sub tree name.

Note that mapState returns an object. How do we use it in combination with other local computed properties? Normally, we'd have to use a utility to merge multiple objects into one so that we can pass the final object to computed. However with the object spread operator (which is a stage-4 ECMAScript proposal), we can greatly simplify the syntax as shown above.

Using Vuex doesn't mean you should put all the state in Vuex. Although putting more state into Vuex makes your state mutations more explicit and debuggable, sometimes it could also make the code more verbose and indirect. If a piece of state strictly belongs to a single component, it could be just fine leaving it as local state. You should weigh the trade-offs and make decisions that fit the development needs of your app.

Getters

Sometimes we may need to compute derived state based on store state, for example filtering through a list of items and counting them.

If more than one component needs to make use of this, we have to either duplicate the function, or extract it into a shared helper and import it in multiple places - both are less than ideal.

Vuex allows us to define "getters" in the store. You can think of them as computed properties for stores. Like computed properties, a getter's result is cached based on its dependencies, and will only re-evaluate when some of its dependencies have changed.

// In store
getters: {
  counter(state) {
    return state.counter
  },
  counterSquared(state) {
    return Math.pow(state.counter, 2)
  }
}

// In component
import { mapGetters } from 'vuex';

export default {
  computed: {
    ...mapgetters([ 'counter', 'counterSquared' ])
  }
}

You can also pass arguments to getters by returning a function. This is particularly useful when you want to query an array in the store. Note that getters accessed via methods will run each time you call them, and the result is not cached.

The mapGetters helper simply maps store getters to local computed properties.

Mutations

The only way to actually change state in a Vuex store is by committing a mutation. Vuex mutations are very similar to events: each mutation has a string type and a handler. The handler function is where we perform actual state modifications, and it will receive the state as the first argument.

You cannot directly call a mutation handler. Think of it more like event registration: "When a mutation with type increment is triggered, call this handler." To invoke a mutation handler, you need to call store.commit with its type.

export default {
  methods: {
    incrementCounter() {
      this.$store.commit('INCREMENT')
    }
  }
}

You can pass an additional argument to store.commit, which is called the payload for the mutation. In most cases, the payload should be an object so that it can contain multiple fields, and the recorded mutation will also be more descriptive. An alternative way to commit a mutation is by directly using an object that has a type property. When using object-style commit, the entire object will be passed as the payload to mutation handlers, so the handler remains the same.

Since a Vuex store's state is made reactive by Vue, when we mutate the state, Vue components observing the state will update automatically. This also means Vuex mutations are subject to the same reactivity caveats when working with plain Vue:

Prefer initializing your store's initial state with all desired fields upfront.
When adding new properties to an Object, you should either - use Vue.set(obj, 'newProp', 123), or replace that Object with a fresh one. For example, using the object spread syntax.

However, using constants to indicate the types of mutations is completely optional, although this may be useful in large projects.

One important rule to remember is that mutation handler functions must be synchronous. Imagine we are debugging the app and looking at the devtool's mutation logs. For every mutation logged, the devtool will need to capture a "before" and "after" snapshots of the state. However, the asynchronous callback inside the example mutation above makes that impossible: the callback is not called yet when the mutation is committed, and there's no way for the devtool to know when the callback will actually be called - any state mutation performed in the callback is essentially untrackable!

You can commit mutations in components with this.$store.commit('xxx'), or use the mapMutations helper which maps component methods to store.commit calls (requires root $store injection)

Asynchronicity combined with state mutation can make your program very hard to reason about. For example, when you call two methods both with async callbacks that mutate the state, how do you know when they are called and which callback was called first? This is exactly why to separate the two concepts. In Vuex, mutations are synchronous transactions. To handle asynchronous operations, should descry Actions.

Actions

Actions are similar to mutations with a few differences:

Instead of mutating the state, actions commit mutations.
Actions can contain arbitrary asynchronous operations.

actions: {
  signIn({ commit }, payload) {
    // Show spinner when user submit form
    commit('LOGIN_IN_PROGRESS', true);

    // axios - Promise based HTTP client for browser and node.js
    axios
      .post('/api/v1/sign_in', {
        email: payload.email
        password: payload.password
      })
      .then((response) => {
         const { user, token } = response.data;
         commit('SET_AUTH_TOKEN', token);
         commit('SET_USER', user);
         commit('LOGIN_IN_PROGRESS', false);
      })
      .catch((error) => {
        commit('SET_SIGN_IN_ERROR', error.response.data.reason);
        commit('LOGIN_IN_PROGRESS', false);
      })
  }
}

Asynchronous action on the example of authorization

Action handlers receive a context object which exposes the same set of methods/properties on the store instance, so you can call context.commit to commit a mutation, or access the state and getters via context.state and context.getters. We can even call other actions with context.dispatch. We will see why this context object is not the store instance itself when we introduce Modules later.

In practice, we often use ES2015 argument destructuring to simplify the code a bit especially when we need to call commit multiple times. Actions are triggered with the store.dispatch method. This may look silly at first sight if we want to increment the count, why don't we just call store.commit('increment') directly? Remember that mutations have to be synchronous? Actions don't. We can perform asynchronous operations inside an action. Actions support the same payload format and object-style dispatch.

A more practical example of real-world actions would be an action to checkout a shopping cart, which involves calling an async API and committing multiple mutations. Performing a flow of asynchronous operations, and recording the side effects (state mutations) of the action by committing them.

You can dispatch actions in components with this.$store.dispatch('xxx'), or use the mapActions helper which maps component methods to store.dispatch calls (requires root $store injection). Actions are often asynchronous, so how do we know when an action is done? And more importantly, how can we compose multiple actions together to handle more complex async flows?

The first thing to know is that store.dispatch can handle Promise returned by the triggered action handler and it also returns Promise. It's possible for a store.dispatch to trigger multiple action handlers in different modules. In such a case the returned value will be a Promise that resolves when all triggered handlers have been resolved.

It is only a small part of what we are going to tell in our next articles about Vue.js and all of its additional tools and benefits. Next, we continue our review of the Vuex library and components.

Also, in our blog section, you can read more about Vue.js tool here https://amoniac.eu/blog/post/why-we-fell-in-love-with-vue-js

Most Popular JS Frameworks Overview

Oleksandr Simonov — Mon, 27 Jan 2020 11:46:44 +0000

JavaScript's Rich and Functional World

The JavaScript world is a rich environment with dozens of tools, libraries, and frameworks. But, with lots of options comes a lot of confusion. It really is a double-edged sword.

While you get lots of space for creativity and experimentation, sometimes you are unsure about what library or framework to choose.

The front-end framework you choose can make or break your project in the long run.

In this article, we will look at some of the most popular JavaScript frameworks, and how they fare against each other. We’ll examine five different perspectives of these frameworks, which eases the process of deciding on your next JavaScript framework.

Whether you are choosing from one of these popular JavaScript frameworks, or something more esoteric, you should take each of these aspects into consideration. So, without ado, we will go ahead and take a look at the most popular JavaScript frameworks for 2019!

VUE

Vue.js is an open-source JavaScript environment designed to simplify and streamline user interface design. The framework, also the ideal blend of Angular and React, has proven itself to be the perfect choice for developing a lightweight, two-way data binding application to the angle structure and server rendering of the React JS framework. Vue.js was nominated as the most popular JavaScript interface on GitHub with 118 thousand stars last year.

Vue.js may seem like an ideal JavaScript structure for software development, but it also has its pros and cons.

Pros

A quick set of popularity: in just a few years since its inception, many enterprises have added Vue.js to their technical stack.
Quick Setup: Vue has built-in data binding and an MVC model (model, view, controller), which makes configuration much easier compared to Angular.js and React.js.
Easier integration: the platform supports easier integration with HTML elements.
Small learning curve: compared to the Angular JS Framework, Vue is much easier to learn, understand, and use.

Cons

Few resources: the structure is still too young to find useful solutions on the Internet and self-study.
Small community engagement: Vue.js is new to the market and has less community support than Angular and React technologies.

You can also read more about the framework Vue.js in our article here https://amoniac.eu/blog/post/why-we-fell-in-love-with-vue-js

REACT

Supported by Facebook, Instagram and other well-known organizations, React is one of the best JavaScript frameworks for the past five years. Also, React.js or React JS, more than 38% of developers worldwide use the front end infrastructure. Netflix, Flipboard, PayPal and the BBC are the first organizations to use React. Let's take a look at all the pros and cons of React.

Pros

Lots of documentation and online resources: thanks to Facebook support, there are many opportunities to use a ton of documentation and online resources for learning and using the Javascript framework for React.
Fast, flexible, efficient and lightweight technology: The JS system is widely recommended for its efficiency, small block size, flexibility and a quicker approach to work due to its simple component model and server-side rendering functionality.
A transition between versions: migration between versions is usually very simple, Facebook provides “codemods” to automate a huge part of the process. 4. Feels great when working with ES6 / 7 ReactJS, can take on any load.
The structure has a component architecture that revolutionized web application development and influenced other technologies.
DOM allows you to combine HTML, XHTML or XML documents follow certain criteria, most often into a tree, so React is excellent for web browsers when analyzing various elements of web applications.

Cons

Assembly tools are needed: this JavaScript infrastructure may not work correctly without adequate build tools or may display incompatibility with other libraries and codes due to high DOM.
Big learning curve: Unlike Vue, React takes more time to learn concepts and implement. React JS requires a massive amount of knowledge in how to integrate the user interface into the MVC structure.
Lack of streamlined documentation: the super-fast exchange of solutions in ReactJS leaves no room for streamlining the documentation, the documents are placed a bit chaotic, since many developers individually enter them into the database without any systematic approach.

ANGULAR

Angular.js is a full-featured front-end JavaScript environment supported by Google and other famous corporations. This structure is known for its potential capabilities like fast code generation, two-way data binding, and testing parts of an application. Although hundreds of companies and developers enjoy using the Angular front end Javascript framework, there are pros and cons of this technology.

Pros

Two-way data binding.
Mobile approach to web development.
Support PWA.
Stable and long-term support for Google.
Universal MVVM module, allows you to separately operate in one section of the application, using the same data set.
Interdependence of functions, because of their connectedness with components and modules.
RXJS, lightning fast compilation, less than 2.9 seconds, modified start HttpClient.

Cons

The problem with the drainage of the battery: applications created using the framework system Javascript, known for excessively discharging the battery of the device.
Poor optimization: Angular.js based applications require more optimization to solve low-performance problems.
Big learning curve: Angular shows a high learning scale, you need more time to master this structure.
Integration errors: may occur during the transition from the old version to the new one.
Difficult programming language: although Angular uses TypeScript 2.4.

EMBER

Ember.js has been used in the design of many complex websites, like Kickstarter, Heroku, and LinkedIn. Ember.js is ideal for developing complex web applications, and the string system of templates with which it is delivered contributes to a significant reduction in load time. The front end JavaScript Framework also focuses on scalability so that developers can quickly work with both mobile and web applications.

Pros

Ember Data Library: this is one of the best libraries for API level requests and data retrieval in the local app store.
Ember CLI: an idea stolen from Rails, but this feature makes Ember.js very convenient.
Many extensions (ember addons) that can be easily added to the application using a single terminal command (ember install). The centralized repository of all add-ons along with the search is also enjoyable.
Built-in testing tools: standard ember-cli comes with QUnit.

Cons

Ember Data: suitable for standard REST API requests only.
Many ember addons: ports existing in the jQuery library.
Relationship with jQuery: it would be much more convenient if Ember would use axios or a standard sample to create ajax requests.
A huge learning curve: first you need to learn Javascript, then Ember, this can take a lot of time, especially from scratch.
No server-side rendering.
No Redux. Enough said.

BACKBONE

Backbone is an MV* framework. Backbone partly implements an MVC architecture, as Backbone’s View part carries out the responsibilities of the Controller.

Backbone has a strong dependency on the jQuery and the Underscore library that gives us many helper functions for convenient cross-browser work with JavaScript. Unlike many other full-fledged JavaScript frameworks, Backbone attempts to reduce complexity to avoid performance issues. More specifically, you won't get performance problems because of two-way data binding or built-in loops like in AngularJS.

Pros

View: the view part of Backbone apps, Backbone views implement component logic, how model data is rendered to the browser, similar to a Controller in MVC, you can bind views and models so that the view will change whenever model data is altered. Backbone view can use third-party templating engines like Mustache and Underscore.js.
Collection: which are just arrays of similar models, if your app has different types of users, each user type will be represented by a separate model, and all user models can be iterated over in Backbone collections.
Events: a class that let's implement and use events, both custom, and built-in, and bind various events to Backbone models, collections, routes, and views.
Router: an interface that maps URLs to different components of an app, Backbone's router depends on the history object to work with browser history.
REST: a simple API that we can use to synchronize the front end and back end more specifically, to request persistent model data and collections from the server.

Cons

Backbone parts are not sufficient to develop an advanced client-side app: another way, Backbone is almost always used with additional JavaScript libraries.
Backbone’s view layer can’t render itself to the DOM: This is where Marionette and Thorax come into, they let make Backbone views to the DOM.
Work with Backbone: it’s almost inevitable that also need to learn Marionette, Chaplin, or Thorax.

Summary

Our team's favorite is Vue.js, one of those selected here. But the real answer depends entirely on the project. Do you need the most popular JavaScript framework? Probably no. How about the biggest and the biggest or the smallest and the lightest? These factors may or may not matter.

Each developer has his own opinion, but we all need to understand one thing that cannot find the best structure among the JavaScript frameworks. Choosing the most appropriate structure depends entirely on the needs of a project. Thus, it is to consider the pros and cons of all the above frameworks and decide which one to start a project with.

Why we love and choose Ruby instead of Node.js?

Oleksandr Simonov — Thu, 23 Jan 2020 12:30:27 +0000

Making pretty code with Ruby

Ruby on Rails is an open-source platform from which programmers become happy, code is pretty, and development is reliable and fast.

RoR is a framework written in the Ruby programming language, implements the architectural pattern Model-View-Controller for web applications, and also provides integration with a web server and database server. It opens software and licensed under conditions of the MIT license.

Created by David Heinemeier Hansson based on his 37signals work on the Basecamp project management tool that released in 2004.

RoR fully-fledged website framework that includes everything to complete a website project including an ability to manage logic, routing, and applications, all from the box. These handy tools also include database integration and controllers which makes it easier to facilitate web development on an end to end basis.

Key benefits of Ruby and Ruby on Rails

Development speed

The main advantage of the Ruby language is the speed of development that increased by 30-40 percent with any other programming language or framework. The growth rate of development determined by an extensive set of ready-to-work standard RoR tools, a massive set of already made solutions in the community, the Ruby language and the simplicity of programming on it.

One of the most critical parts of the RoR culture is sociality. Solved the problem and helped solve others. I implemented my module, so, share it with the community. Thus, thousands of ready-made solutions of various tasks stored in open access. Authentication, authorization, commenting, payment systems, mailing lists and much more implemented by others, implemented and tested and recommended by numerous communities.

Culture and Standards

Ruby on Rails is a framework that does not allow you amateur performance. In RoR, you can “invent your own bike” and program in any direction without relying on standards; but this is not required. Criteria for placing files, standards for writing code, general rules for programming in the community actively structure any project. Due to this, it becomes readable. Entry into the project of newcomers is high-speed. Experience shows that any newcomer to the project on the first day of work makes its first useful edits. Due to this, it not a big problem if the project development by one team of programmers and project support or revision by an entirely different team. The project on RoR is a priori clear to any developer.

Testing Tools

When developing any major project, a reasonable question arises. How and who will test the project? There is not always the means and desire to create entire departments of testing, especially to automate this process. Unlike other frameworks, RoR has excellent automated testing tools. There are no standard testing tools in other programming languages and frameworks. There is third-party development that allows you to organize automatic testing of a project in other languages, but they are not out of the box, and programmers do not think about using them. In a project on RoR, ideally, the project code is not written until tests written for this code. RoR ideology implies the initial use of BDD (Behavior Driven Development) or TDD (Test Driven Development) methods.

More info about testing can be found in our previous article here https://amoniac.eu/blog/post/tests-as-must-have-for-complex-projects

Caching tools

Project caching is one of the most critical stages in the development of a large Internet project. Different languages have different data caching options. These options and tools are screwed, attached, fastened, attached at the side. Until now, there is no consensus in the community what is to use, how to cache the data, what tools to use.

Ruby on Rails in its basic configuration has regular data caching tools. At the start, tools provided that allow you to implement data caching on the project. You can cache whole pages or blocks of code. You can cache query results and ActiveRecord — models. You can cache as with Memcached or Redis and other means. To implement caching on a Ruby on Rails project, in 95 percent of cases you will not need anything other than ready-made and standard solutions.

Localization tools

There is a situation when someone has done a project, and then suddenly realizes that to continue the development of the project, a version in some other language is necessary. Developers working with other programming languages at the same time begin to talk about the fact that it not foreseen in advance, that it is long and complicated. Let's say, let's open a parallel project, which will be a complete copy of this, and translate it.

The basic configuration of Ruby on Rails has project localization tools. You may consider the need to support various languages on the site both initially and in the future. RoR can distribute templates for different languages, contains configuration files with a translation of terms and many other regular tools for implementing the project localization.

Nice routing

In many projects, we can see when the address of a particular page is huge and unclear. In Ruby, there is a regular ability to flexibly configure your routing, the type of addresses, the names of the main sections. It is possible to quickly change addresses in one place without having to change this address throughout the project. In the community of RoR – developers, REST ideology is actively used. The addresses of pages in projects on Ruby on Rails are always clear, beautiful, correctly understood by search engines and simple.

Validations tools

In Ruby on Rails, tools are correctly implemented to validate incoming data. Your users fill out forms, and you need to check the correctness of the entered email address, the presence of a password or the required minimum length of the login — regular means of Rails will help you with this.

Migrations and work with the database

The common problem of many projects written in other languages is the inability to control the structure of the database using clear tools and tools. Changes to the structure are made manually and directly into the database. Because of this, many incomprehensible fields and tables appear in the project, about which no one remembers anything. In Ruby on Rails, there are regular database tools - “migrations.” The database structure is stored in the application code and configured from the project. Your structure will always be in the repository, any change to the structure will be documented and tied to a specific commit in the repository.

Security

Ruby on Rails is by default heavily sharpened for project security. When using the RoR tools, SQL injections and XSS attacks excluded. All input parameters escaped by default. Displayed variables in templates also avoided unless you specify the opposite option. The developer has no chance to make security mistakes, although there are exceptions.

Deploy

There are many convenient and enjoyable tools in the Ruby on Rails environment. Including tools used in the deployment process. Using Capistrano, rolling out a new version of an application on a combat server or several servers will require one command in the console that is cap deploy.

Version control systems

When developing any Ruby on Rails project, the use of known version control systems implied. Using git, as we say, “voluntarily — forcibly”, since many systems of automatic project deployment on combat servers do not work without them. RoR programmers initially, when exploring the platform, are forced to learn git, since numerous code examples in the documentation imply the use of these version control systems. Because of this, it is easier for inexperienced beginners to start learning other languages and not to touch Rails until they reach a certain level of understanding of web development as such and its principles.

Task managers

Ruby on Rails was initially designed to implement the Basecamp project management system. Also, on RoR an accessible and free Redmine project management system was created. When working on Rails projects voluntarily-compulsorily use of such systems. All of them integrated with version control systems, which allows more flexible management of project development processes.

Where Ruby on Rails wins vs. Node.js?

Web development best practice

Rails comes with a view to creating the best practice for web development. The creator intended to make it easy to develop sites accordingly a set framework which puts convention before configuration. As such, Ruby On Rails ships with every necessary library and module. And they all implement the model, view and controller paradigm. The intention is to make web development as predictable and smooth a process as possible.

Infrastructure that is expansive

RoR’s built for quick site development, so, it includes an integrated web server, plus, it has a database with generators and scripts; these are powerful and make it easy to together a Rails application. You can use all the necessary bits automatically, and pieces a functioning Rails site requires in place. It’s great for rapid development.

Database interoperability

You can easily migrate Rails databases. Because the model that supports the Rails database, ActiveRecord, can easily translate the differences amongst the numerous SQL interactions. Instead of writing out SQL code, users of Rails can use the Rails language to describe changes to database tables.

So, in effect, the schema created is agnostic of the database in use. Which means you can run Rails application in many database environments.

And where does it lose?

Flexibility can be an issue

Flexibility can be an issue, for every advantage, there is a matching drawback. It is also about RoR. Due to Rails creator’s development vision, you may feel restricted with RoR if your particular application is too unique. The Rails platform imposes a lot of authority on the developmental process, so there can come where adjusting RoR to fit your requirements takes up a massive amount of your time. Whereas merely starting from scratch would have been quicker.

Performance is not always optimized

Again, a positive thing that can also be a negative. Because of the large number of modules in the box, RoR can seemingly bog down when running in the real world. The overall framework is heavier than alternatives, including Node.js. So it’s not so efficient at managing a barrage of requests is typical of many website applications. You can add more server instances, but these use up your memory.

Debugging can be tedious

Because of Ruby on Rails’ complexity and multiple layers, it can be difficult to troubleshoot a Ruby application. Finding an error in the mix can be very time-consuming. So if something goes wrong, compounded by your application’s custom requirements, you can find Ruby on Rails a very tedious platform to develop on.

What is Node.js?

Node.js is a server platform built on JavaScript Engine from Google Chrome (V8 Engine). Node.js developed by Ryan Dalem in 2009, the latest version of the framework is v0.10.36.

Node.js is an open-source, cross-platform JavaScript run-time environment that executes JavaScript code outside of a browser. JavaScript is used primarily for client-side scripting, in which scripts written in JavaScript are embedded in a web page's HTML and run client-side by a JavaScript engine in the user's web browser.

In short, Node.js is a run time environment that allows you to execute server-side, which used to be client-side, code.

So, Node.js, built on version 8 of the Chrome JavaScript engine, lets you execute JavaScript on a server. It was initially intended to make it easier to create push capability for real-time websites. But Node.js is an expansive platform. And it includes native modules that can manage everything from files to computing resources and security.

The Node.js distributed development project, governed by the Node.js Foundation, facilitated by the Linux Foundation's Collaborative Projects program.

Features and uses of Node.js

We list some critical elements that make Node.js popular with software developers.

Asynchronous scripts based on events

All Node.js APIs are asynchronous, that is, non-blocking downloads. In essence, Node.js based server never expects data to return from the API. After the call, the server proceeds to the next API, and the Node.js Events notification mechanism helps the server to get a response from the previous API call.

Very fast

Being built on the Google Chrome V8 JavaScript browser, the Node.js library and runs very quickly in code. As for our experience, we prefer to rewrite some code to Go instead of Node.js, and only when it is necessary. Thus, we are leveling the speed advantage of Node.js. But you must understand that in complex applications, different parts can affect speed, like a database, a web server, and more — not just pure language speed.

Single-flow but easily scalable

Node.js uses a single-threaded model with an event loop. The Event engine helps the server response in a nonblocking manner, and provides high scalability, unlike traditional servers, which create limited threads for processing requests. Node.js uses a single-threaded program, and the same program can serve a much larger number of requests than traditional servers, the Apache HTTP Server.

No buffering

Node.js applications do not buffer the data. They output the data in parts.

License

Node.js released under the MIT license.

Where and who uses Node.js?

In these areas, Node.js has established itself as an ideal technological solution:

— applications related to data input/output

— applications for streaming data

— intensive use of real-time data (DIRT)

— JSON API based applications

Among the users are such large companies as eBay, General Electric, GoDaddy, Microsoft, PayPal, Uber, Wikipins, Yahoo! and yammer.

Where Node.js wins vs. Ruby on Rails?

Node.js is excellent for applications that are real-time and which handle a lot of concurrent requests. Under these scenarios, data regularly go between the client and the server. These Real-Time Applications (RTAs) include chat apps, applications for collaborating and video conferencing.

Because Node.jsis event-based, it’s great for handling these apps. Running on a single page, known as SPAs or Single Page Applications, involves a lot of processing on the client side. The primary function for the back-end under these scenarios is to provide a REST API.

TOP 10 famous Ruby on Rails web apps

Github

Github is a web-based hosting service for version control using Git. It mostly used for computer code. It offers all of the distributed version control and source code management (SCM) functionality of Git as well as adding its features.

It provides access control and several collaboration features such as bug tracking, feature requests, task management, and wikis for every project.

Bloomberg

Bloomberg is a privately held financial, software, data, and media company headquartered in Midtown Manhattan, New York City. It was founded by Michael Bloomberg in 1981, with the help of Thomas Secunda, Duncan MacMillan, Charles Zegar, and a 30% ownership investment by Merrill Lynch. Bloomberg L.P. provides financial software tools such as an analytics and equity trading platform, data services, and news to financial companies and organizations through the Bloomberg Terminal, its core revenue-generating product.

Yellow Pages

The yellow pages are any telephone directory of businesses, organized by category rather than alphabetically by business name, and in which advertising is sold. The directories originally printed on yellow paper, as opposed to white pages for non-commercial listings. The traditional term "yellow pages" is now also applied to online directories of businesses.

Shopify

Shopify is a Canadian e-commerce company headquartered in Ottawa, Ontario. It is also the name of its proprietary e-commerce platform for online stores and retail point-of-sale systems. Shopify offers online retailers a suite of services including payments, marketing, shipping and customer engagement tools to simplify the process of running an online store for small merchants.

Groupon

Groupon is an American worldwide e-commerce marketplace connecting subscribers with local merchants by offering activities, travel, goods and services in 15 countries. Based in Chicago, Groupon was launched in November 2008, and the first market for Groupon was Chicago, followed soon after that by Boston, New York City, and Toronto. By October 2010, Groupon was available in 150 cities in North America and 100 cities in Europe, Asia, and South America.

Airbnb

Airbnb is a privately held global company headquartered in San Francisco that operates an online marketplace and hospitality service which is accessible via its websites and mobile apps. Members can use the service to arrange or offer lodging, primarily homestays, or tourism experiences. The company does not own any of the real estate listings, nor does it host events; as a broker, it receives commissions from every booking.

Dribbble

Dribbble is an online community for showcasing user-made artwork. It functions as a self-promotion and networking platform for graphic design, web design, illustration, photography, and other creative areas. It was founded in 2009 by Dan Cederholm and Rich Thornett, becoming publicly available in 2010. It is one of the largest platforms for designers to share their work online.

SlideShare

SlideShare is a hosting service for professional content including presentations, infographics, documents, and videos. Users can upload files privately or publicly in PowerPoint, Word, PDF, or OpenDocument format. Content can then be viewed on the site itself, on handheld devices or embedded on other sites. The website was originally meant to be used for businesses to share slides among employees more efficiently, but it also has expanded to become a host of a large number of slides that are uploaded merely to entertain.

Hulu

Hulu is an American entertainment company that provides "over-the-top media services." It is primarily oriented towards instant streaming of television series, carrying current and past episodes of many series from its owners' respective television networks and other content partners.

SoundCloud

SoundCloud was established in Berlin in August 2007 by Swedish sound designer Alexander Ljung and Swedish electronic musician Eric Wahlforss, and the website launched in October 2008. SoundCloud is an online audio distribution platform and music sharing website based in Berlin, Germany that enables its users to upload, promote, and share audio.

Read more about developments and technologies we use in our blog here https://amoniac.eu/blog

Why we fell in love with Vue.js?

Oleksandr Simonov — Wed, 22 Jan 2020 11:43:08 +0000

What is Vue.JS?

Vue.js is an open source JavaScript framework for creating user interfaces. Easily integrated into projects using other JavaScript libraries. It can function as a web framework that helps develop advanced one-page applications.

In 2013, an employee of Google Evan You, working on one of the projects, concluded that there are no ready-made solutions for rapid prototyping of complex user interfaces of web applications. React was then at an early stage of development, the main tools were such complex frameworks as AngularJS or MVC-oriented Backbone.js, which were not very simple and focused on developing large applications. To overcome this gap, You began developing Vue.js, which, while maintaining simplicity, turned out to be suitable not only for prototyping but also for full-fledged development.

Theoretically, Vue.js is an alternative to jQuery. But in reality, Vue.JS competes quite successfully with React.JS - the obvious leader in the field of View. From modern popular technologies that solve similar problems, you can also select Angular and Ember. Each of them has its advantages and disadvantages. However, all these frameworks can be reduced to one common denominator - the relative complexity of development.

Vue.JS vs others

Vue.JS created with an eye on the best practices of the listed technologies. From React.JS, the Vue team borrowed the idea of a virtual DOM. This approach eliminates direct interaction with interface nodes. The initial work is carried out with its lightweight copy - virtual DOM. And only after this changes applied to the real interface nodes. In parallel, a comparison of the real DOM tree and its virtual copy takes place. Thus the difference is revealed, and only that which has changed redrawn.

From Angular Vue.JS borrowed two-way data binding. This allows you to design interfaces: firstly, declaratively; secondly, using Vue in template engines. Such as Haml or Pug. But It's true that this approach has been practiced before, for example, in the Knockout.JS framework.

The Vue.JS kernel, like React, contains only the necessary functionality for working with the interface. Therefore, it is compact, easily integrates with other technologies, including jQuery, and can even be used instead to develop simple interfaces.

In addition, Vue has a number of plug-ins that implement a modern approach to the development of web applications. What is it about? For example, almost all React applications are designed in tandem with the state control technology Redux, which is a separate library and implements the flux-architecture. The approach practiced by the Redux library turned out to be quite convenient and successful. Therefore, Vue.JS has developed its own application state control technology - Vuex. Vuex completely borrows the ideas of Redux, but the degree of integration of this library with Vue is much higher than in the case of React and Redux. And this translates into speed and convenience.

Vue.js main distinctive ideas

1. Reactivity

Reactivity is when the data inside the application is directly related to the data in the display and changing it in any part instantly affects the redrawing of the screen. How is reactivity implemented in React? In short, all data that we use in the application stored in state and props, if necessary, change the data, we change it through setState, then React determines which parts of the app depended on the modified data and redrew it.

In Vue.js, a similar approach used, but it has one fundamental difference - each field of application input data is expanded using Object.defineProperty and divided into setter/getter pairs. With their help, Vue keeps track of what data is being read or modified and can specifically determine what affects the rendering of the display.

2. Calculated properties

There are several component data types in Vue:

data - basic data;
props - data transmitted from the parent component;
computed - data that can be calculated based on the previous two.

This separation of concepts is a simple but convenient idea. The latter has a number of advantages compared with the approach to React:

We cease to produce auxiliary methods of the form getFullName for components;
They are reactive, and at the first calculation, with the help of extended getters (the principle described in the first paragraph) they collect dependencies and know for sure when changing what data recalculation is necessary;
They are lazy, i.e. are counted only when they are accessed, and not with each change of dependent data;
Cached based on input data.

Similar behavior, when working with a large sample size in Redux, can be achieved with Reselect.

3. Built-in FLIP animation

The idea of conveniently describing animations in frameworks is far from new (ng-animate, ReactCSSTransitionGroup). Surprises FLIP-animation right out of the box. In short, this is a kind of animation of moving elements when you first know their total positions and then move with the help of translate. In Vue, this animation can be obtained with just a couple of lines of code:

4. Components and vue-loader

Vue recommends storing all component code (js, styles, pattern) in a single file like a rather unusual approach. We will not judge how comfortable it is, especially when your components are far from atomic.

But there is a curious point, the components loaded via vue-loader for webpack, which hides the complexity of the build from you, allowing to use your favorite technologies right out of the box ES6, coffeeScript, Sass, postCSS, CSS modules, jade (pug) and others.

And unlike React, we don’t need to deal with the new JSX language, and we continue to use what we are familiar with or use completely different HTML generators, such as PUG.

No setting, cool, huh?

5. Slots

The idea of the slots came from Web Components and is very simple - if you need to transfer several components inside another component, then you can designate the places where they will be displayed. This approach allows you to make complex components, wrappers that easily abstracted from what is happening inside. So, for example, you can make a layout component with several slots:

And let's look at a real example?

Most recently, we developed a Cloud Checker service that allows to analyze cloud services and optimize their use.

This is where we actively used Vue. When developing the design for the project, Google Material Design has taken as the basis, it ideally suited for this task due to its simplicity and rigor, but despite this, it is quite pleasant and user-friendly.

For this reason, at the preparatory stage for writing the frontend part, it was decided to use the ready Material Component Framework as Vuetify. It is intuitive and relatively simple when writing templates, it also stores an incredibly large and powerful base of ready-made components necessary to create a full-fledged ready-made application already from the box.

Vue.JS pros and cons

Vue.JS pros

After examining the key features of the technology and testing them in practice, you can list the main advantages of the Vue framework:

Vue.js has many similar characteristics with Angular, and this can help optimize the processing of HTML blocks using different components.
Vue.js has very extensive documentation that can capture the learning curve for developers and save a lot of time developing an application using only basic knowledge of HTML and JavaScript.
It provides a fast switching period from other frameworks in Vue.js due to the similarity with Angular and React in terms of design and architecture.
Vue.js can be used both for creating single-page applications and for more complex web interfaces. The main thing is that small interactive parts can be easily integrated into the existing infrastructure without having a negative impact on the entire system.
There are no stack requirements, so Vue.JS can be used on any project.
Vue.js can weigh around 20 KB, retaining its speed and flexibility, which allows it to achieve much higher performance than other platforms.
Thanks to the use of any templates and the availability of documentation, most of the problems that arise resolved fairly quickly. Including in comparison with React, since in most applications that do not have complicated interfaces, the whole power of this framework is a bit redundant.
Vue.js can help develop fairly large reusable templates that can be made without the extra time allocated for this, in accordance with its simple structure.
The ability to find and connect to the project almost any developer who is at least a little familiar with front-end. The low threshold of entry allows work with the framework, both front-end and back-end developers.
Vue allows you to create functional applications that meet all modern standards, with a minimal connection of new resources and, in fact, cheaper.

Vue.JS cons

There are also disadvantages, in particular, in comparison with React.JS:

Work on the state of the application is “under the hood”. It increases the entry threshold for new developers, but for our team, this is not a real disadvantage.
Vue.js still has a fairly small market share compared to React or Angular, which means that the sharing of knowledge in this framework is still at an initial stage. But it should be noted that the trends are changing colossally, and Vue is very actively gaining momentum much faster than other frameworks.
Since Vue.js has some Chinese base, many elements and descriptions are still available in Chinese. This leads to partial complexity at some stages of development, however, more and more materials translated into English. As for personal experience, our team copes with tasks of any complexity with the help of Vue and has not encountered any misunderstandings in using the framework.

Despite such shortcomings in the work of Vue.js, our development team has a huge experience in working with technology and ready to cope with absolutely any complex and even sometimes overwhelming tasks.

Today, Vue.js is used by such companies as Xiaomi, Alibaba, WizzAir, EuroNews, Grammarly, Gitlab and Laracasts, Adobe, Behance, Codeship, Reuters.

Angular and React have their own ways to do the things, where, Vue is considerably easy. Many companies are switching to Vue because it is easy to work with. Developing in Angular or React requires good JavaScript knowledge and you need to take a lot of decisions regarding third-party libraries.

Now if we consider our frameworks in this case, Angular uses two-way data binding, React goes for single-data flow, and Vue supports both.

Every framework has its own pros and cons, meaning that there should be just the right choice for every single case during the product development.

Read more about developments and technologies we use in our blog here https://amoniac.eu/blog