DEV Community: Patric Genfer

Isolating Microservices to Improve their Availability

Patric Genfer — Tue, 09 Jan 2024 08:30:00 +0000

TL;DR: Designing microservices is always a trade-off between data consistency and service availability. This post shows how data replication and asynchronous communication can enhance service isolation to improve a system’s robustness.

Microservices, as an architectural paradigm, streamline the development and deployment of complex systems by emphasizing a crucial characteristic: Service Isolation. This isolation entails each microservice acting as an autonomous unit, encapsulating a distinct part of the business logic. In line with domain-driven design principles, these services also define their own bounded context, enabling individual development, updates, and maintenance without impacting the wider system.

However, sometimes, our business cases are too complex to be handled by a single service alone. For solving these more sophisticated use cases, several services must interact and exchange data. Communication then often happens through direct API calls between services, e.g., using synchronous protocols like HTTPS or gRPC.

This typical interaction pattern creates a strong coupling by making our services dependent. While generally manageable, these dependencies pose a risk: a network error in a low-level service could easily disrupt substantial portions of our system. Moreover, updating interconnected components becomes tough, potentially causing prolonged maintenance downtime due to the ripple effect of a single update across multiple nodes.

This post will investigate how we could isolate our microservices better and make them more robust against network failures by using asynchronous communication and data redundancy. However, we will also see that improving our system's availability comes with the cost of having temporary data inconsistencies.

Our Example System: A Typical Online Shop

As an example system, we will use a small microservice architecture representing a typical online shop backend (and parts of the frontend).

With our shop, customers can select and order different products. Our focus for today lies only on the checkout process, where customers are presented with a list of their chosen products, their address, and payment method and can then proceed with the actual purchase.

The checkout page of an online shop, showing the customer's address, their shopping cart and a button to proceed with the checkout.

The Microservice Architecture

Each part of our domain is implemented through a separate service. For instance, the Customer Service is responsible for storing and managing all customer-relevant master data, like their names, addresses, payment methods, or contact information. Our system uses a shared-nothing approach, so each service manages its own database others cannot access directly.

The second service we will focus on is the Order Service, which implements the whole checkout process, also presenting an overview of the customer address, the payment method, and the chosen products to the user. It requests this information by calling other services directly.

An excerpt of our microservice architecture. The ordering process is implemented as a separate microservice. The user interacts with the service through the checkout-page web frontend.

Processes like shipping, payment, etc., are also extracted into separate services. However, for now we will focus mainly on the Customer and Order service.

Of course, this is just a very minimalistic example architecture. Real-world systems are often much more complex. But for our use case, let's assume this architecture is sufficient.

Managing the Checkout Process

While our Order Service encapsulates most of the logic required for the checkout process, it still needs to collect data like the shipping address or the payment method by calling the Customer Service directly through a synchronous connection.

While this communication creates a strong coupling between both services, it guarantees that the address and payment data we present are always up-to-date since the Customer Service will always provide us with the most recent version of the records stored in its database.

When the network functions within standard parameters, this solution works well and offers seamless communication. However, network unpredictability, caused by issues like misconfigurations, sudden surges in requests, or potential DDoS attacks, can render servers unreachable. What makes it worse is that the strong coupling we implemented between our services makes our systems even more vulnerable to such network failures:

Imagine the user has chosen some products and proceeds to the checkout page, where the Order Service tries to receive the customer's address from the Customer Service, which, unfortunately, became unresponsive due to a network issue. Instead of showing the correct information, we would rather have to print an error message to the user:

Worst case scenario: We cannot continue the checkout process because the service providing our customer's address is down - Okay, true, the error visualization is a bit striking, but I'm sure you get the idea...

That's really daunting: We used microservices in the first place to make our services more independent and fortify our system against failures, and now, a single service breakdown halts our core business functions. This situation is particularly troubling as it would cost us real money: The customer's purchase was disrupted, potentially leading them to seek the product elsewhere.

Undoubtedly, the strong interdependence between our services is the root cause of this error. Still, we have to exchange data somehow, so coupling can't be avoided - or is there a better way to transfer information while keeping the coupling to a minimum?

As you may have guessed, there is a different approach. But before going into details, we must first dive a bit deeper into distributed systems and their properties - welcome to the CAP theorem!

The CAP Theorem - Trade-Offs in Distributed Systems

The CAP theorem, first postulated by Eric Brewer, is a rule that applies to distributed computer systems. It states that within such a system, it's impossible to guarantee availability and data consistency simultaneously. In case of a network error, one always has to choose between one of the two.

The CAP Theorem describes the trade-offs among Consistency, Availability and Partition Tolerance in Distributed Systems.

