Migrating from AngularJS to Vue — Part 1

Author: Rotem Benjamin

Here at Tipalti, we have multiple web applications which were written over the course of the past 10 years. The newest of which is an AngularJS application that was born at the beginning of 2014. Back then AngularJS was the most common Javascript framework, and it made sense to start a new application with it. The following is our journey of migrating and rewriting this app from AngularJS to a new VueJS 2 app.

Why Migrate?

Google declared in 2018 that AngularJS is going into support only mode and that will end in 2021. We wouldn’t want our application using a framework without any support. So the sooner we can start migrating the better, as migration can take quite some time.

Why Vue?

As of writing this, there are 3 major players in the front-end framework ecosystem: Angular, React and Vue.
It may appear that for most people migrating from angularJS to Angular is a better idea than a different framework. However, this migration is as complicated as any other migration option, thanks to Google’s total rewriting of the angular framework.

I won’t go into the whole process we underwent until finally deciding to go with Vue, but I’ll share the main reasons we chose to do so. You can find a lot of information on various blogs and tech sites that support these claims.

  • Great performance — Vue is supposed to have better performance than Angular and according to some comparisons better than React as well.
  • Growing community and GitHub commits — It is easy to see on Trends that the Vue community is growing with each passing month and it’s GitHub repo is one of the most active ones.
  • Simplicity — Vue is so easy to learn! Tutorials are short, clear and in a really short time, one can gain enough knowledge needed in order to start writing Vue applications.
  • Similarity to AngularJS — Though it is not a good reason on its own, the similarity to AngularJS makes learning Vue easier.

You can read more reasons in THIS fine post.

What was our status when we started?

It is important to mention that our application was and still is in development, so stopping everything and releasing a new version 6 months (hopefully) later was not an option. We had to take small steps that would allow us to gradually migrate to Vue without losing the ability to develop new features in our application going forward.

During the course of the application development, we followed best practices guides such as John Pappa’s and Todd Motto’s.

The final version of our application was such that:

  • All code was bundled with Webpack.
  • All constant files were AngularJS consts.
  • All model classes were AngularJS Factories.
  • All API calls were made from AngularJS Services.
  • Some of the UI was an HTML with controller related to it (especially for ui-route) and some were written as Components (with the introduction of Component to AngularJS in 1.5 version).
  • Client unit testing was written using Jasmine and Karma.

Can it be done incrementally?

Migrating a large scale application such as the one we have into Vue is a long process. We had to think carefully about the steps we would need to take in order to make it a successful one, that would allow us to write new code in Vue and migrate small portions of the app over time.

As you can understand from the above, our code was tightly coupled to AngularJS, such that in order to migrate to Vue some actions were needed to be made prior to the actual migration — and that was the first part of our migration plan.

It’s important to emphasize that as we started the migration, we understood that although the best practices guides mentioned above are really good, they had made us couple our code to a specific framework without a real need to actually do so.

This is also one of the lessons we learned during our migration — Write as much pure JS code as you possibly can and depend as little as possible on frameworks, as frameworks come and go, and you can easily find yourself trying to migrate again to a new framework in 2–3 years. It seems obvious as that’s what SOLID principles are all about, however it’s sometimes easy to miss those principles when ignoring the framework itself as a dependency.

What were our first steps in the migration plan?

So, the actual action items we created as the preliminary stage of our migration plan were detaching everything possible from AngularJS. Meaning modifying code that has little dependencies, but many others depend on it from AngularJS to ES6 style. By doing so we are detaching it from AngularJS ecosystem. Practically, we transformed shared code to be used by import/export instead of AngularJS built-in dependency injection.

To wrap things up, we created the following action items:

  • Remove all const injection to AngularJS and use export statements. Every new const will be added as an ES6 const and will be used by import-export.
  • Update our httpService (which was an AngularJS service) which is the HTTP request proxy in our app. Every API call in our application was made using this service. We replaced the $http dependency with axios and by doing so created an AngularJS-free httpService. Following that, we removed the injection of httpService from every component in our app and included it with an import system.
  • Create a new testing environment using Chai, Sinon, and Mocha, which allows us to test ES6 classes that are not part of the AngularJS app.
  • Transfer all BL services from AngularJS to pure ES6 classes and remove their dependency from our app.
  • Create a private NPM with shared vue controls what will be used by every application we have. This is not a necessity for the first step to full migration, but it will allow us to reuse components across multiple apps and have them the same behavior and styling (which can be overridden of course), which is something that is expected from different apps in the same organization.

What’s next?

As for our next steps, every new feature will be developed in Vue and will be for now part of the AngularJS app by using ng-vue directive, and at the same time, we can start migrating logical components and pages from AngularJS to Vue by leveraging that same great ng-vue directive.

