The technical approach that we had in our work for UbiqiSense

September 16, 2019 5 min. read

You might be curious about the details of our work and how we approach projects from a technical perspective. If you are, in this blog post, we go into detail about our work for UbiqiSense – a young company based in Denmark, which has an exciting product that we helped develop. Here is what UbiqiSense has demanded from us, what we delivered, and how:

The customer’s requirements

We were asked by UbiqiSense to build a web platform for their Internet of Things (IoT) solution. The platform had to have a scalable architecture for getting measurements through the MQTT (Message Queuing Telemetry Transport) protocol. The measurements had to be stored in a database that can be scaled, based on the complexity of each customer’s setup, and on the number of sensors that customers choose to implement in their locations. The web platform also had to provide UbiqiSense’s customers with rich user interfaces where they could visualize their locations’ occupancy, building footfalls (how many people go in and out of rooms), and so on.

The administration part also had to be handled. We also had to build a management dashboard, where organizations can set up UbiqiSense’s solution and their provisioning. Last but not least, we also had to provide customers with 3rd party endpoints (APIs) so that they could integrate the metrics supplied by UbiqiSense’s solution within their business applications.

NOTE: To know more about what this platform does, read: How 3angleTech is contributing to UbiqiSense’s success!

Using 3angleTech’s open-source apps for handling the basics

The truth is that most web apps use the same boilerplate code for handling things:

  • On the client side: authentication, authorization, login, logout, navigation menus
  • On the server side: authentication with the OAuth protocol, support for tests, and database migrations
  • Continuous integration: automatically listen for commits, run tests and push the code to the cloud environments

Our team has created open-source components developed through the projects that we work on, that handle such needs:

The code that we developed uses an MIT license, and customers get to choose if they want us to reuse it for their project too. To make things even better, we do not charge for bootstrapping a project with our predefined templates, as we want to deliver business value as soon as possible. This approach helps us have a great, clean architecture put into place, that can be used to create Minimum Viable Products (MVPs) efficiently. We have learned that it is better to start with a clean open-source architecture, instead of always rewriting the same things for our customers. It improves the speed of implementation, and, in the long term, this approach delivers more value than charging customers for the same boilerplate code being developed for each project individually.

Our first steps in working with UbiqiSense

When we developed the initial proof of concept, we started with the most complicated part of it, to demonstrate that we can deliver fast. That approach means that we could also fail fast. We wanted to discover the main problems sooner rather than later. Initially, only raw data could be extracted from the platform, without any calculation and visualization capabilities. Our initial aim was to arrive as quickly as possible at a point where UbiqiSense could visualize real-time metrics that mattered most to them. To get there, all the components that we created were deployed on Amazon’s Web Services (AWS). We connected a gateway with the cloud solution using the MQTT protocol that is bundled in AWS IoT Core. Then we created an IoT rule that triggers a lambda function which saves the incoming measurement within a NoSQL database in MongoDB Atlas. We created a backend (API) that provides a REST interface with authentication on top of the OAuth 2.0 protocol. The client app (made with Angular) uses the measurements and their data to provide the customer with interactive charts, using the ECharts library. You can see our architecture in the diagram below:

In a matter of weeks, we demonstrated that our architecture works. We also crystalized an easy to use provisioning flow for the physical devices that are part of UbiqiSense’s platform. One exciting aspect is that the devices can reuse the same web app. The same page can be accessed just as easily from a smartphone or a computer, and it can even be included in a later hybrid mobile app.

The challenges that we identified

Both of us at 3angleTech and our customer – UbiqiSense – are small startup-like teams. We performed buddy testing and regular code reviews. Every task had to be deployed fast so that we could catch problems as early as possible, and deliver fast solutions. To capture the errors as quickly as possible, and handle them correctly, we used Sentry. With it, our team of developers monitored and fixed crashes in real time. We were able to iterate continuously and boost our efficiency.

Another challenge was to ensure that everything scaled well, at all times. We had to provide continuous delivery, and problem-free deployments of new features, to all of UbiqiSense’s customers.

The technical solutions that we used for UbiqiSense

We ended up using the following technical solutions for this project:

  • Microservices with Docker instances – using the AWS Fargate compute engine for Amazon ECS, we could run containers without having to manage servers or clusters. With AWS Fargate, we no longer had to provision, configure, and scale clusters of virtual machines to run containers. This removed the need to choose server types, to decide when to scale clusters or to optimize cluster packing. We had a Docker instance for backend API and another for running the client app
  • The Docker instances were tagged with the commit version and pushed to the Amazon ECR (Elastic Container Repository)
  • We automated the deployments of code and new features using AWS CodePipeline – a fully-managed Docker container registry that makes it easy for developers to store, manage, and deploy Docker container images.
  • We externalized the database administrator role, using already provisioned databases from AWS, like Amazon RDS for PostgreSQL and MongoDB Cloud, which provide custom deployments on AWS.

The positive aspects of our approach

The approach that we took has the following advantages:

  • The Backend API project can be further split into subcomponents (microservices) depending on its load, making it scalable for different situations
  • Amazon ECS is capable of automatically opening new task instances on the cloud clusters that we use
  • AWS Application Load Balancer is placed in front of the tasks that are run on Amazon ECS, making sure that we get rid of the scaling problem
  • Because we leverage Docker, the code runs the same way on every environment where it is used

There are other minor benefits that you may identify, but these were the ones that mattered most to us.

How can 3angleTech help you?

Now you know more about one of the best projects that we worked on and the technical approach that we chose. If you enjoyed our approach, feel free to drop us a line and tell us about your software-related needs. Is there anything we could help you with? For more contact options, hit the Contact Us button on the top-right corner of our web page.