As a backend developer, the Sigfox API is not a really good experience. This for multiple reasons and it is a good example on how a really good product can get a developer push-back just because of the interaction layer.
I can’t change the API itself (and its not y role) but as I was bored to use POSTMAN tool and the Sigfox backend documentation (who already used it will understand) I decided to spend some hours this week to rewrite most of the API endpoint into a clean open-api format into a Spring application to get benefit of the SpringFox swagger front.
This project is not fully terminated but already in place with the most used API endpoint. The next will arrive soon. Read mode to get access.
This post is describing how to setup a Mongo Db database in a clustering mode. I choose to deploy 3 replica set on 3 different bare metal server running centos 7 and to add 1 arbiter to reduce vote problem during a server crash or reboot.
You will find the different steps to make this configuration running, the way to secure it in a vlan and to activate the authentication.
I also added some elements on the way to backup it. Feel free to propose enhancement and links in the comments.
When deploying a API in a scalable environment we usually try tom implement a stateless solution to avoid parallelism conflicts between the different nodes.
This works well for event management synchronously executed. But in some case these event need to have a part of the work managed asynchronously. It was my was my case when I had to process alarm report potentially generating multiple communications with execution time not predictable. To manage this I decided to process theses operation asynchronously. There are multiple architecture for managing this like Queuing (my preferred) of dedicate asynchronous engine. I’ve in fact preferred another way to do it for keeping my infrastructure more simple : adding in all of my nodes a batch function processing the alarms asynchronously.
The alarm events are written into the database and processed by the first of the batch taking it. This allow to preserve a fully redundant and simple architecture. That said I need to ensure only one of the process will execute this process at a time and potentially split the work to do between all the nodes. For making this I had to create a mutex solution.
This post describes the way to create a Mutex solution based on MongoDB with Spring Boot.
When creating an API you can manage a “session” with a JWT Json Web Tokens ensuring the user has login previously.
This post explains how JWT is working and how to implement it with SpringBoot using user identity stored in a Database.
This is based on a real implementation and is the sum of lots of search on Internet to make it correctly working.
SpringBoot is a really efficient framework for creating webservices and much more. For this reason I’m using it to design my backend applications.
This framework is also well referenced on Internet and many people are downloading it and using it. All of this sounds really good and you will see you can make a webservice in less than 5 minutes following the many examples existing on Internet. As usually in this kind of technology once you have made the classical HelloWorld and university classical practices you have a lot of difficulties to make your first real program coupling different simple use-cases. So As I spent a couple of hours searching solution on Internet, this post will give you a full example of a project getting data from a MongoDB instance to provide a simple webservice.