# Tools and Technologies

Here we document the reasoning behind certain tools, technology and process choices for Mojaloop. We also have included the recommendation links/versions for each of these tools.

TOOL CHOICES

  • API Development
    • **Open API 3.0 ** is leveraged for API development (Swagger 2.0 earlier).
    • ** ISTIO** as the API Gateway (WSO2 now outdated with Mojaloop v16.0.0 - Congo and IaC v5.0.0 onwards) offers an enterprise platform for integrating APIs, applications, and web services—locally and across the Internet. It also provides Mojaloop with a Security Layer, and Development Portal.
  • Circle-CI - This tool is used for continuous build and continuous deployment. We needed an online continuous build and testing system that can work with many small projects and a distributed team. Jenkins was considered, but it requires hosting a server and a lot of configuration. CircleCI allowed for a no host solution that could be started with no cost and very limited configuration. We thought we might start with CircleCI and move off later if we outgrew it, but that hasn’t been needed.
  • Dactyl – We need to be able to print the online documentation. While it’s possible to print markdown files directly one at a time, we’d like to put the files into set of final PDF documents, where one page might end up in more than one final manual. Dactyl (opens new window) is a maintained open source conversion tool that converts between markdown and PDF. We originally tried Pandoc, but it had bugs with converting tables. Dactyl fixes that and is much more flexible.
  • DBeaver - DBeaver (opens new window) is a free multi-platform database tool for developers, SQL programmers, database administrators and analysts. Supports all popular databases: MySQL, PostgreSQL, MariaDB, SQLite, Oracle, DB2, SQL Server, Sybase, MS Access, Teradata, Firebird, Derby, etc.
  • Docker - The Docker container engine creates and runs the Docker container from the Docker image file.
  • Docker hub is used to link, build, test and push the Mojaloop code repositories. We needed to support both local and cloud execution. We have many small microservices that have very simple specific configurations and requirements. The easiest way to guarantee that the service works the same way in every environment from local development, to cloud, to hosted production is to put each microservice in a Docker container along with all the prerequisites it needs to run. The container becomes a secure, closed, pre-configured, runnable unit.
  • Draw.io – We need to create pictures for our documents and architecture diagrams using an (ideally free) open source friendly tool, that is platform agnostic, supports vector and raster formats, allows WYSIWYG drawing, works with markdown, and is easy to use. We looked at many tools including: Visio, Mermaid, PlantUML, Sketchboard.io, LucidChart, Cacoo, Archi, and Google Drawings. Draw.io scored at the top for our needs. It’s free, maintained, easy to use, produces our formats, integrates with DropBox and GitHub, and platform agnostic. In order to save our diagrams, we have to save two copies – one in SVG (scalable vector) format and the other in PNG (raster). We use the PNG format within the docs since it can be viewed directly in GitHub. The SVG is used as the master copy as it is editable.
  • ESLint - Within JavaScript code, we use ESLint (opens new window) as a code style guide and style enforcement tool.
  • GitHub – GitHub (opens new window) is a widely-used source code repository service, based on git, the standard source code version control system for open source projects. So the decision to use GitHub was straightforward. We create a story every time for integration work. Create bugs for any issues. Ensure all stories are tracked throughout the pipeline to ensure reliable metrics.
  • Helm - The Helm package manager for Kubernetes provides templatized deployments and configurations and allow for overall complexity management.
  • IaC - Infrascture as Code (IaC) is the tooling, scripts used to deploy a Mojaloop platform at the desired quality level, ranging from development, qa or sandboxes to pre-production or even extended for production quality deployments. This uses the Mojaloop releases as the core and deploys the entire supporting toolset needed to run the Mojaloop Platform for a Mojaloop Switch.
  • Kafka - This technology is leveraged to support Mojaloop’s demand for a high velocity and high volume data messaging but keep our hardware requirements minimum.
  • JavaScript - The Mojaloop application is primarily written in JavaScript.
  • Kubectl - This is a command line interface for running commands against Kubernetes clusters.
  • Kubernetes - This enterprise tool provides an extraction layer, infrastructure management and a container-orchestration system.
  • Markdown – Documentation is a deliverable for this project, just like the code, and so we want to treat it like the code in terms of versioning, review, check in, and tracking changes. We also want the documentation to be easily viewable online without constantly opening a viewer. GitHub has a built-in format called Markdown which solves this well. The same files work for the Wiki and the documents. They can be reviewed with the check in using the same tools and viewed directly in GitHub. We considered Google Docs, Word and PDF, but these binary formats aren’t easily diff-able. A disadvantage is that markdown only allows simple formatting – no complex tables or font changes - but this should be fine when our main purpose is clarity.
  • Mojaloop Testing Toolkit (TTK) – Mojaloop Testing Toolkit (opens new window)) is a Swiss-knife tool for Mojaloop related activities, primarily used for end-to-end testing, demonstrations, mocking APIs and in several other extended scenarios. The Mojaloop test collections use the ML TTK and it is the tool of preference for end-to-end testing, which is also integrated into the scripts for automated testing (using TTK CLI in IaC and other dev/qa environments).
  • MySQLWorkbench – MySQL Workbench (opens new window) is a unified visual tool for database architects, developers, and DBAs. MySQL Workbench provides data modeling, SQL development, and comprehensive administration tools for server configuration, user administration, backup, and much more. MySQL Workbench is available on Windows, Linux and Mac OS X.
  • NodeJS - This development tool is a JavaScript runtime built on Chrome's V8 JavaScript engine that runs Mojaloop. NodeJS is designed to create simple microservices and it has a huge set of open source libraries available. Node performance is fine and while Node components don’t scale vertically a great deal, but we plan to scale horizontally, which it does fine. The original Interledger code was written in NodeJS as was the level one prototype. Most teams used Node already, so this made sense as a language. Within NodeJS code, we use Standard (opens new window) as a code style guide and to enforce code style.
  • NPM - NPM is the package manager for Mojaloop since JavaScript is the default programming language.
  • Percona for MySQL - These tools are leveraged as a relational database management system to ensure high performance and enterprise-grade functionality for the Mojaloop system. We needed a SQL backend that is open source friendly and can scale in a production environment. Thus, we chose MySQL, an open-source relational database management system.
  • Postman is a Google Chrome application for interacting with HTTP APIs. It presents you with a friendly GUI for constructing requests and reading responses.
  • Rancher 2.0 - The Infrastructure management, provisioning and monitoring is provided by Rancher 2.0 which is an enterprise Kubernetes platform that manage Kubernetes deployments, clusters, on cloud & on-prem. Rancher makes it easy for DevOps teams to test, deploy and manage the Mojaloop system no matter where it is running.
  • Slack – Slack is used for internal team communication. This was largely picked because several team already used it and liked it as a lightweight approach compared to email.
  • SonarCloud – We need an online dashboard of code quality (size, complexity, issues, and coverage) that can aggregate the code from all the repos. SonarCloud for Mojaloop is free, with some setup. This also offers quality checks on Pull Requests and offers ratings based on the quality gates applied.
  • SourceTree – Sourcetree (opens new window) simplifies how you interact with your Git repositories so you can focus on coding. Visualize and manage your repositories through Sourcetree's simple Git GUI. But this is up to the developer to use their tool of choice following general GitHub recommendations.
  • Visual Studio Code - Visual Studio Code (opens new window) is a code editor redefined and optimized for building and debugging modern web and cloud applications. Visual Studio Code is free and available on your favorite platform - Linux, macOS, and Windows.
  • ZenHub – We needed a project management solution that was very light weight and cloud based to support distributed teams. It had to support epics, stories, and bugs and a basic project board. VS and Jira online offerings were both considered. For a small distributed development team an online service was better. For an open source project, we didn’t want ongoing maintenance costs of a server. Direct and strong GitHub integration was important. It was very useful to track work for each microservice with that microservice. Jira and VS both have more overhead than necessary for a project this size and don’t integrate as cleanly with GitHub as we’d want. ZenHub allowed us to start work immediately. A disadvantage is the lack of support for cumulative flow diagrams and support for tracking # of stories instead of points, so we do these manually with a spreadsheet updated daily and the results published to the "Project Management" Slack channel.

