Skip to Content

Blog Archives

Dev jobs: A microservices architecture journey

Recently at Tangosource I was assigned to work on an internal project named Dev Jobs (see dev jobs on iOS and dev jobs on Android), where I had the chance to work next to great teammates and implement a microservice architecture with Ruby on Rails, nodeJS, JWT, Ionic, Docker, and several testing tools, including RSpec, Mocha, Frisby, and Protractor. In this first post, I’ll explain the basics of the microservice architecture.

What is a Microservice Architecture ?

Martin Fowler gives a great definition.

[1]“The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”

The Problem

Let’s have some context. We are building a server side application that must support different client side platforms such as:

  • Desktop browsers
  • Mobile browsers
  • Native mobile applications

 

Also, we need to consume an external API service. In our case, Linkedin through Oauth2 for authentication. And the ability for users to chat between each other.

On an architectural matter we still had to decide between monolithic or microservice. So let’s dig a little more on this two.

Monolithic vs MicroServices

Monolithic

If we take this approach, we need to keep the following in mind:

  • Build one application to rule them all.
  • Use one language ( Ruby, PHP, JavaScript, etc. ) we could not take any extra advantages from other programming languages.
  • The architecture needs to be flexible enough to support API through AJAX and render HTML.
  • The development team needs to feel comfortable with the language we picked.
  • Security. We will have a public API to serve mobiles/clients.
  • Best tools for RTCP. So we can have a nice looking chat
  • Testing. build testable code

 

I have seen great monolithic architectures that can support all of this. One of my favorites is RoR engines based or nodeJS services based applications.

MicroServices

In the other hand, if we go for MicroServices we must take in mind the following:

  • Delegate responsibilities in small applications.
  • We can use different languages per service. Which is the best choice per responsibility?
  • How are we going to communicate each service ? Normally with tcp/ssl.
  • How are we going to persist Data through services?
  • Security: Protect the services.
  • Testing: Test all microservices.

 

On a personal note, as a developer working on a microservice platform, I can focus only on the technical details wrapping a specific service. This does not mean I should not understand the whole set of services as a unit.

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

— Melvyn Conway, 1967

Having this in mind, we had to start by making technical decisions, such as how to protect our API, how to manage RTCP, by nature HTTP is stateless which means is sessionless so for our case we had to maintain a session through tokens ( JWT ), at first we though maybe nodeJS for RTCP since nodeJS is strong for DIRT ( Data Intensive Real Time )  apps. But we had not only had to take care of the tech devs but also for dev resources, currently at TangoSource we have strong Ruby on Rails devs so we had to work all together and take advantage of the expertise of each team member, our best bet was to use RoR for business logic, and take advantage of nodeJS. So the combination of RoR and nodeJS makes the solution solid and strong.

Solution

For this particular project, we decided to go for the MicroService and have some fun! The first thing that we needed to figure out was defining the responsibilities per service. So we end up with 4 microservices.

  • Ionic
    • More than a service, it’s the client side of the application. Ionic by itself is a front end SDK for hybrid mobile apps using AngularJS.
  • IDP
    • Responsible for (a) providing identifiers for users looking to interact with a system, (b) asserting to such a system that such an identifier presented by a user is known to the provider (c) possibly providing other information about the user that is known to the provider.
    • This may be achieved via an authentication module, which verifies a security token, and that can be accepted as an alternative to repeatedly and explicitly authenticating a user within a security area.
  • SP
    • In charge of persisting all user’s data, including interaction with the system. This service will contain all the business logic
  • Chat
    • In charge of establishing real-time communication among users within the system.

 

We decided to protect the services with JWT

Architecture

devjobsarchitecture

Each square represents a service, and the lines are how they communicate between each other.

Ionic : This might be the most critical service of them all, but not the most important. We have 3 main components:

  • Ionic server
    • An HTTP server in charge of sending all the assets ( HTML, CSS, JS ) to the next component.
  • Ionic Cordova
    • A Mobile SDK, which provides the user’s interaction with the app, and consumes the rest of the microservices as resources. This component runs on top of 3 different type of devices.
      • Android
      • Ios
      • Browser
  • Ionic App
    • Ionic admin panel, this panel allow us to configure GCM and APNS exposing a protected API.

 

IDP : This service is in charge of giving identity to a component/user. This service will expire a valid token with a component/user’s basic information on the JWT’s payload. Similar to memoization, this service will keep track of sessions using Redis on a basic TLS connection. Thanks to the RFC 7519 standard, this service can scale in other microservice based architectures and be reused.