We did migrate one page to ng-vue and added new tests for the vue components we created, in addition to embedding Vuex that will eventually take control of the state data.
Once we finished all the above, we were ready to take the next step of our migration….
More to follow on the next post.

NodeJS MS-SQL integration testing with Docker/Mocha

Author: Zachary Leighton

Integration testing vs. unit testing

Unit tests are great for testing a function for a specific behavior, if you code right and create your “mocked” dependencies right you can be reasonably assured of your code’s behavior.

But our code doesn’t live in isolation, and we need to make sure all the “parts” are connected and working together in the way we expect. This is where integration tests come in to play.

Charlie Sheen didn’t write unit tests, and look where that got him

A good way to explain the difference would be that a unit test would test that a value (let us say an email for simplicity) passes a test for business logic (possibly a regex or something — maybe checks the URL) and the email and rules would be provided as mocks/stubs/hard-coded in the test, while an integration test of this would check the same logic but also retrieve the rules and value from a database — thus checking all the pieces fit together and work.

If you want more examples or want to read up a bit more on this there are great resources on Medium, as well as Stack Overflow, etc. The rest of this article will assume you are familiar with NodeJS and testing it (here we use Mocha — but feel free to use whatever you like).

Pulling the MS-SQL image

He used Linux containers 🙂

To start you’ll want to pull the Docker image, simply run the command docker pull microsoft/mssql-server-linux:2017-latest (Also if you haven’t installed Docker you might want to do that too 😃)

This might take a few minutes depending on what you have installed in your Docker cache.

After this is done, please make sure to right click, go to “Settings…” and enable: “Expose daemon on tcp://localhost:2375”. As we will see in a few sections this needs to be set to process.env.DOCKER_HOST for the Docker modem to run correctly.

Delaying Mocha for setup

Since we need a few moments to spin up the container and deploy the schema we will use the --delay flag for Mocha.

This adds a global function run() that needs to be called when the setup is done.

You should also use the --exit flag which will kill Mocha after the test run, even if a socket is open.

Preparing the run

In this example, we use the --require flag to require a file before the test run. In this file an IIFE (immediately invoked function expression) is used because we need to call some async functions and await them, and then call the done() function from above. This can be done with callbacks but it is not so clean.

The IIFE should end up looking like this:

(async () => {
    const container = require('./infra/container');
    await container.createAsync();
    await container.initializeDbAsync();
    run(); // this kicks off Mocha
    beforeEach(async () => {
        console.log('Clearing db!');
        await container.clearDatabaseAsync();
    });
    after(async () => {
        console.log('Deleting container!');
        await container.deleteAsync();
    });
})();

Spinning up the container from Node

In the above IIFE we have the method container.createAsync(); which is responsible for setting up the container.

const { Docker } = require('node-docker-api');
const docker = new Docker();
...
async function createAsync() {
    const container = await docker.container.create({
        Image: 'microsoft/mssql-server-linux:2017-latest',
        name: 'mssqltest',
        ExposedPorts: { '1433/tcp': {} },
        HostConfig: {
            PortBindings: {
                '1433/tcp': [{ HostPort: '<EXPOSED_PORT>' }]
            }
        },
        Env: ['SA_PASSWORD=<S00p3rS3cUr3>', 'ACCEPT_EULA=Y']
    });
    console.log('Container built.. starting..');
    await container.start();
    console.log('Container started... waiting for boot...');
    sqlContainer = container;
    await checkSqlBootedAsync();
    console.log('Container booted!');
}

The container is created from the async method docker.container.create , the docker instance needs to have process.env.DOCKER_HOST set, in our case we have a local Docker server running (see: Pulling the MS-SQL image) so we’ll use that.

The options come from the modem dockerode and it uses the Docker API.

After the container spins up we need to check that SQL finished running, our port is <EXPOSED_PORT> and the password is <S00p3rS3cUr3> (these are placeholders so make sure you put something valid).

If you want to read more about what is happening here with the EULA option, etc. check out the guide here from Microsoft.

Since it takes a few seconds for the SQL server to boot up we want to make sure it is running before firing off the test suite. A solution we came up with here was to continually try and connect for 15 seconds every 1/2 second and when it connects, exit.

If it fails to connect within 15 seconds something went wrong and we should investigate further. The masterDb.config options should line up with where you’re hosting Docker and on what port you’re exposing 1433 to the host. Also remember the password you set for sa .