TECHNOLOGY CHOICES

  • Agile development - This methodology is used to track and run the project. The requirements need to be refined as the project is developed, therefore we picked agile development over waterfall or lean.
  • APIs - In order to avoid confusion from too many changing microservices, we use strongly defined APIs that conform to our Pragmatic REST design pattern. APIs will be defined using OpenAPI. Teams document their APIs with Swagger v2.0 or RAML v0.8 so they can automatically test, document, and share their work. Swagger is slightly preferred as there are free tools. Mule will make use of RAML 0.8. Swagger can be automatically converted to RAML v0.8, or manually to RAML v1.0 if additional readability is desired.
  • Automated Testing - For the most part, most testing will be automated to allow for easy regression testing. See the automated testing strategy and code quality metrics for standards.
  • Hosting - Mojaloop has been designed to be infrastructure agnostic and as such is supported by AWS, Azure and On-Premise installations.
  • Interledger – Mojaloop needed a lightweight, open, and secure transport protocol for funds. Interledger.org (opens new window) provides all that. It also provides the ability to connect to other systems. We also considered block chain systems, but block chain systems send very large messages which will be harder to guarantee delivery of in third world infrastructure. Also, while blockchain systems provide good anonymity, that is not a project goal. To enable fraud detection, regulatory authorities need to be able to request records of transfers by account and person.
  • Open source - The entire project has been released as open source in accordance with the Level One Project principles (opens new window). All tools and processes must be open source friendly and support projects that use an Apache 2.0 license with no restrictive licenses requirements on developers.
  • Operating System – Microsoft Windows is widely used in many target countries, but we need an operating system that is free of license fees and is open source compatible. We are using Linux. We don’t have a dependency on the particular flavor, but are using the basic Amazon Linux. In the Docker containers, Alpine Linux (opens new window) is used.
  • Microservices - Because the architecture needs to easily deploy, scale, and have components be easily replaced or upgraded, it will be built as a set of microservices.
  • Scaled Agile Framework - There were four initial development teams that are geographically separate. To keep the initial phase of the project on track, the scaled agile framework (SAFe) (opens new window) was picked. This means work is divided into program increments (PI) that are typically four 2 week sprints long. As with the sprints, the PI has demo-able objective goals defined in each PI meeting.
  • Services - Microservices are grouped and deployed in a few services such as the DFSP, Central Directory, etc. Each of these will have simple defined interfaces, configuration scripts, tests, and documentation.
  • Threat Modeling, Resilience Modeling, and Health Modeling - Since the Mojaloop code needs to exchange money in an environment with very flaky infrastructure it must have good security, resilience, and easily report it's health state and automatically attempt to return to it.
  • USSD - Smart phones are only 25% of the target market and not currently supported by most money transfer service, so we need a protocol that will work on simple feature phones. Like M-Pesa, we are using USSD between the phone and the digital financial service provider (DFSP).

← Pragmatic Rest →

Apache 2.0 Licensed | Copyright © 2020 - 2024 Mojaloop Foundation