DEV Community: Wojciech Olejnik

Commentable.rs - Building a Serverless Comment System in Rust

Wojciech Olejnik — Mon, 20 Jan 2020 10:01:43 +0000

In this article I'm going to write about my journey of building Commentable.rs - a privacy oriented Disqus-like comment hosting solution written in Rust and running on AWS Lambda.

Motivation

A couple months ago I was working on our internal Software Radar - a web app showcasing the technologies we use and tracking the ones we're experimenting with or watching. One of the ideas for this project was that our employees should be able to have a discussion about a particular technology in its comment section, without having to look for an appropriate channel on Slack. Normally we'd integrate such comment system into the current backend, but at the time Radar's API was just a couple of Google Cloud Functions, acting as a proxy to Salesforce. We've decided to look at existing solutions and compare their capabilities but we couldn't find a perfect candidate. The closest to our needs was Disqus, the leading choice in this field. But Disqus has raised some major concerns among our team, such as the lack of data ownership, every comment being public (accessible by URL) and separate sign in/sign up process. Disqus also proved to be hard to customise and even though we managed to override it's stylesheet to match our website's theme it still didn't look very good.

With so much room for improvement, it's hard not to be inspired to build
something better. A comment hosting solution that is privacy oriented and easily customisable. In the spirit of our current backend architecture I've decided to try the Serverless approach. I've also made the decision to use Rust, mostly because I'm a huge fan of it, but also because of its speed and safety. 😉

Development

Getting started

I began by doing some research how to even run Rust code on AWS Lambda. Turns out it's quite easy thanks to a great library that became the backbone of this project - lambda_http. This crate is an extension of the lambda_runtime library and is effectively all we need to quickly develop HTTP-based microservices. A basic hello world example would look like this:

use lambda_http::{lambda, Response, Body, http::StatusCode};

fn main() {
  lambda!(|request, _| Ok(
    Response::builder()
      .status(StatusCode::OK)
      .body(Body::Text("Hello World!"))
      .unwrap()
  ));
}

This incredibly small amount of boilerplate makes me happy, but unfortunately we need to do a bit more to actually run this code on the server. The next part is going to differ depending on your operating system, because we actually need to cross-compile our code to the specific architecture AWS is using for running Lambda functions (Unless you're using Linux, then you're pretty much set!). I was using a Mac and this step gave me a headache, so here's a short summary of what needs to be done:

# 1) Install the cross-compilation tools (WARNING: can take a long time):
$> brew install filosottile/musl-cross/musl-cross
# 2) Add the new target for compilation:
$> rustup target add x86_64-unknown-linux-musl
# 3) Create a soft-link for `musl-gcc`
$> ln -s /usr/local/bin/x86_64-linux-musl-gcc /usr/local/bin/musl-gcc

The final step is to create a .cargo/config file (relative to your project directory) with the following contents:

[target.x86_64-unknown-linux-musl]
linker = "x86_64-linux-musl-gcc"

After that you should be able to compile your project using:

$> CC_x86_64_unknown_linux_musl=x86_64-linux-musl-gcc cargo build

If you don't like headaches (or you're using Windows), the best choice is to use Docker. It works great, but the downside is that build times can get really long - which effectively made me stick to the cross-compilation approach.

Testing and deploying

Having our code compiled we could now zip the binary and upload it to AWS Lambda through the AWS Management Console. That's not very elegant though and certainly not feasible for rapid development. This is where the second pillar of this project comes into play: the AWS Serverless Application Model (SAM). AWS SAM is a technology that allows us to describe the architecture of our application using a YAML (or JSON) file, create a local instance of the app using Docker and finally publish the app to a production environment with a single command. To make use of it we need two command line utilities: aws-cli and aws-sam-cli. If you follow these links you'll be able to install and configure these tools easily.

The final step is to create the AWS SAM template. Here's a very basic one that would work with our hello world example:

AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31

Globals:
  Function:
    Runtime: provided
    Handler: rust.binary
    Timeout: 3

Resources:
  # GET /hello
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      # I'm assuming the binary name is hello
      CodeUri: target/x86_64-unknown-linux-musl/release/hello # or just target/release/hello on Linux/Docker
      Events:
        HelloWorldEndpoint:
          Type: Api
          Properties:
            Path: /hello
            Method: get

The most important parts are specifying the rust.binary handler, CodeUri (binary location) and endpoint properties (path and HTTP method). There's a lot more you can do with SAM templates and I recommend checking the documentation for more information. With the template ready you should be able to test the application locally (Docker required) with:

$> sam local start-api --template PATH_TO_YOUR_SAM_TEMPLATE.YML