If we look at our example architecture from above, we decided implicitly for consistency: Our customer data is stored at a single location, and all access goes through the Customer Service. In that way, we guarantee that customer-related information is always up-to-date. However, according to the CAP theorem, by focusing on consistency, we now can no longer guarantee availability when a network error occurs. If we cannot reach the Customer Service anymore, our checkout process can't continue. The customer data is still consistent - we just cannot reach it!

So, was it a good choice to go towards consistency and against availability? Well, it depends... While in many cases, consistency is essential, there are often scenarios where availability may be preferable for the price of having potentially inconsistent data.

Let's see how we would have to change our system to favor availability and what the implications would be.

Redesigning our System towards Availability

While our initial design intended to use one service per bounded context, some of our services were more built around entities than actual use cases. Take, for instance, our Customer Service: Its primary purpose is to manage customer entities, and as such, it's mainly only a gateway to the underlying database. Services like these are also considered entity services, and can be problematic as they enforce other services to create strong couplings with them.

Unfortunately, this coupling also drives our architecture towards Consistency and away from Availability. So let's see how we could untie our connections a bit.

Step 1: Replicating Data

Our Order Service is obviously not autonomous enough, requiring additional information from other services to complete the checkout task. To address this, we will establish a dedicated database for the Order Service where all relevant customer data is replicated.

By doing so, the Order Service will be self-sufficient without relying on external providers. This setup guarantees that even if the Customer Service is inaccessible, our Order Service will remain operational.

The Order Service replicates the customer's address in its own data store. In that way, all required data is available during checkout, even if the Customer Service is unreachable.

But wait, does that mean that we have to store everything twice? And by replicating the data, are we not violating the DRY principle? Well, that's the price we have to pay for better availability. There is no free lunch, not even when developing complex distributed systems. But note that both services do not necessarily have to store the same view of the data. While the Customer Service may keep a more detailed version, like a primary or secondary address or even a complete history, the Order Service only needs the most rudimentary information to complete the checkout.

While our change makes the service self-containded, it has a drawback:

Since we now store our data at two locations, how do we keep both databases in sync, e.g., when a customer updates their address?

Well, to solve this, we have to rethink how our service communication works...

Step 2: Using Asynchronous Communication

While we could reduce the interconnection between our two services by using a dedicated database for each, we still need some kind of connection to initially transfer the data and keep it in sync later. Our current communication model uses direct synchronous API calls. Again, this creates a strong dependency because the caller needs to know the exact details - like the endpoint address - of the API it wants to call.

We can reduce the coupling here by switching from the technical level towards a more domain-driven thinking: A user changing their address is an essential action in our system. Hence, we should also consider it a domain event that needs to be propagated, and services interested in it should get notified about the change and update their state accordingly,

This is a good use case for applying the asynchronous Publisher-Subscriber pattern: All services are connected to a message broker. In case of an address change, the Consumer Service publishes a customerAddressChanged event, and other participants, like the OrderService, can subscribe to this type of event and get notified when it gets distributed. Upon arrival, they update their database record, ensuring all services have the same consistent dataset again.

A change in the customer address results in sending a domain event through the Customer Service. The Order service reacts to this event and updates its address data accordingly.

The result is not so bad: In case of a (partial) network failure, the user can continue the checkout process, and the data we operate on should remain up-to-date.

That's definitely an improvement to our initial design. Still, we're not done yet. There is one crucial edge case we have to take care of.

Step 3: Handling Data Inconsistencies

By improving our system's availability, we unfortunately reduced its consistency. Think, for instance, what would happens if our message broker goes down due to a network error, or, for whatever reason, a recent address change is not propagated correctly to other services?

In that case, the Order Service would show an outdated address during checkout. While the service is still reachable, we can not guarantee that its data is consistent with the rest of the system.

Luckily, we have an easy workaround: We can add a Change Address button next to the address field, allowing the user to update the information manually if necessary.

Letting users manually change their address can be a fallback mechanism in case of inconsistencies.

Sure, this may be annoying for the user - "I just updated the address in my profile; why does this not show up here?" - but it's still better than canceling the whole checkout process due to an unreachable service.

