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 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. 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.