The output should contain a URL which you can visit to test your application. If everything works fine, we can deploy the app to the actual AWS servers with these two commands (make sure you're logged in to aws-cli first):

# assuming a bucket named "hello-rust-lambda" exists
# if not, you can create one with `aws s3 mb s3://hello-rust-lambda`
$> sam package --template-file PATH_TO_YOUR_SAM_TEMPLATE.YML --s3-bucket hello-rust-lambda --output-template-file package.yml
$> sam deploy --template-file package.yml --stack-name hello-rust-lambda --capabilities CAPABILITY_IAM

The first command packages the application and uploads it to S3. The second command instantiates or updates the required services and copies the code from S3 into a new Lambda function. Even though compiling and deploying takes only 3 commands I ended up writing a sizeable Makefile to speed up this process. You can check it out here.

Going forward

At this point we have everything we need to implement a working API, but we still lack some kind of storage. This is where I introduce the third major component of Commentable.rs - AWS DynamoDB and the rusoto_dynamodb create. I'm not a big fan of NoSQL databases, but this was the only choice that worked very well with AWS SAM and our Serverless approach - we can specify the database schema in the same YAML template and even set the billing to only pay per the number of database requests we make.

rusoto_dynamodb makes interacting with the database a breeze. It's not an ORM though, so I wrote a handy trait called DynamoDbModel containing methods such as new, create, find, delete etc. Here's a snippet showing how it encapsulates the methods from rusoto_dynamodb:

use rusoto_dynamodb::{
  DynamoDb,
  DynamoDbClient,
  PutItemInput,
  AttributeValue,
  // ... other imports
};

pub trait DynamoDbModel where Self: Sized + Serialize {
 // ...
  fn create(db: &DynamoDbClient, attributes: IntoDynamoDbAttributes) -> Result<Self, DbError> {
    let attributes: DynamoDbAttributes = attributes.into();
    db.put_item(PutItemInput {
      item: attributes.clone(),
      table_name: COMMENTABLE_RS_TABLE_NAME.to_string(),
      ..Default::default()
    }).sync()
      .map_err(|err| DbError::Error(err.to_string()))
      .and_then(|_| Self::new(attributes))
  }
 // ...
}

We can implement this trait for any struct in order to save it in the database. In our case we only need three models: User, Comment and Reaction. Here's the Comment model for example:

#[derive(Serialize, Debug)]
pub struct Comment {
  pub primary_key: CommentableId,
  pub id: CommentId,
  pub user_id: Option<UserId>,
  pub replies_to: Option<CommentId>,
  pub body: String,
  pub is_deleted: Option<bool>,
  pub created_at: DateTime<Utc>,
}

impl DynamoDbModel for Comment {
  fn new(mut attributes: DynamoDbAttributes) -> Result<Self, DbError> {
    Ok(Self {
      primary_key: attributes.string("primary_key")?,
      id: attributes.string("id")?,
      user_id: attributes.optional_string("user_id"),
      replies_to: attributes.optional_string("replies_to"),
      body: attributes.string("body")?,
      is_deleted: None,
      created_at: attributes.timestamp("created_at")?,
    })
  }
}

That's all there really is to DynamoDB from the Rust perspective. All we need to do now is to specify the database schema in our SAM template:

# ...
Resources:
  # ... Lambda functions definitions
  CommentableRsTable:
    Type: AWS::DynamoDB::Table
    Properties:
      TableName: CommentableRsTable
      BillingMode: PAY_PER_REQUEST
      AttributeDefinitions:
        - AttributeName: primary_key
          AttributeType: S
        - AttributeName: id
          AttributeType: S
      KeySchema:
        - AttributeName: primary_key
          KeyType: HASH
        - AttributeName: id
          KeyType: RANGE

We only have to specify the required keys so that's enough. We can also create indexes here, but for that I recommend reading the documentation.

Implementing a Create Comment endpoint

At this point there's nothing left to do apart from actually implementing the comment system logic. I'm going to show some snippets from the AddComment Lambda function but I recommend checking the full source code on GitHub - there's a lot of glue code and handy utilities that I won't be able to show here.

Let's start with the entrypoint:

fn main() {
  lambda!(|request, _|
    AddComment::respond_to(request)
      .or_else(|error_response| Ok(error_response))
  );
}

This minimal piece of code immediately delegates execution to the custom AddComment service. I use this pattern for every Lambda function to help with code organisation and state management. The struct itself looks like this:

// HTTP request parameters
#[derive(Deserialize)]
struct Params {
  auth_token: AuthToken,
  replies_to: Option<CommentId>,
  body: String,
}

struct AddComment {
  db: DynamoDbClient,
  commentable_id: CommentableId,
  params: Params,
  current_user: Option<User>,
  comment: Option<Comment>,
}

The real action takes place in the impl block. I used a "pseudo" builder pattern to chain method calls on the AddComment struct. I like the readability of this approach and the bubbling error handling, but there are also some disadvantages: most methods have to take a mutable reference to self, and the methods have to be invoked in a certain order to work correctly.

impl AddComment {
  pub fn respond_to(request: Request) -> Result<Response<Body>, HttpError> {
    if let Some(commentable_id) = request.path_parameters().get("id") {
      Self::new(request, commentable_id.to_string())?
        .validate()?
        .fetch_current_user()?
        .check_reply()?
        .save()?
        .serialize()
    } else {
      Err(bad_request("Invalid params: 'id' is required."))
    }
  }

  pub fn new(request: Request, commentable_id: CommentableId) -> Result<Self, HttpError> {
    if let Ok(Some(params)) = request.payload::<Params>() {
      Ok(Self {
        db: DynamoDbClient::new(Region::default()),
        comment: None,
        current_user: None,
        commentable_id,
        params,
      })
    } else {
      Err(bad_request("Invalid parameters"))
    }
  }
  // ...
}

And here's the save method. It's mostly about preparing the JSON attributes and passing them to the database through a DynamoDbModel trait method.

impl AddComment {
  // ...
  pub fn save(&mut self) -> Result<&mut Self, HttpError> {
    let current_user_id = &self.current_user.as_ref().unwrap().id;
    let mut attributes = IntoDynamoDbAttributes {
      attributes: hashmap!{
        String::from("primary_key") => self.commentable_id.clone().into(),
        String::from("id") => comment_id(&self.commentable_id, current_user_id).into(),
        String::from("user_id") => current_user_id.clone().into(),
        String::from("body") => self.params.body.clone().into(),
        String::from("created_at") => Utc::now().to_rfc3339().into(),
      }
    };
    // replies_to can be empty so we have to insert it separately
    if let Some(parent_comment_id) = self.params.replies_to.clone() {
      attributes.attributes.insert(String::from("replies_to"), parent_comment_id.into());
    }
    match Comment::create(&self.db, attributes) {
      Ok(comment) => {
        self.comment = Some(comment);
        Ok(self)
      },
      Err(err) => Err(internal_server_error(err))
    }
  }
  // ...
}

And that's it! The rest of the code is written using the same general patterns.

Result

I'm overall very happy with how this project turned out. Rust has been a blast to work with and its safety features have saved me multiple times from introducing bugs into the code. The library support for writing Serverless applications is very good. The most problematic thing during development was understanding DynamoDB and getting around some of its limitations - I had to redesign the data layer quite a few times. The performance could also have been a bit better - Rust itself is super fast but it seems that the custom Lambda runtime is introducing some overhead to the response times. When it comes to the future of Commentable, we're aiming to soon realease the client side libraries - for React, Vue, and vanilla JS. After that it's only a matter of adding proper documentation and tests and the product will be ready to ship.

Building WASM applications with C#

Wojciech Olejnik — Tue, 03 Dec 2019 08:51:41 +0000

This post is a short summary of our recent experiment with WASM and Blazor (.NET)

Here at Netguru we have high hopes for WebAssembly. It's definitely a disruptive technology with a huge potential to revolutionize modern web development. So far though, we've struggled to come up with a good use case for it or to find a way to incorporate it in our day-to-day projects. We've experimented with Machine Learning and image processing, but the results were not very satisfying. Our technology of choice was always Rust, which has out of the box support for WASM and a great ecosystem of tools. But Rust also had some drawbacks, including it's infamous steep learning curve. When it comes to writing whole web apps in Rust, the only reasonable option seems to be Yew (https://github.com/yewstack/yew) and even though it looks very promising, it's still a work in progress.

Some time ago I stumbled across Blazor, a part of Microsoft's ASP.NET framework which enables writing client side web applications in C#. There are two flavours of Blazor - one works by executing C# code on the server and passing the data back using a technology named SignalR (basically WebSockets). The second flavour of Blazor works by compiling C# into WebAssembly. I was intrigued that Microsoft adopted this technology so quickly into their core framework, so we decided to perform some research and maybe write a simple application with it.

As of today, the WASM version of Blazor is still in Preview, but the documentation and support are very solid. Getting started is as easy as installing the preview version of Visual Studio (or the dotnet core CLI), downloading the blazorwasm project template, and then creating a project. This comes down to two commands:

# Download the blazorwasm project template
$> dotnet new -i Microsoft.AspNetCore.Blazor.Templates::3.1.0-preview3.19555.2
# Build a new project from the template
$> dotnet new blazorwasm --hosted

You can skip the --hosted part if you want to make just a client-side application. I also wanted to try building a simple API in ASP.NET and this option initializes a simple project for that.

The blazorwasm template contains three examples: a counter, a todo list, and a weather forecast API example. They're minimal and easy to understand, one can also get rid of them quickly (which I did because I like to build my stuff from scratch). For our research example, I've decided to implement a simple dashboard with fake financial data. Stock values are fetched every second from an API where they are adjusted randomly, so that we get some dynamic content in an otherwise simple application. The code that we actually write in a Blazor app can be divided into three areas: Razor templates, component logic and plain C# classes. Razor templates are very similar to other template solutions like JSX or ERB. The difference is of course in the syntax and the fact that we can embed C# code in them. Components in Blazor are again very similar to React or Vue - they are stateful and have specific lifecycle methods defined on them that we can use to manage their state. In my example I had to use OnInitializedAsync (an equivalent of React's componentDidMount), where I set up recurring data fetching. The template and the component logic reside in one file that looks like this:

@page "/"
@using Stocks.Shared
@inject StocksViewModel viewModel

<div class="dashboard">
  // We can use C# inside html if we preceed it with the "@" symbol.
  @if (viewModel.Stocks == null) {
    <p><em>Loading...</em></p>
  }
  else {
    // Rest of the page...
  }
</div>

@code {
  // Component logic goes here
  protected override async Task OnInitializedAsync() {
    await viewModel.FetchStocks();
    System.Timers.Timer t = new System.Timers.Timer();
    t.Elapsed += async (s, e) => {
      await viewModel.FetchStocks();
      await InvokeAsync(StateHasChanged); // Inform the component that it should re-render;
    }
    t.Interval = 1000;
    t.Start();
  }
}

Last but not least, we write pure C# classes to separate the logic from our views and components. An amazing advantage of this approach is the fact that we can actually share the same code between the client and server applications. In my case I had to write a ViewModel class for my Stock model to decorate some of the database fields.

The developer experience overall is pretty good, even on a Mac. Visual Studio is not required (any .NET core app can be run from a terminal), but it certainly brings a lot to the table with IntelliSense and an integrated debugger. That said, the development felt quite slow at times. Error messages in the browser were often extremely unhelpful due to the obfuscated nature of WebAssembly. There's also no hot reload on C# code changes (at least to my knowledge), which meant I had to stop and restart the application every couple of minutes.
When it comes to performance and the overall result of this experiment, I'm quite happy. The app runs smoothly and the only performance bottleneck is the initial load time - since the browser needs to download the WASM equivalent of the entire .NET framework. But these files would be served from browser cache in a normal scenario so I'm actually not worried about that.

I'm certainly intrigued by this new way to develop web applications. With Blazor coming out of preview and WebAssembly constantly evolving, I'm starting to think that it might become one of the hot technologies of the next few years.

Exploring Machine Learning possibilities in WASM

Wojciech Olejnik — Mon, 09 Sep 2019 09:25:33 +0000

This post is a short summary of our recent experiment with WASM & ML.

The goal was to run a simple ML model in WASM and then maybe benchmark it against existing JavaScript ML libraries. Our Machine Learning team provided a basic grayscale filter model in three formats: CoreML, Tensorflow and PyTorch.

We tried PyTorch first as it looked very promising. We found good bindings for Rust - https://github.com/LaurentMazare/tch-rs - that seemed to be very easy to use. But after some tinkering it turned out that it’s not possible to export the whole model from PyTorch in a form that can be easily imported in Rust. We’d basically have to implement the model from scratch before loading the data the ML team provided. That was a bit too much for our experiment so we moved on.

Next we looked at CoreML, but quickly found that there were virtually no libraries for Rust or anything else that we could compile to WASM. I'm not sure if that’s due to CoreML being made by Apple (and thus being proprietary) or the community isn’t as big and there is no interest in libraries for other languages. If it's the second case than maybe it’s worth taking a look at it in the future.

Our last chance was Tensorflow and it started out great. Even though it doesn’t have first-class support for WebAssembly (it's a work in progress: https://github.com/tensorflow/tfjs/issues/1497), it does have official support for Rust - https://github.com/tensorflow/rust.
We were able to quickly prototype a simple app that loaded the Tensorflow model in a *.pb format, pass it an image as a tensor and finally save the output from the neural network to the file system. It worked really well, so we tried to port it to WebAssembly. For Rust it’s really easy thanks to wasm-pack (https://github.com/rustwasm/wasm-pack).
Unfortunatelly that’s when we hit a major blocker. Turns out that Tensorflow depends on a library called “aligned_alloc” which wouldn’t compile to WebAssembly, most likely due to some system-dependent functionality that could not be ported to the browser.

My conclusion for now is that porting big libraries to WASM can be, more often than not, tricky. The differences in memory allocation create conflicts in low-level code and some libraries simply won’t compile. Another solution would be to write a neural network from scratch, using only basic libraries and language-level constructs. This approach was explored e.g. in https://ngoldbaum.github.io/posts/python-vs-rust-nn. It would most likely compile without issues, but require more time to develop.