The Stack Part 3: Building a Frontend

In the last post we set up our deployment, fully automated on merge to our main branch. In this post we will be building our UI (Frontend) applications. See the full overview of posts here.

At the end of this post we will have:

  • A Next.js Frontend app with support for localization, using Tailwind CSS.
  • A Leptos Rust/WASM Frontend app with support for localization, using Tailwind CSS.
  • Automatic deployment of our Apps AWS using CDK, statically hosted using S3 + CloudFront.

We are essentially hedging our bets by building both a JavaScript-based Frontend, which is the safe bet, and a Rust/WASM-based Frontend, which is the future bet. We will be using the same GraphQL API for both, so we can easily switch between them.

There is quite a lot to cover. My recommendation is to clone down the Part 3 branch in the GitHub repository and use this post as an explanation of what is set up.

Read more →

"The Stack": Everything you'll need

This will be a series of blog posts where we will build up the perfect infrastructure setup for the majority of usecase, aka “The Stack”. We’ll be building everything on top of AWS.

Before diving in, let’s first establish some goals:

  • Performant: Latency and performance is important as this will serve end-users.
  • Low cost: We want our base cost to be low, and our costs to scale well with high traffic. Ideally, it should cost nothing if no users are using it.
  • Low operational overhead: It’s >=2023, nobody wants to nurse servers or services anymore, things should scale up and down without intervention or oversight.
  • High flexibility: Everything should be built with the foresight of future scalability, both organizationally, code-wise, and in the way things fit together.
  • Modular: Pieces of the infrastructure should be opt-out, e.g. if you don’t need Pub/Sub, it can be skipped.

Obviously, this is my personal opinion on it, but I’ll be sharing the thinking behind each of the choices as we go along.

Some technology choices upfront:

  • Everything will be infrastructure as code using AWS CDK.
  • We’ll be using Rust throughout for each service, as it allows us to squeeze out the most performance while still giving us a nice developer experience.
  • Federated GraphQL will be our way of facilitating microservices.

Read more →

Common JSON patterns in Haskell, Rust, and TypeScript

A lot of web development is transforming JSON one way or another. In TypeScript/JavaScript, this is straightforward, since JSON is built into the language. But can we also achieve good ergonomics in Haskell and Rust?

Dear reader, I am glad you asked! 🙌

The comparisons we will see are not meant to show if one approach is better than another. Instead, it is intended to be a reference to become familiar with common patterns across multiple languages. Throughout this post, we will utilize several tools and libraries.

The core of working with JSON in Haskell and Rust is covered by:

  • Aeson: a Haskell JSON serialization/deserialization library1.
  • Serde: a Rust JSON serialization/deserialization library.

The ergonomics is then improved in Haskell by grabbing one of the following options2:

We’ll go through typical use-cases seen in TypeScript/JavaScript codebases, and see how we can achieve the same in Haskell and Rust.

Read more →