SP : This is an API/Https service protected with JWT. This micro service is in charge of persisting all user’s interaction/information using MySQL with a standard TLS connection. It also manages the business logic.  

Chat : This microservice will provide real-time communication between users. This RTCP (real time control protocol) is being protected with JWT on the handshake process, and persists the communication activity on MongoDB, a NoSQL database.

Conclusion

Taking these kind of decisions is not simple. It requires a lot of experience in order to compare libraries/languages, you must at least know how they work, and it’s even better if you have used them. Remember that you will not build this by yourself, you are part of a team. It’s smart to sit with your team and discuss each individual’s strengths and weaknesses in order to make the best tech decisions.

DO NOT mix responsibilities of the micro services, instead identify your services. Add all the needed documentation to help the team such as /*Comments */,  READMEs, and Wikis.
A microservice architecture is not always the best approach, and could be painful if you are not careful.

3 8 Continue Reading →

Angular.JS controller communication

AngularJS is a Javascript framework made by Google. Over the last few years, its popularity has increased exponentially. Its main features are double data binding, DOM control, form validation and the use of reusable components. Plus, it’s fairly easy to use, which makes AngularJS one of the top choices when looking for a Javascript framework.

When we start working with Angular, we come to this question very quickly: how can we set our controllers to communicate with each other? Which option is the best?

It is typically assumed that in Angular.js there should be only one controller per view. Sometimes, however, we have no choice but to have two controllers within the same page, and they will need to interact with each other.

Given that, I’ll go into some of the typical scenarios and how to handle the communication among controllers for each of them. I hope this is of help for some of you.

Father and Son

This is when we have a controller inside another controller. So let’s say that our markup looks like this:

The problem would be, how can we access the model inside the child controller? If we want to get info already set in the other controller, then we could do something like:

But this only works for reading the value that has been already set. If that value changes, our variable in the controller will not be updated. We could fix that with the following code:

But watch out, an even better solution arrives! AngularJS provides us with some amazing functions that we can take advantage of:

This function broadcasts an event to all children controllers. All the controllers that are listening for the ‘name’ event will get notified. The $broadcast function could be useful if you wanted to send information from the parent controller to a child controller.

On the other hand, if what you wanted was to communicate from a child to its parent, we use this method:

Finally, ‘on’ allows us to define which methods we are listening to. It listens for the ‘name’ event‘ emitted’ or ‘broadcasted’ methods depending on the case.

Communication from parent controller

Here’s an example:

In this example, we are sending a message every time that our variable ‘something’ changes in the parent controller. Use of $watch is not necessary. What we need to keep in mind is that our child’s controllers and listener for the event needs to be defined before broadcasting

Communication from child controller

Here’s some markup example for this situation:

And the code:

As you can see, the parent controller is listening for a ‘new message’ event. While in our child controller we are emitting this event every time we call ‘tellToMyParent’. We are calling that function when we click on the ‘Say it’ button, and it is sending the value of the $scope.message, which, in this case, is the value in the textbox.

Brother controllers

The idea sounds pretty good, right? Unfortunately sometimes this isn’t as easy as it sounds. There will be some situations on which we have brother controllers, and we can’t get them to communicate without the use of a parent controller.

Here’s some sample markup:

We know that there is one $rootScope for the Angular application and that we could take advantage of that. The code inside the controllers is interpreted in the child scope. And, if the property does not exist in the child scope, then Angular will look for the parent scope, ending at $rootScope. You can take advantage of this to help them communicate.

For example:

Great, but there is only one thing left: if we use $rootScope.$on in the controller, this will create duplicate bindings. That is because controllers can get instantiated multiple times (every time the user enters the view, basically). So we need to be careful with that and find a way to avoid adding duplicate listeners, which could affect the application’s performance very drastically.

So, we still have one option left. That is, combining broadcast and services; services only get instantiated once, unlike controllers.

Examples:

First option; simple set and get:

Second option, combination with $broadcast:

So, we have reviewed a few different ways of handling communication between controllers depending on the situation. As you can see, Angular.js is very flexible with this, but that does NOT mean that we should not to try to look for better implementations and follow best practices. What do you think about these options to communicate controllers? Do they seem useful? Have you found better ones? Feel free to share in the comments.

Thanks for reading!

J.

0 5 Continue Reading →