Most of the services in our microservice oriented architecture at Bench are purely used within the back-end. They communicate via Camel messages and REST calls and do not offer a user interface on their own. They are the small little workers in the background dedicated to their job. Their functionality is indirectly exposed via our web front-end.
Since a big part of our business is doing what a traditional bookkeeping firm does but better, we look at everything -- from customer intake to preparing documents for tax accountants -- as one workflow that we should improve on. As a result, we often identify problems that are unrelated to our primary bookkeeping software that can make our employee’s lives much easier. In those cases, microapps allow us to quickly iterate on ideas and requirements that come straight from any of our departments.
An example is the sales-service; a microservice with a user interface that allows our sales team to coordinate incoming leads in a more efficient and scalable way. At Bench, we call these microservices ‘microapps’, and in this post we’ll cover the technical choices we made to implement them.
When it comes to CSS, everyone seems to have their own approach to naming and organization - we’ve had a few debates about it ourselves at Bench. In this article, we’ll take a look at two of the more popular CSS conventions we considered and show you how we ended up creating our own solution.
Web components are unarguably the Way Of The Future (tm). For better or for worse, and our experience says it's for the better, browsers are going to start supporting native web components, changing the way web apps are thought about and made.
At Bench we really love the microservices approach to application architecture because it allows you to build your own stack and run lightning fast iterations. When we implemented our first microservice one year ago, we had a lot of questions:
1. How do we deploy it, and how can we automate it? 2. How can we make it scalable from the very beginning? 3. What’s the best way to run integration tests against it? 4. What’s the best way to replicate a production environment locally so we can work on it?
Back then we didn’t know the answers, but we had a rough idea and we saw the power of container technologies. After six months of experimentation, we had proven out a few concepts and were ready to launch Project Benchception.
Microservices architecture is becoming very popular now, but it’s not a new concept; a lot of companies are already successfully using it and Bench is one of them. In the beginning, Bench's app was a classic JEE monolith written with Spring and Java, so we've been evolving it by implementing new features using microservices. This post is the first in a series of posts on microservices and it will outline the technologies we’re using to build microservices.
For the summer of 2014, we invited Josh Conley, a talented developer from Toronto, to be our intern. At the time, since our team of developers was quite small for the amount of things we had on our plate, we needed someone who could hit the ground running and contribute from day one.
Scalaz is one of those things that everyone is talking about, but many teams are unsure if they actually want to use it. The question is often, “should we use Scalaz?” but we think the question should actually be “how should we use Scalaz?”
Welcome hackers, contributors, nerds, and other interesting people to our new Developers Blog at Bench!
This is the place where we are going to share all the exciting stuff we work on. At Bench, we use a wide variety of technologies and experiment a lot. You can expect a wide range of topics, from integrating AngularJS with webpack, to developing using Docker containers inside Vagrant. We’ll also be talking about product development and user experience.