We have assisted Forus in building a service for their US Token and an internal administration interface intended for their own use. This article briefly summarizes why such a service exists and the technologies it is built upon to ensure development productivity and service availability.
Jarmo Pertman — 2023-12-06 (4 minute read)
Forus offers an exciting value addition to its customers and partners in the form of tokens. For instance, both passengers and drivers earn tokens for each taxi ride. In 2027, these accumulated tokens can be exchanged for a stake in the Forus company. The idea behind Forus owners is straightforward: those who contribute to the company's development should receive some form of ownership income since it wouldn't exist without them. The token's registrar is a startup called KOOS.
With KOOS serving as the registrar, one might wonder why Forus needs any in-house intermediary service at all. KOOS has a systematic interface (API) that can be directly connected to any Forus service, eliminating the need for an in-house intermediary service. Nevertheless, the only system directly integrated with KOOS in the current solution is Forus' in-house token service. All other Forus services are integrated with the in-house token service that we developed. Essentially, this means that before tokens are reserved for owners in the KOOS environment, this is done in the Forus in-house service.
The in-house service serves several purposes:
In the context of Forus, KOOS primarily serves as the official registrar. Furthermore, KOOS has resolved many legal issues related to the distribution of non-traditional company ownership. For smaller companies, KOOS can provide a complete solution, but from Forus's perspective, it doesn't make sense to put all eggs in one basket. Therefore, the in-house token service is justified for risk mitigation.
Collaboration with KOOS has been smooth, and integration with their API has not proven overly complicated. The service's reliability has also been satisfactory.
Forus' token service is nothing more than an API middleware for KOOS with an administration interface. The service is built using the Phoenix framework and the Elixir programming language. These are modern technologies that create a highly productive, robust, and reliable environment for development and production.
The service is structured so that Forus services communicate through the API layer, encompassing various activities related to tokens. API development follows a principle where communication with KOOS occurs asynchronously whenever possible. For example, when issuing tokens to owners, the request is accepted, but the information is sent to KOOS later as a background process. This approach ensures that Forus applications can continue functioning smoothly even in the event of KOOS service disruptions, and tokens actually are granted to owners sometime later. A synchronous request to KOOS is only performed in extreme cases and is rarely, if ever, done — for instance, when displaying token balances to individuals who have not yet agreed to the service terms.
Forus' token service has been in existence for approximately 1.5 years and has operated very successfully with minimal development work after deployment. This error-free and robust system can be attributed to technological choices and the use of best practices in software development. The codebase is thoroughly covered by unit and integration tests, the service is extensively monitored (for instance, we have been aware of KOOS system issues before their team), data is replicated between multiple data centers in different countries to ensure availability, and the quality of system logs is high, making it quick and easy to find necessary information.
All of the above may seem self-evident for any software project, but unfortunately, most of the time, these principles are not applied. The reasons for this could be ignorance, sloppiness, lack of time, or simple laziness. Sadly, projects like this are often destined to fail from the start.
At first glance, it may seem that there is no business need for creating certain software, but thinking outside the box can reveal various advantages (and, of course, disadvantages) that justify the need for software development. In this project, we actively participated in the project from start to finish, creating the necessary software for the client, along with its surrounding ecosystem for all the availability needs to run in production.
To ensure the success of the project, it is essential to use good practices rather than rushing and taking shortcuts. The software has been in use for approximately 1.5 years by now, during which there have been no critical or less critical bugs discovered, and development work has been minimal, mostly due to new business requirements or changes to the KOOS API.
Solutional is an agile software development company which has a team of professional engineers who are able to solve all software problems from beginning to the end without any middlemen.
Contact us at firstname.lastname@example.org in case you have any new or existing projects needing help with successful execution.