Are you working with an ocean of microservices connected together by a message broker like RabbitMQ? Then there is a chance you have experienced queues filling up and messages not reaching their destination, most likely due to stability issues in your architecture of services.
If you want to know how our engineers investigate such issues, and why they built a tool called RabbitIO that helps them with this, then this post is for you.
Haven’t we all been a bit nervous at times about pressing that “Deploy” button, even with amazing test coverage? Especially in the scary world of microservices (aka distributed systems) where the exact constellation of services and their versions is hard to predict.
In this post I will introduce the Synthetic Monitoring concept, which can make you feel more confident about your production system because you find errors quicker. It focuses on improving your Mean Time to Recovery (MTTR), and gathering valuable metrics on how your whole system behaves.
The Meltwater Mobile application development team was formed in 2014 and has grown from 3 to 18 members. We build native apps for both iOS and Android platforms. Usage of the native apps has grown in sync with the growth of the team size.
In part 1 of this series we discussed what went into my team’s decision to move to VIPER as our app development architecture. In the second part of this series we will share our experience and provide some lessons learned. Hopefully reading about our experience will make your move a little bit easier.
Examplr is a lightweight tool for adding examples to your Node.js project. With Examplr, you write the smallest amount of code possible to demonstrate the critical elements of your module: the configuration, the input, and the output.
In this post Evan, the main contributor to Examplr, guides you though adding your first example, advocates why examples are awesome for any project, and shares a real use case often encountered by his team.
The Meltwater Mobile application development team was formed in 2014 and has grown from 3 to 18 members. We build native apps for both iOS and Android platforms. Usage of the native apps has grown in sync with the growth of the team size.
In this post we want to share how we have reinvented and refocused the way we build our native apps by adopting VIPER as our foundation. Part 1 of this two part series discusses how we arrived at VIPER as our underlying architecture and why it turned out to be the right choice for us. The journey to VIPER was not easy, nor was it one we wanted to take, but now that we have crossed over the chasm of fear we are on a solid path to future success.
If your team is considering moving to VIPER you might just be convinced to “go for it” by reading our story.