TNID, blockchain solutions for phone numbers

TNID, latest technology.

TNID is a web application built with C# and ASP .NET core 6.0 and running in Azure App Services. It consists of a frontend built with React, a GraphQL API and some Azure functions and we use KeyCloak as identity provider. Through the frontend, customers affiliated with TSG SMS can create campaigns using the user-friendly web GUI. TNID then sends the campaigns to the appropriate organizations and ensures that each mutation is captured in a blockchain implementation running in AWS.

The GraphQL API is intended for operators who want to automate this process and possibly perform it in bulk. Again, every mutation is recorded in our blockchain. Both the frontend and the GraphQL API use KeyCloak as the identity provider and this runs in a container in Azure Container Instances. The Azure functions implement a retry mechanism that ensures that in case of a problem in one of the backend APIs, the campaigns are offered again later.

We deploy with CI/CD pipelines from Azure Devops and use Git based source control. Sonar Qube is integrated for automated code quality assessment and we require at least 80% code coverage for unit tests. We review each other's pull requests and after review we deploy directly to the development environment and test environment. After the customer tests and approves the changes in the test environment, the application is automatically pushed to the production environment.

Ricky's personal role and experience.

My involvement during this project included unlocking the back end APIs. I built two services used by the Azure functions in sending the campaigns to the APIs. To the GraphQL API, I added the part to create new campaigns and in addition, I participated in the blockchain implementation.

The best part of this project was the innovative techniques I was allowed to use.

It was my first introduction to a tool like SonarQube and a new development in APIs like GraphQL. In addition, I found the blockchain technology very interesting to work with. I had already read a lot about blockchain, but now for the first time I could see for myself in practice how blockchain works. Very educational.

Just about every organization uses multiple software solutions for administrative matters. Those systems do not stand alone. Information captured in one system may be needed in another. A simple example is timekeeping. The information captured in such a system is needed for invoicing, which is done with another system. The Hub-X project aims to develop an application with which we want to provide a low-threshold solution to these types of "integration" issues.

hub-x, microservices architecture.

Hub-X is built according to the microservices architecture. It consists of connector services and customer services. The connector services are the components that retrieve information from or send information to a specific system. The customer services use the connector services and they ensure that the information retrieved by a connector service is transformed appropriately so that it can be sent by another connector service to a system that uses that information. So we can quickly and easily connect new customers by building a customer service for each new customer that performs the desired transformations and uses existing or possibly new connector services. Customers can choose to run their own customer service in our shared platform, but for heavy workloads or high confidentiality requirements, they can also choose a dedicated solution.

This allows us to connect new customers quickly and easily by building a customer service for each new customer

use of new, innovative technology.

Whenever possible, we use the latest techniques and practices. Hub-X runs in Kubernetes and is built with C# and .NET core 6.0. We deploy with CI/CD pipelines from Azure Devops and use Git based source control. Sonar Qube is integrated into the pipelines for automated code quality assessment and we require at least 80% code coverage for unit tests. We review each other's pull requests and after review we deploy directly to the development environment. Currently, our shared Hub-X platform is running in Azure Kubernetes Services. The intention is that in the future we can also offer Hub-X as a dedicated solution to customers and give them the choice to run in Azure, AWS or on their own infrastructure on Rancher. We will then define our own pipeline in Azure DevOps for each customer who wishes to do so.

kubernetes in azure.

In this project, I was mainly involved in setting up the Kubernetes environment on Azure. I really enjoyed this, as I had been following the developments around Kubernetes and related technologies for a while. In the past, I had already given a presentation to colleagues on this topic in the context of knowledge sharing. Before that, I had built a small sample application that was hosted in a local test cluster. Nice, but too small to really learn all aspects of Kubernetes. Now I got a chance to use Kubernetes in practice and the specific problems I ran into in setting up a product worthy environment accelerated the depth of my knowledge.