Skip to content

Commit

Permalink
Update tools-and-technologies.md
Browse files Browse the repository at this point in the history
Quick minor updates to fix outdated items and added few missing items
  • Loading branch information
elnyry-sam-k authored Apr 9, 2024
1 parent c0bf10c commit d722d9c
Showing 1 changed file with 8 additions and 7 deletions.
15 changes: 8 additions & 7 deletions docs/community/tools/tools-and-technologies.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,8 +5,8 @@ Here we document the reasoning behind certain tools, technology and process choi
**TOOL CHOICES**

* **API Development**
* **RAML** and **Swagger 2.0** is leveraged for API development.
* **WSO2** 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.
* **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](https://github.com/ripple/dactyl) 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](https://dbeaver.io/) 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.
Expand All @@ -16,29 +16,30 @@ Here we document the reasoning behind certain tools, technology and process choi
* **ESLint** - Within JavaScript code, we use [ESLint](https://eslint.org/) as a code style guide and style enforcement tool.
* **GitHub**[GitHub](https://github.com/Mojaloop) 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](https://github.com/mojaloop/ml-testing-toolkit)) 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](https://www.mysql.com/products/workbench/) 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](https://www.npmjs.com/package/standard) 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.
* **SonarQube** – We need an online dashboard of code quality \(size, complexity, issues, and coverage\) that can aggregate the code from all the repos. We looked at several online services \(CodeCov, Coveralls, and Code Climate\), but most couldn’t do complexity or even number of lines of code. Code Climate has limited complexity \(through ESLint\), but costs 6.67/seat/month. SonarQube is free, though it required us to setup and maintain our own server. It gave the P1 features we wanted.
* **SourceTree**[Sourcetree](https://www.sourcetreeapp.com/) 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.
* **Stories On Board** - We use Stories on Board to help capture our high level Epics at a portfolio level before they are commmitted and moved to Github. Our Story Board for Mojaloop is located [here](https://mojaloop.storiesonboard.com/m/ml-phase3-planning)
* **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](https://www.sourcetreeapp.com/) 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](https://code.visualstudio.com/) 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](pragmatic-rest.md) design pattern. APIs will be defined using OpenAPI or RAML. 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. See the [automated testing strategy](automated-testing.md) and [code quality metrics](code-quality-metrics.md) for standards.
* **APIs** - In order to avoid confusion from too many changing microservices, we use strongly defined APIs that conform to our [Pragmatic REST](pragmatic-rest.md) 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](automated-testing.md) and [code quality metrics](code-quality-metrics.md) 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](http://Interledger.org) 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](https://leveloneproject.org/wp-content/uploads/2016/03/L1P_Level-One-Principles-and-Perspective.pdf). 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.
Expand Down

0 comments on commit d722d9c

Please sign in to comment.