Read our latest: The year so far & 1.0 update.
Complex applications can unsurprisingly have a very large codebase which can be difficult to organise, develop upon, test, deploy and maintain.
Before BRJS we experienced a number of problems:
BRJS resolves these problems. It has resulted in a well organised 250k LoC codebase where the first line of code we write is a feature. The functionality is developed in isolation, code changes can quickly be verified and tests take minutes rather than hours to run. The codebase is updated and maintained by multiple teams who can work on the same application without conflict. And development can start whether or not a back-end services are ready.
The conventions and architecture that BRJS enables and supports mean we can now focus on building features instead of dealing with development workflow problems. This has a very positive impact on developer productivity for both us and our customers.
We’re open-sourcing BRJS because, although there are a number of great developer toolkits and frameworks available (like Yeoman and Mimosa), BRJS is unique in its approach and its support for programming in the large.
As the number of developers creating large-scale front-end web apps increases, we hope that BRJS will turn out to be useful to others. We’re also keen to validate our hunch that it will be equally valuable for building complex applications in domains other than financial web trading applications.
BRJS is fundamentally about following a set of conventions that we've found work when building very large scale applications; it is the tooling that backs these conventions.
BRJS consists of:
In addition to the CLI, a number of commands can also be executed from a web dashboard.
What goes into a Blade?
Because application components are broken down into small pieces of functionality, with assets grouped by feature (not type), and because a blade only interacts with other application features through the EventHub or through services, we can run them in isolation. This has resulted in a feature we're really excited about - workbenches.
Workbenches allow a blade to be developed and run in isolation. They can also be interacted with through their runtime UI or through workbench tools via the EventHub or Services they use.
A Caplin Trader FX Tile Blade running within a Workbench
The Plugin Architecture means that you can create functionality to augment and extend the development workflow.
The plugin interfaces include:
BRJS was designed as a generic framework, but is presently within the codebase of the product (Caplin Trader 3) we have built with it. We’re in the process of decoupling and tidying up some of the rough edges. This will be completed by the end of the month (September) when we will be moving the BRJS codebase to github. So, please watch the repo if you're keen to be an early adopter.
From the end of the month we'll be using github issues to plan our roadmap, track ongoing work, to capture feedback and discuss ideas.