Of course, before the shipping starts, we somehow have to bring our different addresses in sync again, but this can happen long after the checkout is completed (that's why we speak from eventual consistency here - there will be a point in time when our data is synchronized again, although this may not happen immediately).

Conclusion

Developing complex distributed systems, especially within microservices, presents a balance between autonomy and interdependence. While synchronous communication ensures data consistency, it creates a strong coupling between services and amplifies vulnerability to network failures.

Data replication and asynchronous communication can help isolate services and strengthen system resilience but may introduce occasional data inconsistencies. Which approach to choose highly depends on the use case. In our concrete example, there is a clear benefit of being available over being consistent since potential inconsistencies can be corrected manually if necessary. Also, since a customer's address may not change that often, chances that updates are not arriving due to network downtime may be less likely.

But there are also cases where availability may be more critical: Showing the total order sum requires us to have accurate pricing information at any time. This is a scenario where eventual consistency would not be sufficient enough. The same is true for validating the payment. We must ensure that the payment information our system processes is correct when finishing the order. Otherwise, we cannot continue with the shipping.

In essence, the optimal choice between consistency and availability always hinges on the specific demands of the concrete domain and business case.

Moving from Electron to Tauri 2

Patric Genfer — Thu, 27 Apr 2023 19:00:04 +0000

Part 2: Local Data Storage — Implementing a database backend in Rust for a Tauri application.

TL;DR: Several file-based embedded database wrappers are available for Rust. This article examines some of them and demonstrates how to incorporate them into an application written with Tauri and Rust.

This is the second post on porting UMLBoard to Tauri. While the previous article focused on interprocess communication, this time, we will examine how we could implement the local data storage subsystem with Rust.

~~Porting inter-process communication to Tauri~~ (see last post)
Accessing a document-based local data store with Rust (this post!)
Validate the SVG compatibility of different Webview
Check if Rust has a library for automatic graph layouting

To achieve this, we will first look at some available embedded datastore options for Rust and then see how to integrate them into the prototype we created in our last post.

But before we start coding, let’s glimpse at the current status quo:

Basic Architecture

The current, Electron-based UMLBoard main process uses a layered architecture split into several application services. Each service accesses the database through a repository for reading and writing user diagrams. The datalayer uses nedb, (or better, its fork @seald-io/nedb), an embedded, single-file JSON database.

This design allows for a better separation between application code and database-specific implementations.

Porting from Typescript to Rust

To port this architecture to Rust, we must reimplement each layer individually. We will do this by defining four subtasks:

Find a file-based database implementation in Rust.
Implement a repository layer between the database and our services.
Connect the repository with our business logic.
Integrate everything into our Tauri application.

Following the strategy from our last post, we will go through each step one by one.

1. Finding a suitable file-based database implementation in Rust.

There are numerous Rust wrappers for both SQL and NoSQL databases. Let's look at some of them.
(Please note this list is by no means complete, so if you think I missed an important one, let me know, and I can add it here.)

1. unqlite A Rust wrapper for the UnQLite database engine. It looks quite powerful but is not actively developed anymore -- the last commit was a few years ago.

2. PoloDB A lightweight embedded JSON database. While it's in active development, at the time of writing this (Spring 2023), it doesn't yet support asynchronous data access -- not a huge drawback, given that we're only accessing local files, but let's see what else we have.

3. Diesel The de-facto SQL ORM and query builder for Rust. Supports several SQL databases, including SQLite -- unfortunately, the SQLite driver does not yet support asynchronous operations[^1].

4. SeaORM Another SQL ORM for Rust with support for SQLite and asynchronous data access, making it a good fit for our needs. Yet, while trying to implement a prototype repository, I realized that defining a generic repository for SeaORM can become quite complex due to the number of required type arguments and constraints.

5. BonsaiDB A document-based database, currently in alpha but actively developed. Supports local data storage and asynchronous access. Also provides the possibility to implement more complex queries through Views.

6. SurrealDB A wrapper for the SurrealDB database engine. Supports local data storage via RocksDB and asynchronous operations.

Among these options, BonsaiDB and SurrealDB look most promising: They support asynchronous data access, don't require a separate process, and have a relatively easy-to-use API. So, let's try to integrate both of them into our application.

2. Implementing a Repository Layer in Rust

Since we want to test two different database engines, the repository pattern looks like a good option as it allows us to decouple the database from the application logic. In that way, we can easily switch the underlying database system.

Defining our repository's behavior in Rust is best achieved with a trait. For our proof-of-concept, some default CRUD operations will be sufficient:

// Trait describing the common behavior of 
// a repository. TEntity is the type of
// domain entity handled by this repository.
pub trait Repository<TEntity> {
    fn query_all(&self) -> Vec<TEntity>;
    fn query_by_id(&self, id: &str) -> Option<TEntity>;
    fn insert(&self, data: TEntity) -> TEntity;
    fn edit(&self, id: &str, data: TEntity) -> Option<TEntity>;
}

Our repository is generic over its entity type, allowing us to reuse our implementation for different entities. We need one implementation of this trait for every database engine we want to support.

Let's see what the implementation will look like for BonsaiDB and SurrealDB.

BonsaiDB

First, we declare a struct BonsaiRepository that holds a reference to BonsaiDB's AsyncDatabase object we need to interact with our DB.

pub struct BonsaiRepository<'a, TData> {
    // gives access to a BonsaiDB database
    db: &'a AsyncDatabase,
    // required as generic type is not (yet) used in the struct
    phantom: PhantomData<TData>
}