async function checkSqlBootedAsync() {
    const timeout = setTimeout(async () => {
        console.log('Was not able to connect to SQL container in 15000 ms. Exiting..');
        await deleteAndExitAsync();
    }, 15000);
    let connecting = true;
    const mssql = require('mssql');
    console.log('Attempting connection... ');
    while (connecting) {
        try {
            mssql.close();
// don't use await! It doesn't play nice with the loop 
            mssql.connect(masterDb.config).then(() => {
                clearTimeout(timeout);
                connecting = false;
            }).catch();
        }
        catch (e) {
            // sink
        }
        await sleep(500);
    }
    mssql.close();
}

Deploying db schema using Sequelize

Fun Fact: Liam Neeson used Docker to release the Kraken as well.

We can quickly use Sequelize to deploy the schema by using the sync function, then as we will see below it is recommended to set some sort of flag to prevent wiping of a non-test DB.

First though, we want to actually create the db using the master connection. The code will end up looking something like this:

async function initializeDbAsync() {
    const sql = 'CREATE DATABASE [MySuperIntegrationTestDB];';
    await masterDb.queryAsync(sql, {});
    await sequelize.sync();
    return setTestingDbAsync();
}

Safety checks

Let’s face it, if you’ve been programming professionally for any reasonable amount of time — you’ve probably dropped a database or file system.

And if you haven’t go run out and buy a lotto ticket because man you’re lucky.

This is the reason to set up infrastructure for backups and other things of the sort, roadblocks if you will, to prevent human error. While this integration test infrastructure you just finished setting up here is great, there is a chance you may have misconfigured the environment variables, etcetera.

I will propose here one possible solution, but feel free to use your own (or suggest more in the comments!).

Here we will use the SystemConfiguration table and have a key value pair on key TestDB that’s value needs to be truthy for the tables to be truncated. Also at multiple steps I recommend checking the NODE_ENV environment variable to be test which can make sure you didn’t accidentally run this code in a non-test environment.

At the end of the last section we saw the call to setTestingDbAsync the content is as follows:

async function setTestingDbAsync() {
    const configSql =
        "INSERT INTO [SystemConfiguration] ([key], [value]) VALUES (?, '1')";
    return sequelize.query(configSql, {replacements: [systemConfigurations.TestDB]});
}

This sets the value in the database, which we will check for in the next snippit. Here is a snippet of code that will check the existence of a value on the key TestDB (provided from a consts file) that we just set.

const result = await SystemConfiguration.findOne({ where: {key: systemConfigurations.TestDB }});
    if (!result) {
        console.log('Not test environment, missing config key!!!!');
        // bail out and clean up here
    }
// otherwise continue

Wiping the test before each run

Taking the code above and combining it with something to clear the database we come up with the following function:

const useSql = 'USE [MySuperIntegrationTestDB];';

async function clearDatabaseAsync() {
    const result = await SystemConfiguration.findOne({ where: {key: systemConfigurations.TestDB }});
    if (!result || !result.value) {
        console.log('Not test environment, missing config key!!!!');
        await deleteAndExitAsync();
    }
    const clearSql = `${useSql}
       EXEC sp_MSForEachTable 'DISABLE TRIGGER ALL ON ?'
       EXEC sp_MSForEachTable 'ALTER TABLE ? NOCHECK CONSTRAINT ALL'
       EXEC sp_MSForEachTable 'DELETE FROM ?'
       EXEC sp_MSForEachTable 'ALTER TABLE ? CHECK CONSTRAINT ALL'
       EXEC sp_MSForEachTable 'ENABLE TRIGGER ALL ON ?'`;
    await sequelize.query(clearSql);
    return setTestingDbAsync();
}
async function setTestingDbAsync() {
    const configSql = "INSERT INTO [SystemConfiguration] ([key], [value]) VALUES (?, '1')";
    return sequelize.query(configSql, {replacements: [systemConfigurations.TestDB]});
}

This will check for the existence of the value for key TestDB in the SystemConfiguration table before continuing. If it isn’t there it will exit the process.

Now how does this run within the context of Mocha?

If you remember in the IIFE we had a call to beforeEach , this is where you want to have this hook so that you have a clean database for each test.

beforeEach(async () => {
        console.log('Clearing db!');
        await container.clearDatabaseAsync();
    });

Shutdown / Teardown

You don’t want to leave the Docker in an unknown state, so at the end of the run simply kill the container, you’ll want to use force too.

Docker reached out to us and said they don’t use exhaust ports

The after look looks like this:

after(async () => {
        console.log('Deleting container!');
        await container.deleteAsync();
    });

And the code inside container.deleteAsync(); looks like this:

async function deleteAsync() {
    return sqlContainer.delete({ force: true });
}

Putting it all together

