Skip to main content

Arkitekt Next

Developing the Arkitekt Platform is an ongoing process. While we are happy with the released version of Arkitekt, we are always looking for ways to improve the platform and make it more user-friendly, stable, and reliable. After having adapted the platform to a set of applications, we have now learned a lot more about the needs of users and are working on a lessons-learned-version of Arkitekt that will address the most dire pitfalls of the current version.

From here be dragons

We are working tirelessly to bring the next version of Arkitekt to you. Currently we are stepping into a pre-alpha phase and are looking for early adopters that want to help us test the new version of Arkitekt. If you are interested in testing the new version of Arkitekt, please go ahead and check out the installation instructions for the next version of Arkitekt. Rest assured that the "paper version", will remain available and rest frozen in time to ensure reproducability of the paper.

The shape of things to come​

While we could dicusss hours about the new features of the next version of Arkitekt, we have decided to focus on the most important ones here and give you already a sneak peak of what is to come, this is by no means a comprehensive list of all the features that we are working on, but it should give you a good idea of what to expect.

Improved User Experience​

Users, Users, Users! While we want Arkitekt to be a powerful tool for bioimage analysis, we also want it to be easy to use. Let's face it, if you followed the tutorial and got your first workflow running you saw all of the hurdles. This is why we are working hardcore on improving the user experience of Arkitekt. starting with Orkestrator our desktop control app. Here we are focusing on the following areas:

Improved Design and Layout​

The design and layout of "Orkestrator" boasts a lot of features and functionality, but it is not very user-friendly. With the new interface we are working on, we are aiming to make the platform more user-friendly and intuitive, streamlining the UI and UX. Here is a sneak peak of the new design:

The new design will hopefuly feature a more intuitive layout, with a focus on the most important features of the platform. You'll be able to easily navigate between different sections of the platform, and access the most important features with just a few clicks. Also interlinking between the different parts of the platform will be more intuitive and easier to understand. Images will become front-and-center in the new design and exploring ROIs and measurements should be more intuitive.

For Developers

Orkestrators new design is based on the shadcn/ui and follows a more stricter design system. For you as a developer this should also make it easier to create your own apps that follow the same design pattern.

No more Reservations​

While Johannes was desperately trying to make reservations work, we realized that the concept of "reserving" a node was not very intuitive and was causing a lot of confusion (additionally it was a source of many bugs). So we got rid of it ! The new version of Arkitekt will allow you to assign tasks to nodes directly without having to reserve them first. B

Look how easy it is to start a task:

Two clicks and you are done. No more reservations, no more waiting for the node to be available. Just start your task and let Arkitekt do the rest. The context menu is still a work in progress and we are working on improving the user experience of the context menu. You might have notced that "Available to install" section. This is a new feature that integrates closely with the new App Store that we are working on. More on that later.

Don't you worry

Reservations are not entirely gone, but their purpose has shifted: they can now be used to predefine the parameters for batch-tasks to make them both more easy to start and more efficient. You just don't have to think about them to much anymore

Improved Workflow Design​

Designin visual workflows should be a breeze and honestly in Orkestrator is currently a bit complex and not very intuitive. We have reworked and are continuing to iterate on the workflow design and making it more intuitive. The new prototype alreadly includes features such as auto node suggestion, auto-repair of broken workflows, and more and uses design patterns that users are already familiar with from other workflow design tools like Blender or Unreal Engine. Here is a sneak peak of the new design:

Note

It's still not perfect, so please please suggest improvements and let us know what you think.

The App Store​

Feel like installing a new app? In Arkitekt-Next this should be no problem. We are working on a new App Store that will allow you to easily install new apps and plugins to extend the functionality of the platform. We will have some commnuity repositories enabled by default, but you can still use the old mechanism to install apps from your own repositories. Here is a sneak peak of the new App Store:

On Engines

Kabinet the new App-Store backend service, follows are complety different design on deploying apps. While the old Plugin-System deployed containers directly on the server, the new App-Store provides the backbone for different "Engines" (again, just Arkitekt Apps), that can connect to the server and deploy apps on any infrastructure. Want to deploy apps on your own cluster? Just create an Engine App for that cluster, install it on the cluster and connect it to the Arkitekt Instance.

For Developers

With this approach, we can rely more heavily on the ingenuity of software packages like Helm and Kubernetes to deploy apps, and can focus on the development of the platform itself. If you want to see what happens an earily prototy is here

Improved Data management​

Data management is a major pain point in the bioimage community and we are hoping to address some outstanding issues with next version of Arkitekt. Here we are focusing on the following areas:

Introducing the Knowledge Graph and Ontologies​

A vision of Arkitekt was to capture the reality of biological systems in a database that allows users to create arbitraty measurements and interactively link them to each other. But the current version of Arkitekt does not fully allow to capture the intricacies of biological interactions intuitevely. The next version of Arkitekt will introduce the Knowledge Graph a new feature that will allow users to assign meaning to their analyzed data following a more natural language based approach (e.g. this ROI delineates an Axon) and link them to other data (e.g. this Axon is connected to this Dendrite). For this Arkitekt will now feature a Graph Database (based on the amazing Apache AGE project) that will allow users to interactively create and explore the relationships between their data using their own vocabulary.