Our struct has a generic argument, so we can already specify the entity type upon instance creation. However, since the compiler complains that the type is not used in the struct, we must define a phantom field to suppress this error.

But most importantly, we need to implement the Repository trait for our struct:

// Repository implementation for BonsaiDB database
#[async_trait]
impl <'a, TData> Repository<TData> for BonsaiRepository<'a, TData> 
    // bounds are necessary to comply with BonsaiDB API
    where TData: SerializedCollection<Contents = TData> + 
    Collection<PrimaryKey = String> + 'static  + Unpin {

    async fn query_all(&self) -> Vec<TData> {
        let docs = TData::all_async(self.db).await.unwrap();
        let entities: Vec<_> = docs.into_iter().map(|f| f.contents).collect();
        entities
    }

    // note that id is not required here, as already part of data
    async fn insert(&self, data: TData, id: &str) -> TData {
        let new_doc = data.push_into_async(self.db).await.unwrap();
        new_doc.contents
    }

    async fn edit(&self, id: &str, data: TData) -> TData {
        let doc = TData::overwrite_async(id, data, self.db).await.unwrap();
        doc.contents
    }

    async fn query_by_id(&self, id: &str) -> Option<TData> {
        let doc = TData::get_async(id, self.db).await.unwrap().unwrap();
        Some(doc.contents)
    }
}

Rust doesn't yet support asynchronous trait functions, so we must use the async_trait here. Our generic type also needs a constraint to signal Rust that we are working with BonsaiDB entities. These entities consist of a header (which contains meta-data like the id) and the content (holding the domain data). We're going to handle the ids ourselves, so we only need the content object.

Please also note that I skipped error handling for brevity throughout the prototype.

SurrealDB

Our SurrealDB implementation works similarly, but this time, we must also provide the database table name as SurrealDB requires it as part of the primary key.

pub struct SurrealRepository<'a, TData> {
    // reference to SurrealDB's Database object
    db: &'a Surreal<Db>,
    // required as generic type not used
    phantom: PhantomData<TData>,
    // this is needed by SurrealDB API to identify objects
    table_name: &'static str
}

Again, our trait implementation mainly wraps the underlaying database API:

// Repository implementation for SurrealDB database
#[async_trait]
impl <'a, TData> Repository<TData> for SurrealRepository<'a, TData> 
where TData: Sync + Send + DeserializeOwned + Serialize {

    async fn query_all(&self) -> Vec<TData> {
        let entities: Vec<TData> = self.db.select(self.table_name).await.unwrap();
        entities
    }

    // here we need the id, although its already stored in the data
    async fn insert(&self, data: TData, id: &str) -> TData {
        let created = self.db.create((self.table_name, id))
            .content(data).await.unwrap();
        created
    }

    async fn edit(&self, id: &str, data: TData) -> TData {
        let updated = self.db.update((self.table_name, id))
            .content(data).await.unwrap();
        updated
    }

    async fn query_by_id(&self, id: &str) -> Option<TData> {
        let entity = self.db.select((self.table_name, id)).await.unwrap();
        entity
    }
}

To complete our repository implementation, we need one last thing: An entity we can store in the database. For this, we use a simplified version of a widespread UML domain type, a Classifier.
This is a general type in UML used to describe concepts like a Class, Interface, or Datatype. Our Classifier struct contains some typical domain properties, but also an _id field which serves as primary key.

#[derive(Debug, Serialize, Deserialize, Default, Collection)]
#[collection( // custom key definition for BonsaiDB
    name="classifiers", 
    primary_key = String, 
    natural_id = |classifier: &Classifier| Some(classifier._id.clone()))]
pub struct Classifier {
    pub _id: String,
    pub name: String,
    pub position: Point,
    pub is_interface: bool,
    pub custom_dimension: Option<Dimension>
}

To tell BonsaiDB that we manage entity ids through the _id field, we need to decorate our type with an additional macro.
While having our own ids requires a bit more work on our side, it helps us to abstract database-specific implementations away and makes adding new database engines easier.

3. Connect the repository with our business logic

To connect the database backend with our application logic, we inject the Repository trait into the ClassifierService and narrow the type argument to Classifier. The actual implementation type of the repository (and thus, its size) is not known at compile time, so we have to use the dyn keyword in the declaration.

// classifier service holding a typed repository
pub struct ClassifierService {
    // constraints required by Tauri to support multi threading
    repository : Box<dyn Repository<Classifier> + Send + Sync> 
}

impl ClassifierService {    
    pub fn new(repository: Box<dyn Repository<Classifier> + Send + Sync>) -> Self { 
        Self { repository }
    }
}

