# Why we migrated to microservices from Meteor

#### Growth always means change. As Socrates once said, “the secret of change is to focus all of your energy not on fighting the old, but on building the new.”

At Littledata, we’re always [innovating our app](https://blog.littledata.io/2021/08/12/development-sprints-product-innovation/) and building the new. To us, that means finding
better and faster ways to make necessary improvements and
changes.

Our app relies on a sophisticated combination of backend and
frontend technologies. The biggest challenge for us right
now is upscaling the app so we can integrate with other
ecommerce platforms.

At the moment, our platform consists of separate services
and one monolith, the Meteor app, as depicted below:

The architecture worked well for us for a while, and we
enjoyed the speed of engineering Meteor offered to us. But,
at the same time, we faced many limitations which became
obstacles in our path to scaling.

## What are the problems with Meteor?

There’s a handful of limitations we’ve faced using Meteor
that pushed our decision to switch away.

### 1. Overall architecture and maintainability

The idea of having the overall architecture communicate
easily from frontend with backend definitely has many
benefits. This includes only requiring a low level of
necessary code-writing knowledge, as well as speed of
delivery on new solutions.

However, in the long term, it causes many problems with
maintaining the app — things like code readability, hard
unit testing, and slow production bundle deployment.

The deployment slowness is a good example of the
architecture problem overall. We recently migrated to
CircleCI in order to fix the problem, but are stuck with a
meteor limitation.

12 minutes to build and deploy … that’s a lot of time when
you need fast iteration and delivery.

### 2. The Meteor community is isolated

Meteor moves via a self-defined path, quite differently from
standard industry tendencies.

In some ways, that’s a good thing. But if you want to add a
new approach or library to your Meteor setup, you could face
a handful of unexpected problems.

One limitation we’ve encountered is that, instead of
promises, Meteor surprisingly uses a callback to async
functions with the following syntax:

Another is its old school template system based on the
traditional template approach.

That was great for 2000-2010, but in 2021 and beyond, we
have much more efficient techniques to work with frontends
such as React, VueJS, and Angular.

Moreover, it’s becoming harder and harder to find an
engineer who wants to work with a traditional template
system nowadays.

### 3. Difficulty finding engineers to work with Meteor

It’s a challenge to find engineers willing to stick with
Meteor. They usually tend to work with newer, more
well-known tools — ones with more perceived value in the
market.

When evaluating the labour market for front-end and back-end
engineers today, we’ve seen that Meteor is not the main
framework for JavaScript development.

Frontend engineers have consistently preferred to work with
frontend-oriented frameworks like React, Angular, and Vue.JS
because they provide a wide range of instruments.

Unlike the Meteor template system in Vue.JS, we can use the
whole power of JavaScript inside our frontend applications
without being limited to a mere few template commands.

Moreover, we can use many helpful engineering tools such as
autocomplete, linting, and type checking in Vue.JS in order
to make our engineering process more efficient and
enjoyable.

The biggest benefit for us, though, shows in [Vue.JS’ much better scaling](https://vuejs.org/v2/guide/comparison.html#Scale). It has robust routing management, which is important for
a large application like ours.

Meteor, on the other hand, has been steadily losing its
popularity as a framework for backend technology since 2016.

That makes it harder and harder for us to find engineers
willing to work with Meteor in the future.

## How did we migrate away from Meteor?

Though rewriting everything away from Meteor sounded like a
good solution in theory, we realised that path significantly
postponed our main objectives.

So, we had only one solution: to rewrite portionally.

Like many software companies today, and especially fellow
startups, we decided the best solution was to use separate
microservices to maintain and scale our platform.

In part 2 of this post, I’ll share which microservices we
chose, how we use them, and detail the full migration
process away from Meteor.