This short video illustrates a very manual approach of labeling and assigning meaning to ROIS in an image. Of course the process shoud be ideally automated, but maybe it can give you an idea of what we are aiming for.

On Ontologies

Ontologies and Knowledge Graphs are a huge topic and are sadly not coverable in this short introduction. We will of course provide more information on how to create and use ontologies in the next version of Arkitekt in the documentation, and explain you how they might just help to make your data and your knowledge more sharable.

What we are aiming for it to interlink your Knowledge Graph with your data and metadata, and to allow you to interactively explore the relationships between your data and metadata. We want Programmers and Database savy people to use standard graph query languages to interact with the Knowledge Graph, and non-programmers to use a more intuitive interface to explore the relationships between their data and metadata.

note

This is a prelimnary version of the Knowledge Graph and we are working on improving the user experience and the features of the Knowledge Graph. We would like to tightly integrate the Knowledge Graph with the Views and Protocols features of the next version of Arkitekt.

Introducing Views​

Metadata management is hard. To often does the metadata get lost or is not properly documented, and often because the metadata system is to rigid to accomodate the needs of the users. The next version of Arkitekt will introduce the concept of "Views". Views are ways to describe the metadata of your data in a flexible way respecting the multi-dimensionality of your data.

  • Your first channel of the image is supposed to be displayed in a certain color? Just add a RGBView to that channel.
  • You want to describe the acquisition parameters of your image? Just add a AcquisitionView to the image.
  • One of your Lab reagents was used to stain an image? StainViews to your rescue.
  • You want to indicate that this images pixel values represent labels (in a segmentation Map), just add a PixelView to the image, and map the labels to your Knowledge Entities.

While your image-data might never change, the way you describe it can be as flexible as you need it to be, and we hope it can evolve in the same way your data does.

Introduction of Protocols​

Where Metadata is a way to describe your imaging data, some metadata is more structured than others. For all the none structured information we have worked on "Protocols", that allow you to describe the steps of your image analysis using natural language and rich text editing. They can still interlink data and metadata, but are more focused on the analysis steps that you have taken to arrive at your image.

On Protocols future

Protocols are one of these features that are highly experimental and might not make it into the final version of Arkitekt. They are currently to broad in scope and might just live in an outside software that can be integrated with Arkitekt. Our goal is not to reinvent word processing software but to provide a way to interlink your analysis steps with your data and metadata. So if you have suggestions ! Right away!

Other stuff​

While the above features are the most important ones that we have been working on, we are also working on other features that will improve the platform.

Introduction of Rooms​

LLMs are everywhere. While their ability to facilitate image analysis with scientific scrutiny is debatable, they are a great way to interact and discuss with your data. The next version of Arkitekt will introduce the concept of "Rooms". Rooms are a way to create a virtual space where you can interact with your data, and discuss with your colleagues but also with "AI Agents", that can help you with your analysis. In full Arkitekt style these agents are just pluggable apps that can be added to your room and can help you with your analysis.

Here is a sneak peak of the new rooms feature

Agents are Apps

As Agents are just Arkitekt Apps, you can just download differently enabled apps from the app-store and can (potentially if you allow) have access to your whole arkitekt functionailty. This highly experimental agent here can browser all of your lab functionality and start analysis tasks (like the simulated acquistion task lasting 5 seconds) in your name. But you can imaging purely analytical agents that have access to your data and can help you with your analysis.

On Open-source LLMs

While nobody stops you form creating an Arkitekt App that uses your OpenAI API key to interact with an LLM, in full Arkitekt Style you can bundle your arkitekt server with Ollama a LLM backend that all agents can hook into and use, without sending data to the cloud.

Arkitekt For Real Time Streams​

When talking about Streams most people think about video streams, but in the context of Arkitekt as a streaming analysis platform, we talk about streaming analytical data. These to concepts ironically could not be more different, so much so that Arkitekt didn't even have support for streaming videos in the first place. Well that is about to change. The next version of Arkitekt will introduce the concept of "Streams" a way to have stream real-time (video) data to the platform and other connected apps. Want to stream data from your microscope to your Orkestraor instance? Well thats what we are working on. Here is a sneak peak of the new streaming feature

VIDEO HERE

On Streams

Streams are a highly experimental feature and are not yet fully implemented. We are working on integrating the Streams more tightly in a collaboration with OpenUC2, so stay tuned.

Livekit

The new streaming feature is based on the amazing Livekit project, that allows for real-time video streaming through WebRTC and will allow for a performant and reliable streaming experience utilizing losless compression. The setup is a bit more complex than the rest of the platform, but we are working on making it as easy as possible to set up.

Stateful Apps​

Your microscope has a phisical position of the stage that you want to display to the user before he moves it and break the objective? Not possible in the old version of Arkitekt. Going to be possible in the next version of Arkitekt. We are working on introducing the concept of "Stateful Apps" that can publish their state to arkitekt for users to remotely inspect. This is a highly experimental feature and we are working on making it as easy as possible to implement. Heres a sneak peak of the new feature api