Since this is only for demonstration purposes, our service will delegate most of the work to the repository without any sophisticated business logic. For managing our entities' primary keys, we rely on the uuid crate to generate unique ids.

The following snippet contains only an excerpt, for the complete implementation, please see the Github repository.

impl ClassifierService {

     pub async fn create_new_classifier(&self, new_name: &str) -> Classifier { 
        // we have to manage the ids on our own, so create a new one here
        let id = Uuid::new_v4().to_string();
        let new_classifier = self.repository.insert(Classifier{
            _id: id.to_string(), 
            name: new_name.to_string(), 
            is_interface: false, 
            ..Default::default()
        }, &id).await;
        new_classifier
    }

    pub async fn update_classifier_name(
        &self, id: &str, new_name: &str) -> Classifier {
        let mut classifier = self.repository.query_by_id(id).await.unwrap();
        classifier.name = new_name.to_string();
        // we need to copy the id because "edit" owns the containing struct
        let id = classifier._id.clone();
        let updated = self.repository.edit(&id, classifier).await;
        updated
    }
}

4. Integrate everything into our Tauri application

Let’s move on to the last part, where we will assemble everything together to get our application up and running.

For this prototype, we will focus only on two simple use cases:

(1) On application startup, the main process sends all available classifiers to the webview (a new classifier will automatically be created if none exists), and
(2) editing the classifier's name via the edit field will update the entity in the database.

See the following diagram for the complete workflow:

The second use case may sound familiar: We already implemented it partially in our last post, but without persisting the changes to a database backend.

Last time, our service implemented an ActionHandler trait to handle incoming actions from the webview. While this approach worked, it was limited to only a single type of action, the ClassifierActions.

This time, we have more than one action type: ApplicationActions that control the overall program flow and ClassifierActions for behavior specific to classifier entities.

To handle both types uniformly, we split our trait into a non-generic ActionDispatcher responsible for routing actions to their corresponding handler, and an ActionHandler with the actual domain logic.

Our service must implement both traits, first the dispatcher

// Dispatcher logic to choose the correct handler 
// depending on the action's domain
#[async_trait]
impl ActionDispatcher for ClassifierService {

    async fn dispatch_action(
        &self, domain: String, action: Value) ->  Value {

        if domain == CLASSIFIER_DOMAIN {
            ActionHandler::<ClassifierAction>::convert_and_handle(
                self, action).await
        } else  if domain == APPLICATION_DOMAIN {
            ActionHandler::<ApplicationAction>::convert_and_handle(
                self, action).await
        } else {
            // this should normally not happen, either 
            // throw an error or change return type to Option
            todo!();
        }
    }
}

and then the ActionHandler for every type of action we want to support:


// handling of classifier related actions
#[async_trait]
impl ActionHandler<ClassifierAction> for ClassifierService {

    async fn handle_action(&self, action: ClassifierAction) -> ClassifierAction {
        let response = match action {
            // rename the entity and return the new entity state
            ClassifierAction::RenameClassifier(data) => {
                let classifier = self.update_classifier_name(
                    &data.id, &data.new_name).await;
                ClassifierAction::ClassifierRenamed(
                    EditNameDto{ id: classifier._id, new_name: classifier.name}
                )
            },
            // cancel the rename operation by returning the original name
            ClassifierAction::CancelClassifierRename{id} => {
                let classifier = self.get_by_id(&id).await;
                ClassifierAction::ClassifierRenameCanceled(
                    EditNameDto { id, new_name: classifier.name }
                )
            },
            // return error if we don't know how to handle the action
            _ => ClassifierAction::ClassifierRenameError
        };
        return response;
    }
}

// handling of actions related to application workflow
#[async_trait]
impl ActionHandler<ApplicationAction> for ClassifierService {
    async fn handle_action(&self, action: ApplicationAction) -> ApplicationAction {
        let response = match action {
            ApplicationAction::ApplicationReady => {
                // implementation omitted
            },
            _ => ApplicationAction::ApplicationLoadError
        };
        return response;
    }
}

The dispatcher's ActionHandler calling syntax seems odd but is needed to specify the correct trait implementation.

With the ActionDispatcher trait, we can now define our Tauri app state. It contains only a dictionary where we store one dispatcher per action domain. Consequently, our ClassifierService must be registered twice since it can handle actions of two domains.

Since the dictionary owns its values, we use an Atomic Reference Counter (Arc) to store our service references.


// the application context our Tauri Commands will have access to
struct ApplicationContext {
    action_dispatchers: HashMap<String, Arc<dyn ActionDispatcher + Sync + Send>>
}

