New code cut, tested, and deployed: API v0.0.15 is now serving requests to api.amatino.io. This update is simultaneously big and small. Big because it includes over 10,000 lines of changed, created, or deleted code. Small because there are no changes to the public API. That is, code interfacing with 0.0.14 should be fully compatible with 0.0.15.
Under the hood, those 10,000 lines include a total refactor/rewrite of a major Amatino component. Amatino API is internally partitioned into two major components: An internal API and a public API. The public API serves requests to api.amatino.io: AKA it is what you interface with in your applications. The internal API serves requests within Amatino.
Most of those requests deal with objects that cannot logically be stored in a single physical region. For example, Users, Sessions, Entities, and Global Unit prices. When the public API receives a request dealing with one of these entities, it is forwarded to the internal API.
Until 0.0.15, that internal API was causing major development headaches. It was undocumented and poorly designed. While it could be indirectly tested via the public API test suite, it could not be tested on its own. Error messages were at best vague and at worst totally generic. These characteristics meant that anytime development touched the internal API, it ground to a crawl.
The objective of 0.0.15 was to remove the roadblock. The internal API was redesigned and refactored for simplicity, clarity, and workability. It is now documented, testable, and provides detailed errors when it cannot serve a public API request.
Theoretically, no public interfaces changed. However, there are likely to be uncaught edge cases. If you notice unusual behaviour, or some part of a 0.0.14 library appears to be broken, please contact me at email@example.com. While I can’t guarantee backwards compatibility during this stage of the project, I would like to avoid unnecessary breakages, and I will work to resolve any major issues 0.0.15 has caused.