from arkitekt_next import register, state, background
from my_custom_api import listen_to_stage_position, move_stage


@state
class MyState:
    position_x: float = 0.0
    active_objective: str = "40x"


@register
def change_x_position(state: MyState, x: int) -> int:
    state.position_x = position_x
    time.sleep(5) # Simulating move
    return state.position_x



@register
def change_objective(state: MyState, objective: str) -> str:
    state.active_objective = objective
    time.sleep(5) # Simulating move
    return state.active_objective


@background
def listen_to_stage_change(state: MyState):
    # constantly runs in the background checks some external API for changes
    # of course this could also be a callback
    for state_change_event = listen_to_stage_position():
        state.position_x = state_change_event.position_x

On the Danger of State

Stateful Apps are a highly experimental feature and can lead to a lot of confusion and bugs, because state is just aweful. We are working on making the state management as easy as possible and clarifiyng the purpose of state: to provide ui feedback to the user, and not to store data. We will only release the state feature once we have established some programmatic guardrails to prevent misuse (e.g. if your app tries to update its state in the millisecond interval and crashes the server, we will have to intervene).

Stability Upgrades​

Stability is a major focus of the development on Arkitekt Next. As the platform grew organically out of our research needs, some parts of the platform are not as stable as we would like them to be. We are working on improving the stability of the platform and making sure that it is robust and reliable. Here we are focusing on the following areas:

Adressing Failure Hell​

One of the arguabily biggest features of the Arkitekt platform is its ability to have applications run code that depend on other applications. May it be that you schedule a workflow on one app, that calls a plugin on another app. Or when when you have written a plugin that internally calls another plugin.

This is a powerful feature, but our current implementation is not as stable as we would like it to be. Especially when apps fail, and we have to cascade the failure to other apps that depend on the failed app. Currently propagating this change to the next app needs is handled on the client side, and is therefore not as reliable as we would like it to be. The next version of Arkitekt will adress this feature and make sure that the platform is more robust by introducing an automatic way to handle the cascading failure of tasks on the server side.

Adressing Apps without Servers​

Arkitekt is buld around the concept of apps that want to connect to the platform. But this platform is by design modular as we wanted to make it easy for sys admins to only choose the modules they need. Do not care about mikro? Just don't install it. Kluster is exactly what you want because you have a dask-cluster? Just add it in your docker-compose file.

So how do we make sure that the apps can find services that they need to connect to? The Arkitekt answer to this is "Fakts", a small protocol that we developed for the service discovery inside Arkitekt. And it does work great for its intended purpose. However while transitioning from the Paper version to the Next version we realized that apps do not really have a way of declaring specific version requirements and communicate them before they are installed. This is a major issue as it can lead to the installation of apps that are not compatible with your underlying services. Fakts next will adress this issue and make sure that the platform is more robust and reliable by introductin dependencies to the Fakts protocol, which are declared in the app manifest and can stop you from installing an app that is not compatible with your services.

The old manifest
name: "My App"
version: "1.0.0"
The new way
name: "My App"
version: "1.0.0"
dependencies:
    - kluster: "live.arkitekt.kluster@paper"
    - mikro: "live.arkitekt.mikro@paper"
    - rekuest: "live.arkitekt.rekuest@next"
Breaking changes

This is probably the biggest breaking change in arkitekt and will hinder old apps from connecting to the platform. We will update the existing apps to the new manifest format, but you might have to update your apps to the new manifest format as wll.

Improved Documentation​

We are working on improving the documentation of Arkitekt. While the current documentation is comprehensive, it can be overwhelming for new users. While we will keep the expert section we will also add a new section for beginners and intermediate users, that will guide them through the platform step by step. We are also working on improving the search functionality of the documentation, so that users can easily find the information they are looking for. All of which has not yet happend.

Improved Backend Stack​

We are working on improving the backend stack of Arkitekt. Currently Arkitekt is built on top of a stack of Graphene, Django, and Postgres. While We are happy with the two latter, Graphene has some limitations and we are going to replace Strawberry which is a new GraphQL library that provides a more type safe and intuitive API. This stack is is already powering everything that you are seing here, and we are working on making it more stable and reliable.

Performance Updates​

A major focus of the development on Rekuest will be on improving the performance of the platform, when assigning tasks. While the current version of Arkitekt is not slow by any means, we are working of scqueezing out every bit of performance from the platform, when it comes to distributed task assignment. One such tasks is going to be the introduction of "ephemeral" tasks that will not have to be stored in the database and can be assigned directly to the worker. This feature does not yet exist, but we are working on it.

Improved API Design​

We are working on improving the API design of Arkitekt. While the current API is powerful, it does not follow all the best practices. THe next version of Arkitekt will have a more consistent and intuitive API based on the GraphQL best practices.

Improved Security​

We are working on improving the security of Arkitekt. While currently Arkitekt is secure by design, most security features are not enforced. The next version of Arkitekt will have more security features and we hope to enforce them by default.