// initialize the application context with our action dispatchers
impl ApplicationContext {
    async fn new() -> Self { 
        // create our database and repository
        // note: to use BonsaiDB instead, replace the database and repository
        // here with the corresponding implementation
        let surreal_db = Surreal::new::<File>("umlboard.db").await.unwrap();
        surreal_db.use_ns("uml_ns").use_db("uml_db").await.unwrap();
        let repository = Box::new(SurrealRepository::new(
            Box::new(surreal_db), "classifiers"));

        // create the classifier application service
        let service = Arc::new(ClassifierService::new(repository));
        // setup our action dispatcher map and add the service for each
        // domain it can handle
        let mut dispatchers: 
            HashMap<String, Arc<dyn ActionDispatcher + Sync + Send>> = 
            HashMap::new();
        dispatchers.insert(CLASSIFIER_DOMAIN.to_string(), service.clone());
        dispatchers.insert(APPLICATION_DOMAIN.to_string(), service.clone());
        Self { action_dispatchers: dispatchers }
    }
}

The last part is easy again: We update our Tauri command and choose the correct dispatcher depending on the incoming action:

#[tauri::command]
async fn ipc_message(message: IpcMessage, 
    context: State<'_, ApplicationContext>) -> Result<IpcMessage, ()> {
    let dispatcher = context.action_dispatchers.get(&message.domain).unwrap();
    let response = dispatcher.dispatch_action(
        message.domain.to_string(),
        message.action).await;
    Ok(IpcMessage {
        domain: message.domain,
        action: response
    })
}

Et voilá:
It was quite some work, but everything fits together now:
We can load our entities from the database, let the user change an entity's name, and persist the changes to our database so that they are still available the next time the application starts.

Jobs done!

Conclusion

In this post, we created a proof-of-concept for adding a database backend for maintaining our application state to a Tauri app. Using a repository trait, we were able to decouple our application logic from our database, letting us switch between different database backends.

However, our repository interface is rather minimalist, but more complex scenarios would definitely require a more advanced query API. But that's something for another post...

Also, migrating from an old domain model to a new one would be another good topic for a follow-up article.

What about you? Have you already worked with Tauri and Rust?
Please share your experience in the comments or via Twitter @umlboard.

Image of a local database generated with Bing Image Creator.
Source code for this project is available on Github.

Originally published at https://umlboard.com.

Moving From Electron to Tauri

Patric Genfer — Tue, 07 Feb 2023 13:50:29 +0000

Part 1: Interprocess Communication — porting a Typescript-based message system of an Electron App to Tauri and Rust.

TL;DR: Tauri is a Rust-based Electron alternative.
However, porting an existing Electron application to Tauri requires some work. This post explains how UMLBoard's message system used for inter-process communication could be ported to Rust without much effort.

Many people would agree that native apps - if done right - provide better user experience and performance compared to hybrid or cross-platform solutions.

However, having separate apps also means maintaining different code bases, each written in its own language.
Keeping them all in sync is quite a lot of work for a single developer - usually more than what we've planned for our side projects.

The Electron framework is a compromise: It provides a convenient way to write platform-independent applications using a web-based technology stack most people are familiar with. Also, the framework is very mature and actively supported by a large community.

But nevertheless, it’s only a compromise:
Its platform-independence comes with the cost of larger binaries and higher memory consumption compared to native apps. Take, for instance, UMLBoard's macOS binaries:
The universal platform package ends up with a total size of 250 MB - that's a massive number for a lightweight drawing tool...

Still, alternatives with the same level of maturity as Electron are relatively rare. Tauri, however, is one of these alternatives that looks very promising.

A First look at Tauri

While Electron and Tauri share some similarities - like using separate processes for their core and rendering logic - they follow divergent philosophies regarding bundle size.

Instead of deplyoing your application with a complete browser frontend, Tauri relies on the built-in Webviews the underlying operating systems provide, resulting in much smaller applications. Despite that, Tauri uses Rust as the language of choice for its Core process, resulting in better performance compared to Electron's node.js backend.

While porting UMLBoard from Electron to Rust won't happen overnight, exploring how some of its core concepts could be translated from TypeScript to Rust would still be interesting.

The following list contains some crucial features of UMLBoard. Some of them are real show-stoppers in case they don't work.
A possible port would have to deal with these issues first.

[x] Porting the inter-process communication to Tauri (this post here!)
[ ] Accessing a document-based local data store with Rust
[ ] Validate the SVG compatibility of different Webview
[ ] Check if Rust has a library for automatic graph layouting

The remaining post is dedicated to the first bullet point:
We will investigate how UMLBoard’s existing inter-process communication could be ported to Tauri. The other topics may be the subjects of further articles.

Ok, but enough said, let's start!

Sending Messages between Electron Processes

UMLBoard's current implementation uses a React front end with Redux state management.
Every user interaction dispatches an action that a reducer translates into a change resulting in a new front end state.

