A couple of additional notes. The main focus of the development team for the next couple of months is to bring the platform to the point where it’s possible for developers to start building simple apps. The approach we have chosen is to develop an exemplar App; a User (patron/staff) management App, which effort Mike has decomposed above, in particular; and concurrently enhance the Platform: add features and facilities, stabilize and document interfaces, test integration between various Platform components. The Users App we are building will obviously not exercise all aspects of the Platform, but should cover enough ground to let external developers write similar, CRUD-oriented, Apps (which traditionally form the core of a library system).
As Seb already mentioned, documentation and dev environment are areas of work where we plan to continuously improve. As the Platform reshapes, some docs become out-of-date, while others may represent not-yet-implemented APIs. We’d like to sync them up with the code before sometime early next year. This, however, is an ongoing activity and will remain such for the duration of the project.
Another area, closely related to the the two above, is testing. It’s an integral part of the development process and we certainly do not treat tests as an afterthought. But we want and need better unit test coverage in all Platform components and once the Platform “becomes whole” we will want to focus on integration, stress, performance and scalability tests. The dev environment work, while focused on different goals, goes hand to hand with the work on the continuous integration/continuous deployment systems that are being built to support builds, testing and demos of various components.
Versioning of interfaces and diagnostics and error handling, are part of a larger effort to stabilize the APIs and the tools we use to capture them. We have invested heavily in RAML and JSON schema as the tools to express APIs, but there might be places where those tools are lacking. One such area, potentially, is permissions, where we currently do a lot design and implementation work, We know that clearly capturing permissions will be crucial for cross-module communication and client/UI implementation.
Talking about permissions, they tie into the larger, cross-cutting efforts to design the extensible authentication/authorization subsystem. We would like to close 2016 with a good conceptual model for managing permissions (and their assignments to users and user groups) and, at least, initial implementation.
Another major piece that is worth mentioning is domain modelling, including but not limited to Users (patron/staff/permissions/rules) and KB/RM, and, on a lower-level, implementation of the experimental model on top of a DB engine. Through the course of the project we have evaluated a couple different storage solutions, and while the micro-service architecture is all about choice in this respect, we would like align on a selected solution across the core storage modules. We would like to complete this task in the next couple of months.
To say the least, the next couple of months are going to be quite busy and even more exciting!