Dev Talks: Why We Transformed Native Access

Happy to indulge! Our startup process needed to accomplish a few things:

1. Checking if the user has logged in/logging the user in
2. Installing/Booting up the Daemon
3. Looking for the user's products/purchases in our databases
4. Get all the product information for every product
5. Activate the user's products in accordance to the activation state
6. Fuse the data together, and filter out products that weren't installable
7. Refresh the product states locally based on any potential incoming information

I might be missing a few smaller tasks here, but that's the gist of things. It's all a result of a combined effort from 3 different teams (Daemon, API, and NA2) to make this a reality and improve on the previous version. While NA1's startup flow is also not ideal, our launch version was definitely not in the best state. Some issues we uncovered were:

• Adding a Daemon to the mix added more challenges than we anticipated, as well as an extra step that we cannot circumvent that naturally prolongs the startup times compared to NA1
• Our authorization detection and permission systems were flaky
• All steps were happening sequentially, when some could be done in parallel.
• All of the user's products were being reactivated. This is one of the largest culprits.
• All the products' statuses were updated in our servers to the results of the activation step
• All of the products were then refreshed which would retrigger the activation step unintentionally in some cases
• Our data handling was linear and we needed to control exactly where the data was going. This was another major culprit.
• There were excess calls being made as a result, which overwhelmed our servers at times, especially in cases of high traffic

We decided to go ahead anyway as we already stabilized in Beta to a slightly more satisfactory state, though we were not happy with the state. We planned to kickstart a major overhaul, which we thought would last a quarter. As such, we made the decision to release with goals to go to a "3.0" state soon after. We're still convinced that adding a Daemon alongside a GUI is the right way to go as it makes a lot of things very flexible, for us as well as the rest of the company. We've addressed most of the above pain points with 3.0.0. Now we run things in parallel where it makes sense, eliminated the excess calls and reduce unnecessary traffic, our data management overhaul made it so the data itself reacted to updates handed to it so that more edge cases were addressed, and our next iteration coming within the next two releases will address how and when we activate products. Initial testing shows very promising results for all startup times following the initial startup, for which the extensive duration is due to the Daemon installation and the initial activation within that newly installed daemon.

So this was before my time, so I'll do my best to discuss the details.

Specifically, the vision was a collaborative effort with multiple teams, not just NA1's and another web dev team. We had the idea to build a GUI using web technologies (which I see Tauri does as well) that we could componentize and theme up in an effort to support the future stacks. We wanted to fully separate areas of concern in our stack, from front-end components to back-end services. To make it work with the rest of our web tech stack, we wanted to levy the front-end framework React, which Electron's builder supports out of the box, as the rest of our web stack makes use of it as well. Electron also served all the needs we needed: auto updates, background worker we could channel things through that operated in NodeJS, a separated renderer environment for UI-specific code, a bridge to communicate between the two environments, and webpack to bundle node libraries together, which we needed for our communication bridge between the NTKDaemon and NA2. We do experience some growing pains, such as Electron having some bugs built in that we need to circumvent, and the upgrading of Electron versions is a little rough around the edges in terms of how to get there, but so far it's not blocked us off from delivering value at a rapid rate.

Regarding why not Tauri, IIRC Tauri wasn't around with a stable version until June of this year, so at the time as far as I'm aware Electron was pretty much the best option for us.

So regarding supporting older versions of a specific product: No updates are mandatory for our NI products, therefore in collaboration with CS it is possible to get access to an older version of Traktor for example. We did have some discussions around this already, as the entire system around versioning isn't very user friendly, admittedly. At this stage it's lower priority though, but perhaps we can revisit this nearing the end of the year.

Regarding Native Access/Daemon older version support specifically, this poses a few problems. Daemons update functionality and offer support to older and newer OSes, which is important for all of our products. If we were to support older versions of the Daemon, it would mean newer products/versions of products are not supported out of the box and core issues linger. Our need is to be the first to support a newer operating system, and the last to drop support for one, so that all of our products are covered. To do this we need users on the newest versions, which we want to give them the best possible activation service We'd only ever drop support for an operating system if the entire company has decided to do so, which would therefore only affect older products. It also becomes a nightmare of a spiderweb for our version management. We can't update the Daemon without a corresponding/supported NA2 version, since functionality can be shifted around, so naturally NA2 is in a pickle here too.

What we are looking into is pausing automatic updates, as this is less of a pain. But it still has an effect on our supported product range, so we could end up degrading the download/activation experience unintentionally.

The TL;DR here is that it's a tricky one to tackle, but we're looking into older product version support for sure.

Hey, appreciate the kind words and warm welcome!

1. We're currently not at a point to discuss any future plans on partner integrations just yet. Sorry!
2. We're sitting at around 60%, but we wont factor this in when we proceed with our migration
3. While we plan to get users on modern/supported operating systems on Native Access 2, we are in the midst of discussing a fallback. There are complications that put certain users at risk and we'd like to figure out support alternatives. So we're not killing anything just yet anyway. People who run NA1 on devices NA2 does not support will be excluded from the migration.