We have never been more excited to finally share with the world some massive announcements around the state and future of the JourneyApps Platform.
Over the last decade, JourneyApps has been working on what we refer to as ‘version 4’ of the platform. We have been shipping and supporting many new minor versions of it (v4.x). In its evolving state of the years, V4 enabled all of our customers to build, ship and deploy incredibly robust, scalable and insanely ambitious applications that have stood the test of time in some of the most demanding environments. We are enormously proud of what the platform has enabled our customers to build, and we could not be happier.
But as the saying goes, “The Times They Are A-Changin’” and we recognized almost 8 years ago that we were going to have start looking far beyond the current technology and were going to need to start making many low-level engineering changes to eventually usher in a new version of the product that would truly one day take application development for our customers to the next level.
So today we are proud to announce version 5 of the platform, and with it some game-changing announcements about the future of its development and how the company is fundamentally evolving to support it in a world where more and more projects are being built in the open.
Version 5
V5 represents a massive evolution over V4 as it includes a backwards compatible, nearly full rewrite of the entire runtime. V4 used technology such as AngularJS, Ionic, legacy libraries and required various bootstrap technologies to allow some of the newer features such as Object Tables V3 to run. Furthermore, a large amount of the codebase (although stable) was still written in un-typed JavaScript that made it complex to refactor and introduce new features.
Version 5 improves all of this: we no longer make use of these older technologies as we now have our own performant counterparts, we have written everything in TypeScript, and more importantly, we have built the new engine as a pluggable modular system that can be extended by our customers directly.
V5 is much, much faster than V4
Due to massive improvements in the digest system, the deterministic nature of the new codebase, and removal of many legacy and outdated technologies, version 5 is now notably faster in almost all scenarios. We designed V5 to be smarter around how and when various routines run, how much work gets done, and also introduced better observability between sub-systems allowing for more efficient rendering and computation strategies.
This has led to an average of 2x to 3x performance gains on almost all views we tested. In fact, the more complex an application is, the faster the same application runs in V5. This is due to the exponential nature of how complex applications on average made use of the digest and rendering system.
V5 is now an engine with pluggable modules
We rewrote the runtime from the ground up to be a core engine with many of the existing features moved to modules (runtime extensions). This allows developers to optionally pick and choose the modules they wish to ship with an application, greatly reducing build times, bundle sizes and in general ship less moving parts than needed — reducing computation cycles and removing unnecessary bloat.
Furthermore, all modules are now built on top of the runtime-sdk which means that customers can now make use of this SDK directly to extend and swap out parts of the runtime with
their own modules. We have long been asked about the feasibility of ‘custom components’. Runtime v5 now not only enables that, but extends it to almost every part of the runtime including notifications, app layout, hardware APIs and so much more.
Over the next few months, we are going to be releasing these SDKs so that developers can start extending the runtime engine with their own technologies!
Building in the open
While it’s one thing to have the technology modular and pluggable internally, its usefulness is amplified when it enables and empowers external developers using the platform to utilize SDKs to contribute to and extend core technology.
That is why today we are proud to announce that we have started open-sourcing and moving over various parts of the full technology stack over to JourneyApps Labs.
JourneyApps Labs is a new initiative which will see much of our internal technology finally open-sourced and available publicly on GitHub. JourneyApps has always developed all its in-house libraries and frameworks as if they were products, and this has enabled us to start moving over some technology with incredible velocity.
Some of the projects we have moved over already include:
Reactor
reactor is our in-house IDE framework technology that powers and enables OXIDE, the PowerSync Dashboard, and our internal administration
tool called OVERRIDE:
Carbon
An experimental, but feature-complete visual programming system that was initially in development for customers that wanted to build apps that could be ‘re-programmed’ at runtime by end-users without modifying code.
Introducing a new backend: Sector!
We have also been hard at work cooking up a new next-generation data browser code-named ‘Sector’:
Sector is built on-top of Reactor and provides a data browsing experience on the platform that truly is world-class.
As a result of being a Reactor-based system, Sector provides an experience that allows users to:
- Work with data in panels and in the Reactor workspace.
- Open multiple connections at the same time.
- Work with data fast due to caching and no page reload requirement.
- View data as tables, forms or even as JSON directly in the browser.
- Batch edit data in real-time and preview changes before bulk commiting.
Sector is open-source!
Sector is being developed in the open over at JourneyApps Labs and is even self-hostable with support for static backend API tokens. See Sector on GitHub
Sector is more powerful in the JourneyApps Platform cloud
Sector not only exists as an open-source version, but is also soon being released as cloud software alongside OXIDE. This version of Sector has everything the open-source version has, but with everything else the current (legacy) backend data browser provides.
This includes features such as:
- Webhook management
- Audit logs
- Managing API tokens
- And so much more!
Sector even works inside OXIDE
As if having a new data browser self-hostable and available part of the platform was not enough, we have also utilized the intrinsic property of Sector being part of Reactor to enable embedding Sector directly in OXIDE. Very shortly, developers in OXIDE will have direct access to deployment data in separate workspaces without needing to leave their development environment. What’s more, Sector inside OXIDE deeply integrates into the app development lifecycle and includes deep linking between live data and the schema views developers are used to within OXIDE.
Thoughts? Feedback? Let us know.
We want to hear from you. Join us on our community Discord server with any feedback.