If, for instance, a user starts editing a classifier's name, a renamingClassifier action gets dispatched. The classifier reducer reacts to this action and updates the classifier's name, triggering a rerender of the component.
So far, this is all standard Redux behavior.

A user input dispatches a redux action that leads to a state update in the front end.

But UMLBoard even goes one step further and uses the same technique for sending notifications to Electron's main process.

Taking our previous example, when the user hits the ENTER key, a renameClassifier action is dispatched, indicating that the user finished editing.

This time, however, the action gets processed by a custom middleware instead of a reducer. The middleware opens an IPC channel and sends the action directly to the main process.
There, a previously registered handler reacts to the incoming action and processes it. It updates the domain model accordingly and persists the new state to the local datastore.

If all that goes well, a response action is sent back on the same channel. The middleware receives the response and dispatches it like a regular action. This keeps the front-end state in sync again with the domain state.

See the following diagram for an overview of this process:

Inter Process Communication between renderer and main process in UMLBoard.

It might look a bit odd to extend Redux to the main process, but from the view of a lazy developer like me, it has some benefits:

Since both mechanisms, Redux and IPC, rely on plain serializable JSON objects, everything that goes through a Redux dispatcher can also go through an IPC channel.
This is very convenient as it means we can reuse our actions and their payloads without writing additional data conversions or DTO objects.
We also don't have to write any custom dispatching logic. We only need a simple middleware to connect the Redux front end with the IPC channel.

This action-based messaging system is the backbone of UMLBoard's process communication, so let's see how we can achieve this in Tauri...

Porting to Tauri

