Rafiki Work Week
From August 26th-30th was the third edition of the Rafiki Work Week - and it included by far the most participants! We were welcomed by the Breakpoint IT team in their offices in Cluj-Napoca, Romania, and around 30 of us from different organizations (ILF, Breakpoint IT, GateHub, People's Clearinghouse (Mexico), and JoPACC (Jordan)) spent five days working on all things related to Rafiki.
We split into teams to focus on seven different tracks:
1. Multi-tenancy
This feature will allow a Rafiki instance to manage multiple tenants, each with their own peering relationships, supported currencies, and Open Payments resources - reflecting a use case where a Rafiki is deployed at a payments switch. This feature that arose from our partnership with JoPACC given their payments architecture, and together with a representative from the organization, we were able to finalize a design for multi-tenant Rafiki and begin its implementation after multiple discussions and requirement-setting.
2. JoPACC integration
Being able to work alongside a representative from JoPACC, we continued advancing the Rafiki/Open Payments integration into the JoPACC payment system.
3. People's Clearinghouse integration
Together with five members of the People's Clearinghouse (PCH), we discussed several outstanding requirements of the PCH x Rafiki integration, and what could be done in Rafiki to meet those needs. We now have a few new issues on the project board and merged PRs in the Rafiki repo, thanks to contributions from the PCH developers. Next steps for the PCH integration & production deployment in preparation for the summit (and beyond) were planned as well. Our tech writers spent time with the PCH team for a deep dive into some of the hurdles that the PCH developers faced deploying Rafiki as part of their stack to get a better idea into how we can improve and add clarity to our documentation for integrators.
4. Interledger Platforms
Outside of Rafiki source code, we have a lot of different documentation platforms, blogs, and sites to manage, especially nearing the summit. Other than making navigation between our different blogs much clearer, we began designing and developing the summit schedule - an integral part of the summit experience.
5. Rafiki Performance
Before a beta release, we want to understand the performance of Rafiki. During the work week, we added measurements in critical points of the software, trying to load the system, and analyzed where we can make performance improvements. A few caching opportunities and optimizations were achieved, and the team was able to increase the performance of the system on some specific areas. We came up with a plan to continue identifying quick performance wins, while also examining overall architecture of Rafiki with the objective to increase its long-term performance and scalability.
6. Test wallet backend integration changes
Currently, the test wallet, rafiki.money, is integrated with a payments & KYC API called Rapyd. Since the API is running in a sandbox environment, it has a rate limit, which is less than ideal for handling a lot of users at once, particularly for hackathons. During the week, work was started to replace Rapyd with GateHub's backend API services for key wallet functions instead. This will be a much better long term solution, as GateHub will be able to better handle increased load.
7. Documentation
Having writers, developers and integrators all in one room, it was a great opportunity to discuss and finalize the Rafiki documentation additions, restructuring and overall improvements. We now have published these redesigned docs on rafiki.dev. You should now have a better reading experience, whether you are a developer, an integrator, or an administrator. Of course, please let us know if you have suggestions on how we can continue improving our documentation.
Alpha 16 Release
At the beginning of the work week, we released Alpha 16 (and a minor follow-up, Alpha 17) which included a few main features:
New Admin APIs
We added "actionable" incoming payments, which allows ASEs to synchronously approve or cancel incoming payments if they would like to run particular checks when an incoming payment is created on their Rafiki instance. In addition, we added a resolver for paginating over outgoing payments, with an option to filter by receivers (incoming payments).
Optional Kratos
In Alpha 10, we added mandatory user authentication for the frontend Admin UI via an integration with open source Ory Kratos package. Understanding that some integrators already have their own systems for admin-user authentication, we now made Kratos (and the frontend package integration) optional. This can be toggled via AUTH_ENABLED in the frontend package.
Performance related changes
After adding additional traces and metrics in Rafiki, we now have a performance testing script to be able to stress test the local playground. Before, and during the work week, it helped us to quickly identify quick performance wins. One of these performance gains was part of this latest release, and should significantly speed up the speed of transaction processing if you are running accounting using Postgres.
Next steps
We are continuing to work hard on the tasks outlined from the work week, and gearing up for a final release before the Hackathon (October 19th - 20th) and ILF Summit (October 26th - 27th) in Cape Town (https://interledger.org/summit).
See you there!
Top comments (0)