Since this article was a bit wordy, and jumped around a bit here are the highlights of what to do to get this to work:

  • Delay Mocha using --delay
  • Require a setup script and use an IIFE to set up the container/DB
  • Spin up a Docker container instance, wait for SQL to boot
  • Deploy the schema using Sequelize and also put in a safety check so we don’t wipe a non-test DB.
  • Hook the wipe logic into the beforeEach hook
  • Hook the teardown logic into the after hook
  • Create amazing codez and test them

I hope you enjoyed this article, and suggestions, comments, corrections and more memes are always welcomed.

Good luck and happy testing!

The Leap from .NET to Linux – Using PM2 with sensitive configurations in production

Authors: Shmulik Biton, Ron Sevet

It’s not very often in the career of a programmer that one has the privilege to deploy a brand new application to production. We were lucky to be in that position. This was even more special since this was a completely new technology stack that we were introducing here at Tipalti. Our entire server-side stack is based on .NET and the various Microsoft products that go along with it. We have an extensive experience with .NET’s best practices, tools, how to run our applications and how to secure them.

This wasn’t the case here. Our new application is written in Node.js and we wanted to run it on Linux for better performance. This meant we had to find how to apply the practices and capabilities from our .NET stack on the Linux stack.

We had two major tasks, the first was to find a capable solution for running our node application. We searched around and found PM2. PM2 is a very comprehensive process manager with many useful features. It’s popular, well maintained and looked very promising.

Securing Configurations

After setting up PM2, we needed a way to secure our sensitive configuration keys like DB credentials and alike. In .NET, you can simply use the Windows Protected Configuration API for a seamless experience. Your web.config is encrypted using the user’s credentials and .NET handles it without too much fuss. You don’t need to store any encryption keys next to the config so it’s a pretty good solution.

In Linux, there isn’t something similar, and after some research, we found a best practice that seemed reasonable to us: storing sensitive configurations as environment variables. The reasoning here is that accessing this file requires either root access or the ability to run code on the machine, which in that point there is not much you can do to keep those variables a secret.

At first, all went well. PM2 performed as expected, and using the environment variables was an easy solution.

The issues started after we had duplicated our server and had to change some of those environment variables. We started getting weird errors that we did not see before. We found out that we were still using the old configurations. Using the `pm2 reload` command did not have any effect. Nor the `restart` command or even restarting the server itself. This was very baffling. It turns out that PM2 was the culprit here. One of PM2’s features forces you to explicitly reload environment variables in order to get the updated values. The flag to use is `–update-env`. This seemed to fix the issues we thought the problems are behind us.

We were wrong. After some time has passed another config change was required and this time the flag did not work. Nothing seemed to work. Rebooting the server did not have any effect either. We figured there must be some sort of a cache PM2 was using to store the application state. This was indeed the case.

We used the command `pm2 save` which creates a dump file on ~./pm2/. When the app started/reloaded/restarted it used that dump file to continue where it left off. This behavior was not desired for two reasons: First, it stopped us from updating our configuration. Secondly, it stored sensitive configurations in the home directory of the user running our app. This can potentially expose us to file traversal attack vectors.

Solving the Issue

We solved it by deleting the dump file and stopped using the `pm2 save` command. We also changed the default startup script PM2 creates when you call `pm2 startup`.

This is our final startup script:

[Unit]
Description=PM2 process manager
Documentation=https://pm2.keymetrics.io/
After=network.target

[Service]
Type=forking
User=
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
EnvironmentFile=/your/env/file
Environment=PATH=/usr/bin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
Environment=PM2_HOME=/home/integration/.pm2
PIDFile=/home/integration/.pm2/pm2.pid

ExecStart=/usr/lib/node_modules/pm2/bin/pm2 start /home/integration/.pm2/ecosystem.config.js
ExecStartPost=/usr/lib/node_modules/pm2/bin/pm2 reload /home/integration/.pm2/ecosystem.config.js
ExecReload=/usr/lib/node_modules/pm2/bin/pm2 reload /home/integration/.pm2/ecosystem.config.js --u
ExecStop=/usr/lib/node_modules/pm2/bin/pm2 kill

[Install]
WantedBy=multi-user.target

Note that you need to specify in the startup script the environment file explicitly, otherwise, it won’t load it, and since we are already specifying the file path, we decided to use a dedicated file with root permissions instead of /etc/environment. This would prevent a general process to have access to our configuration.

A quick note on key store solutions: We thought it would add another layer of complexity without adding much security. If someone got root access to the machine they could get the configuration no matter what we do. This is why we decided not to go that route.

In summary

If you want to run a Node.js application under Linux using PM2, these are the steps that we found worked best:

  1. Put sensitive configuration variables in a root accessible file
  2. Do not use the `pm2 save` command
  3. Change the startup script as shown above
  4. Reload your application after changing the configuration using
    `pm2 reload <your config file name> –update-env`