For our proof-of-concept, we will create a small demo application in Tauri. The app will use a React/Redux front end with a single text field. Pressing a button will send the changes to the backend (Tauri's Core process).

The example app we're going to implement.

We are only interested in inter-process communication, so we will skip all state tracking in the core process (this will be part of a future blog entry...). That's why our Cancel method behaves a bit weird as it will always restore the original class name. But for proving our concept, this should be sufficient.

We basically have to implement four tasks:

Declare Rust equivalents of our Redux actions
Sending actions from Webview to Core process
Handling incoming actions in the Core process
Sending response actions back to Webview

Let's go through the implementation step by step.

1. Declare Rust equivalents of Redux actions

Redux actions are plain JSON objects with a string identifying their type and a field holding their payload.

Rust has a similar concept we could use to mimic this behavior, the Enum type. Enums in Rust are more powerful than in other languages because they allow storing additional data for each variant.

In that way, we could define our Redux actions as a single Enum, where each variant represents an individual type of action.

#[derive(Serialize, Deserialize, Display)]
#[serde(rename_all(serialize="camelCase", deserialize="camelCase"))]
#[serde(tag = "type", content = "payload")]
enum ClassiferAction {
  // received from webview when user changed name
  RenameClassifier(EditNameDto),
  // user canceled name change operation
  CancelClassifierRename,
  // response action after successful change
  ClassifierRenamed(EditNameDto),
  // response action for cancel operation
  ClassifierRenameCanceled(EditNameDto),
  // error response
  ClassifierRenameError
}

To convert our Redux action into a Rust Enum and vice versa, we can use Rust's serde macro: We specify that the variant's name should be serialized into a type field and its data into a field called payload. This corresponds precisely to the scheme we use to define our Redux actions.

But we can even go one step further by using the ts-rs crate. This library can generate the TypeScript interfaces for the action payloads straight from our Rust code. We don't have to write a single line of TypeScript code for this.
That's really neat!

Decorating our Rust struct with the relevant macros

#[derive(TS)]
#[ts(export, rename_all="camelCase")]
struct EditNameDto {
    new_name: String
}

gives us the following auto-generated TypeScript interface for our action payloads:

// This file was generated by [ts-rs](https://github.com/Aleph-Alpha/ts-rs). Do not edit this file manually.
export interface EditNameDto { newName: string }

Ok, we have the correct data types on both edges of our communication channel, let's now see how we can send data between them.

2. Sending actions from Webview to Core process

Interprocess communication in Tauri is done through commands. These commands are implemented as Rust functions and can be called within the Webviews using the invoke API.

One problem we face is that the Redux Toolkit generates the type for identifying an action by concatenating the name of the slice where the action is defined with the action's name.
In our case, the resulting type would therefore be classifier/renameClassifier instead of just renameClassifier. This first part, classifier, is also called the domain to which this action belongs.

Unfortunately, this naming convention does not work for Rust, as it would result in invalid names for our Enum options.
We can avoid this by separating the domain from the action type and wrapping everything up in an additional object, the IpcMessage, before submitting.

See the following diagram for the complete invocation process.

Invoking a Tauri command from the Webview process.

3. Handling incoming actions in the Core process

On the backend side, we must also define a Rust struct for our IpcMessage. Since we don't know the concrete type of the payload yet, we keep it stored as a JSON value and parse it later when needed.

// data structure to store incoming messages
#[derive(Deserialize, Serialize)]
struct IpcMessage {
    domain: String,
    action: Value
}

We can now define the signature of the method for our Tauri command. Our function, ipc_message, will receive an IpcMessage, processes it somehow, and at the end, returns another IpcMessage as a response.

#[tauri::command]
fn ipc_message(message: IpcMessage) -> IpcMessage {
    // TODO: implement
}

Ok, but what would the actual implementation look like?

The function should take the domain from the message, see if a handler is registered for this domain and if yes, call the corresponding handler with the action stored inside our IpcMessage. Since we will have many different domains and handlers later, it makes sense to minimize the implementation effort by extracting common behavior into a separate ActionHandler trait.

// trait that must be implemented by every domain service
pub trait ActionHandler {
    // specifies the domain actions this trait can handle
    type TAction: DeserializeOwned + Serialize + std::fmt::Display;

    // the domain for which this handler is responsible
    fn domain(&self) -> &str;

    // must be implemented by derived structs
    fn handle_action(&self, action: Self::TAction) -> 
    Result<Self::TAction, serde_json::Error>;    

    // boiler plate code for converting actions to and from json  
    fn receive_action(&self, json_action: Value) -> 
    Result<Value, serde_json::Error> {
        // convert json to action
        let incoming: Self::TAction = serde_json::from_value(json_action)?;
        // call action specific handler
        let response = self.handle_action(incoming)?;
        // convert response to json
        let response_json = serde_json::to_value(response)?;
        Ok(response_json)
    }
}

The trait uses the TemplateMethod design pattern: The receive_action specifies the general workflow for converting the action. The handle_action method contains the actual logic for processing a specific action.

In our case, a ClassifierService could be responsible for processing all actions of the domain classifier:

// ClassifierService handles all classifier specific actions
struct ClassifierService {}
impl ClassifierService {
    pub fn update_classifier_name(&self, new_name: &str) -> () {
        /* TODO: implement domain logic here */
    }
}
impl ActionHandler for ClassifierService {
    type TActionType = ClassifierAction;

    fn domain(&self) -> &str { CLASSIFIER_DOMAIN}

    fn handle_action(&self, action: Self::TActionType) -> 
    Result<Self::TActionType, serde_json::Error> {
        // here happens the domain logic
        let response = match action {
            ClassifierAction::RenameClassifier(data) => {
                // update data store
                self.update_classifier_name(&data.new_name);
                ClassifierAction::ClassifierRenamed(data)
            },
            ClassifierAction::CancelClassifierRename =>
                // user has canceled, return previous name
                // here we just return an example text
                ClassifierAction::ClassifierRenameCanceled(
                    EditNameDto { new_name: "Old Classname".to_string() }
                )
            , // if front end sends different actions, something went wrong
            _ => ClassifierAction::ClassifierRenameError
        };
        Ok(response)
    }
}

4. Sending response actions back to Webview

We're almost done. We have the signature of our Tauri command and the code we need to handle an action and generate a response. If we glue everything together, our final ipc_message function may look like the following snippet:

#[tauri::command]
fn ipc_message(message: IpcMessage) -> IpcMessage {
    // This code is just for demonstration purposes.
    // In a real scenario, this would be done during application startup.
    let service = ClassifierService{};
    let mut handlers = HashMap::new();
    handlers.insert(service.domain(), &service);

    // this is were our actual command begins
    let message_handler = handlers.get(&*message.domain).unwrap(); 
    let response = message_handler.receive_action(message.action).unwrap();
    IpcMessage {
        domain: message_handler.domain().toString(),
        action: response
    }
}

Please note that the service creation and registration code are only for demonstration purposes. In an actual application, we would instead use a managed state to store our action handlers during application startup.

We also omitted the error handling here to keep the code simple. However, there are quite some scenarios we should check, e.g., what should happen if no handler is found, or how should we proceed if parsing an action into an enum goes wrong, etc.

Conclusion

Our proof-of-concept was successful! Sure, some parts of the implementation can be tweaked, but porting UMLBoard's IPC messaging from Electron/TypeScript to Tauri/Rust is definitely manageable.

Rust's enums are an elegant and type-safe way to implement our message system. We only have to ensure that potential serialization errors are handled when converting JSON objects into our enum variants.

In the next post in this series, we will try to use a document-based local database to store our domain model.
Hopefully, by then, I'll finally understand how the borrow checker works...

What's your opinion on that? Have you already worked with Tauri and Rust, and what were your experiences? Please share your thoughts in the comments or via Twitter @umlboard.

Title Image from Wallpaper Flare.
Source code for this project is available on Github.
Originally published at https://www.umlboard.com.