
I recently took a much-needed vacation to an exotic location. While I was away, I kept a close eye on the [BattleTabs](https://battletabs.com/) servers. Given [our recent global launch](https://mikecann.blog/posts/battletabs-global-launch-on-discord-activities), things were still a bit unstable, and traffic was continuing to increase.

One issue was that, despite all my best efforts, our worker server was still regularly shutting down and not coming back online.

![](./downtime.png)

This generally happened at points of peak load and usually when I was in bed (typical). The result was that chunks of the game wouldn't work or would work in unexpected ways.

Technically, this should not have been possible as Fly.io's machines have [an auto-start/stop feature](https://fly.io/docs/launch/autostop-autostart/) that should ensure that at least one machine is running at all times.

Since I was on vacation and didn’t have time to debug the root cause of the issue, I decided the simplest thing to do was to write a script that would continually check if the worker server was alive, and if it wasn't, start it up.

I knew that this script would need to be online all the time, so I started thinking about how to host it. I could have easily used my favorite tool, [Convex](https://mikecann.blog/posts/im-now-a-convex-developer-advocate), but I had heard about the recently released [Replit Agents](https://docs.replit.com/replitai/agent), so I thought—why not give that a go?

# Replit Agents

If you're not familiar with Replit Agents, here's a quick primer:

<iframe width="853" height="480" src="https://www.youtube.com/embed/IYiVPrxY8-Y" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

The idea was to use their AI to generate my script and host it on Replit. It should be a fairly simple script and, therefore, hopefully a straightforward, isolated task for the AI.

![](./initial-impressions.png)

I hadn’t used Replit before, and my initial impressions were good. I was very impressed with the UI. It felt like a cut-down code editor, but with the agent chat on the side, taking up a large chunk of the UI to let you know that this is a sort of "pair programming" type of workflow.

I started out with what I felt was a pretty clear prompt (see the image above) and was happy to see that the agent was able to easily scaffold out the start of the project with a bunch of files.

After it had generated the files, it asked me if it worked. Unfortunately, it didn’t, so I had to dig through the code and do a bit of guesswork to try to work out what was going on.

![](./env.png)

It probably would have been better if it worked out this issue by itself, but I was impressed to see that they had a little inline UI for adding an environment variable. I thought that was a nice touch.

This is where things started to go off the rails a bit. The AI continued to make a lot of mistakes, both architecturally and logically, which required quite a few prompts on my part to sort out.

Eventually, I had what I thought should work, but I was still getting errors. I eventually tracked down the problem—it stemmed right back to the first prompt, where the AI was using a very outdated endpoint URL for the API.

![](./tracked-down-the-error.png)

After letting it know, it was able to fix the problem, and I finally had a working API call.

As a side note, I was impressed that Replit has a Git integration, and the AI made regular "checkpoint" commits as it went along.

With it working, I now wanted to have it run itself every 5 minutes. This cloud hosting and cron functionality is one of the core features of Replit, so I thought it should be pretty straightforward for the Agent.

![](./always-on.png)

I was super confused at first as it directed me towards an "Always On" feature that doesn’t seem to exist in Replit (anymore). When I pointed it out to the Agent, it even suggested using another service to run the cron!

I had to manually read through the Replit docs before I worked out how to do it myself in the UI.

![](./deployments.png)

With that, my script was up and working, checking the worker every 5 minutes.

# Conclusions

I really like the Replit Agents UI. I think they have done a great job with how it all looks and works. The functionality of Replit itself is also great, and I will definitely keep it in mind next time I need a quick and dirty project.

The AI, however, just makes way too many mistakes right now for me to recommend. Even with my simple script, I had to go in and manually correct it on multiple occasions.

I will, however, continue to monitor how this develops, as this way of developing software projects feels very much like the future direction for coding.



I've been meaning to tinker with Temporal for quite some time now, as it intersects some of my key interests: [Event Sourcing](https://mikecann.blog/posts/serverless-databaseless-event-sourcing), [durable execution](https://mikecann.blog/posts/tech-to-tinker-with-in-2022), and [cool application architectures](https://mikecann.blog/posts/tinkering-with-convex).

# What is Temporal?

From their [website](https://temporal.io/):

> Durable Execution is a development abstraction that preserves complete application state so that upon host or software failure, it can seamlessly migrate execution to another machine.

But what does that mean exactly?

From a coder's perspective, it means you can define "Workflows" in TypeScript such as:

```ts
export async function SubscriptionWorkflow(email: string, trialPeriod: string | number) {
  await sendWelcomeEmailToUser(email);
  await sleep(trialPeriod);
  await sendSubscriptionEndedEmailToUser(email);
}
```

Temporal ensures this function continues to exist even if the server that runs it shuts down. When the server starts up again, it can resume from the correct location, making it "durable." Temporal also handles errors and retries the steps in the Workflow if they fail.

If this doesn't immediately seem impressive, consider how difficult it is to resume a function's execution at any arbitrary point after the fact, especially when dealing with non-deterministic states like DateTimes and random numbers.

# Exploring Temporal

My goal with any "tinkering" I do is to understand the technology enough to form an opinion about it.

I started with [the docs](https://docs.temporal.io/), which are quite thorough. Setting up the environment included installing the Temporal CLI and running their local service, which even comes with a nice WebUI to display your Workflows:

![](./webui.png)

After reading through the initial pages of the docs, I summarized the key structure and terms with this diagram:

![](./diagram.png)

Clients start Workflows, which can contain several Activities. Workflows enter a Task Queue from which Workers pull and execute tasks. If activities fail, they can be retried an infinite (configurable) number of times.

Every "[Action](https://docs.temporal.io/cloud/pricing#action)" the system takes (starting a workflow, running an activity, signals, queries, etc.) is an event recorded within the system, which is then recorded against your workflow so you can view exactly what happened and when:

![](./events.png)

## Event Sourcing

It's worth taking a tangent to discuss another application architecture dear to my heart: [Event Sourcing](https://martinfowler.com/eaaDev/EventSourcing.html).

I won't explain all of Event Sourcing here, as I've covered it before on this blog and there are many good deep-dives available online. The basic idea is that your entire application should be described with immutable events. To get the current state of your application, you fold/reduce your events down to a state. For example, you might have a "UserCreated" event with the user's name "Dave." Later, if Dave changes his name to "Davina," the system triggers a "UserChangedName" event.

Because we record all the events in order and each event is immutable, we can always reconstruct the current state of the user at a later date and see exactly what led to that state. This state reconstruction is called "Projection" in Event Sourcing terminology and is fundamental to Event Sourcing.

Now, suppose you want to model a "Process" like the Temporal Workflow example at the start of this post.

1. A user clicking a button creates a "UserTrialSubscriptionStartRequested" event.
2. A "Process Manager" picks up that event, sends the user an email, and emits a "UserTrialSubscriptionStarted" event.
3. It could also set up a timer so that after the trial period ends, a "UserTrialPeriodEnded" event is fired.
4. The Process Manager detects that event, sends the user another email to let them know their trial has ended, and emits a "UserTrialSubscriptionEnded" event.

What I've outlined with "Process Managers" is exactly what a Temporal "Workflow" does but with a nicer developer experience. Temporal uses clever build-time tooling to ensure that Activities within a Workflow are the entry points when an event occurs. Because side effects are constrained to Activities, we can replay a Workflow to resume a paused state.

# Why?

So why would you want to do this? Many applications (finance, health, military, industry, etc.) need to ensure something happens and have a clear record of exactly what happened to potentially reconstruct events.

Event-based architectures like Event Sourcing and Temporal capture the system as events, then reconstruct the world from those events, rather than the other way around (a typical CRUD system). Temporal.io cleverly combines the best parts of Event Sourcing (the Process Managers) into an entirely standalone product and names it Durable Execution.

# Unanswered Questions

The Temporal docs are extensive, and there's a lot I haven't explored yet.

I've run out of time for this tinkering session, but next time I'd like to build a simple application to see what works and what doesn't. Here are some notes for next time:

- How does input validation on Workflows work? Is there input validation at all?
- Signals and Queries look interesting but a bit convoluted—need to explore those more.
- Should you use Temporal for your entire application state or just Workflow-based state? If not, how do the two combine?

# Pricing

Temporal uses a per-Action-based pricing model:

![](./actionpricing.png)

One million "actions" costs $25. This seems quite expensive since everything results in an action. For comparison, [Convex](https://www.convex.dev/pricing) charges $25 per month for 25 million function calls, and [Cloudflare](https://developers.cloudflare.com/workers/platform/pricing/) charges $0.3 per 1 million function calls.

However, I'd need to make a real app to get a proper sense of how expensive Temporal would be in practice.

# Thinking in Convex

Speaking of Convex, I can't help but think about how I might implement a "Workflow-like" structure on Convex.

I've been considering building an Event-Sourced application on Convex for a while, but I think a simpler structure via State Machines might achieve most of what you want... 🤔

Stay tuned—I may well tinker with this in the future!



As is [rapidly becoming a trend](https://mikecann.blog/posts/tinkering-with-spacetime-db) in my tinkering adventures, today's post chronicles a bit of a failed adventure. But that's okay, it's always good to explore and learn, particularly in the rapidly evolving field of AI.

# LazyAI

There are a lot of these text-to-app startups around at the moment. One of the most famous is [Devin from Cognition.ai](https://www.cognition.ai/introducing-devin). That one is not available yet, but I wanted to explore another one that has been getting some buzz lately: [Lazy.ai](https://www.getlazy.ai/).

![](./tagline.png)

Its tagline is "Idea to software 10X faster." Let's see how it does.

# The Project

As I am [a massive Convex.dev fan](https://mikecann.blog/posts/im-now-a-convex-developer-advocate), I knew it had to be something Convex related. I felt like this could be tough for the AI, as Convex is not as well-known yet, and so the LLM may not have as much pre-trained knowledge.

Something I had wanted to experiment with for a while was some sort of visualization for Convex database schemas so you can see the relationship between tables and types. I was imagining some sort of class diagram:

![](./classdiagram.png)

Or even better, a program that can generate the diagram dynamically such as [TSDiagram](https://tsdiagram.com/).

![](./tsdiagram.png)

# LazyAI Conversation

So, with that, I entered the following prompt into LazyAI:

> I would like to build an app that takes in a convex database schema and generates a Directed Acyclic Graph of the relationships between the tables and types.

It came back with a helpful plan of attack.

![](./lazy1.png)

I felt like maybe I was being a bit tough on it, so I gave it a bit more info:

> My project is TypeScript based. I want to be able to run this tool as a TypeScript script and have it analyze the convex.dev database schema that I give it. For example:

```ts
const schema = defineSchema({
  messages: defineTable({
    authorId: v.id("users"),
    body: v.string(),
    likes: v.int64(),
    replies: v.int64(),
    isReplyToMessageId: v.optional(v.id("messages")),
    imageId: v.optional(v.string()),
  }).searchIndex("search_by_body", {
    searchField: "body",
    filterFields: ["authorId"],
  }),

  users: defineTable({
    handle: v.string(),
    name: v.string(),
    pictureUrl: v.union(v.string(), v.null()),
    tokenIdentifier: v.string(),
  })
    .index("by_token", ["tokenIdentifier"])
    .index("by_handle", ["handle"]),

  lists: defineTable(
    v.union(
      v.object({
        kind: v.literal("all_messages"),
        ownerId: v.id("users"),
        name: v.string(),
      }),
      v.object({
        kind: v.literal("search"),
        ownerId: v.id("users"),
        name: v.string(),
        query: v.string(),
        includeReplies: v.boolean(),
      })
    )
  ).index("by_ownerId", ["ownerId"]),

  likes: defineTable({
    likerId: v.id("users"),
    messageId: v.id("messages"),
  })
    .index("by_likerId", ["likerId"])
    .index("by_messageId", ["messageId"])
    .index("by_messageId_likerId", ["messageId", "likerId"]),
});
```

The response it came back with was:

![](./lazy2.png)

I felt like that was actually a reasonable plan and told it to go ahead.

Now, the way the app works is that it's split into three parts: Test, Code, and Env Secrets.

![](./lazyparts.png)

So in theory, I should be able to test the output it generates. Well, this is where things unfortunately start to go off the rails a bit because to test (even your first project), you need to sign up for a pro membership.

![](./lazypro.png)

Which I would have been happy to do if I felt like the tool was going to give me some value, but the pricing scared me off.

![](./lazypricing.png)

$39.89 per month just to see if the code works and then usage costs on top of that?! No chance I was going to pay that just to check it out.

So after a little bit more back and forth with the AI, I decided to take a look at the code and copy it into VSCode to see if I could get it to run myself.

Well, unfortunately, I was to be disappointed again.

![](./lazyerrors.png)

There was no chance this code would compile or even run. There are TypeScript type errors all over the place and the imports wouldn't work from the wrong packages, etc.

I tried to give it the benefit of the doubt though and fixed the compile errors and import errors and tried to run it. Sure enough, no dice.

![](./lazyrunerror.png)

# LazyAI Conclusion

It's not ready yet. I think the task I gave it was quite tricky and maybe I was asking too much, but I think I was willing to give it the benefit of the doubt until I saw the pricing for it. Then my sympathy evaporated.

Fortunately, there are a lot of these "AI Project Generation" projects out there and as I still had a bit of time left to tinker, I thought I would give another one a go.

# Pythagora.ai

https://www.pythagora.ai/

![](./pythagora.png)

This one touts itself as a "dev tool that builds apps from scratch by talking to you." Sounds great, let's give it a shot.

This one works a little differently. It is a VSCode extension that you need to install [from the store](https://marketplace.visualstudio.com/items?itemName=PythagoraTechnologies.gpt-pilot-vs-code&ssr=false#review-details). So I headed over there and immediately was discouraged to see that it was only 3 stars out of 5. I was not off to a good start.

![](./pyreviews.png)

After a bit of a confusing setup (you have to first install another tool, gpt-pilot apparently) I had it working.

![](./pyworking.png)

(just a side note, having an AI running on my local system from an unknown developer with full access makes me kind of nervous.)

This time I was a little more generous with the initial prompt:

> I would like to build a Node.js TypeScript app that takes in a convex.dev database schema and generates a graph of the relationships between the tables and types.
>
> I want to be able to run this tool as a TypeScript script inside of my convex project and have it analyze the convex.dev database schema that I give it.
>
> I want the output to be an image that looks like something like a class diagram from classic UML.
>
> This is an example convex schema:

```ts
const schema = defineSchema({
  messages: defineTable({
    authorId: v.id("users"),
    body: v.string(),
    likes: v.int64(),
    replies: v.int64(),
    isReplyToMessageId: v.optional(v.id("messages")),
    imageId: v.optional(v.string()),
  }).searchIndex("search_by_body", {
    searchField: "body",
    filterFields: ["authorId"],
  }),

  users: defineTable({
    handle: v.string(),
    name: v.string(),
    pictureUrl: v.union(v.string(), v.null()),
    tokenIdentifier: v.string(),
  })
    .index("by_token", ["tokenIdentifier"])
    .index("by_handle", ["handle"]),

  lists: defineTable(
    v.union(
      v.object({
        kind: v.literal("all_messages"),
        ownerId: v.id("users"),
        name: v.string(),
      }),
      v.object({
        kind: v.literal("search"),
        ownerId: v.id("users"),
        name: v.string(),
        query: v.string(),
        includeReplies: v.boolean(),
      })
    )
  ).index("by_ownerId", ["ownerId"]),

  likes: defineTable({
    likerId: v.id("users"),
    messageId: v.id("messages"),
  })
    .index("by_likerId", ["likerId"])
    .index("by_messageId", ["messageId"])
    .index("by_messageId_likerId", ["messageId", "likerId"]),
});
```

Then followed a plan that the AI came up with and interestingly, it asks me before it runs commands:

![](./pycommands.png)

Ughh, it seems like it gets stuck quite easily though when something isn't installed that it needs:

[

![](./pydot.png)](./pydot.png)

I didn't want to install anything else right now, so I just clicked past it.

It seemed to continue just fine, then began installing a bunch of Node packages and setting up a TypeScript project for me, which was kind of nice.

It stops every now and then to check with you to make sure everything is looking good, which is nice.

![](./pyreview.png)

It started to generate some TypeScript. It looked like there were some errors, but I was starting to feel confident that it might be able to debug its way out of it. Then I hit:

![](./pyfreetrialover.png)

Fortunately, their pricing is much more reasonable than LazyAI and even lets you use your own OpenAI keys!

![](./pyapikey.png)

I was keen to see where this went, so I decided to spend $10 (and tip the developer) to find out.

I put together this little video to give you a sense of what the process feels like:

<iframe width="853" height="480" src="https://www.youtube.com/embed/YmhPVFl-dVE" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

Unfortunately, as can be seen from the video, the code is very broken and would not run even if I followed the instructions they gave me.

# Conclusion

Unfortunately, I had now run out of time to tinker with this any more, but I felt like it was possible that I could have gotten to something usable with Pythagora, which I didn't think was likely with LazyAI.

Could I build a graph visualization faster myself? Probably, but that's not the point. The point is that I can potentially hand this task off to my "junior developer" and have them work on it for me while I do something else, like touching grass for example (ewww).

So my takeaway is that it's not ready yet, at least these two aren't ready.

LazyAI has a long way to go, but I think I do prefer the running code in an online sandbox process over Pythagora's run the code on your local system approach, which quite frankly makes me nervous.

Running in a sandbox also means that the AI doesn't have to continually pause to ask me if it's okay to run a command (like Pythagora does), as it can simply run it without fear of damaging the underlying operating system.

I am looking forward to future versions of App Generators. In particular, [Devin](https://www.cognition.ai/introducing-devin) looks very promising and also runs in a sandbox-like environment. I added myself to their waitlist, so stay tuned. I may well revisit this in a future blog post!


Wow how fast did 2021 go? Crazy! And we are already almost at the end of January.



I try to write at least one blog post a month but I have to admit, lately I have been struggling to find the time. A combination of more [family](https://mikecann.blog/posts/joshua-christopher-cann) and more [business](https://gangbusters.io) are the likely culprits. Whatever the reasons, it means my personal projects have taken a back seat lately.

Thats not to say that there hasn't been a heap of cool stuff that has caught my eye over the past few months and am itchy to tinker with. So I thought for this month's post I would list a few of the projects that I want to take a closer look at this year :)

# Cloudflare's DOG

[BattleTabs](https://battletabs.com/) is currently [Gangbuster's](https://www.gangbusters.io/) only title and has been in development for [a couple of years](https://mikecann.blog/posts/introducing-battletabs) now. Initially it was released as a concept. We didnt know if it would work or not so I chose the technology I knew I could get going with the fastest, which was Heroku and Postgres at the time.

Since then the game has grown and the requirements have changed as we added new features. We have faced a number of challenges on Heroku and it is a continual worry of mine that the servers will fall over one day or run out of capacity when im on holiday or something. There is also the significant cost associated with Heroku compared to the alternatives.

Ideally we would move to a tech stack that supported infinite scale and not have the same operational concerns. An obvious choice would be a serverless tech stack.

The issue with a serverless stack for us would be the lack of a websocket connection to the client for realtime game updates. We need these capability to provide a great game experience for our players without resorting to less-than-optimal (and expensive) rapid polling.

[AWS does have the ability to use websockets with API Gateway](https://aws.amazon.com/blogs/compute/announcing-websocket-apis-in-amazon-api-gateway/) but when I last ran the numbers it was going to be fairly expensive and there were some significant limitations.

So when I heard about [Cloudflare's Durable Objects](https://developers.cloudflare.com/workers/learning/using-durable-objects) and their [ability to handle websockets](https://developers.cloudflare.com/workers/learning/using-websockets#:~:text=%E2%80%8BDurable%20Objects%20and%20WebSocket%20state&text=Durable%20Objects%20are%20a%20coordinated,learning%20page%20to%20get%20started.) and could do it in a [cost effective manner](https://developers.cloudflare.com/workers/platform/pricing#durable-objects) (you only pay for the message handling time) I became excited.

[In October](https://mikecann.blog/posts/serverless-databaseless-event-sourcing) I tinkered with Durable Objects to build a serverless Event-Sourcing application. This worked well but I ran out of time to try the websockets potential of the technology.

Because a single server / Durable Object can only support a limited number of connections was I needed was a way to automatically "fan-out" incoming connections to "children" automatically so that each server managed only a few thousand connections while still able to communicate with the others in the Group.

![](./fan-out.png)

Fortunately thats when I stumbled across [Cloudflare's Durable Object Groups](https://github.com/cloudflare/dog) (DOG). This is an experimental project that does just that. It takes incoming connections and fans them out to multiple "Replicas", scaling up or down the number of replicas as a needed.

I was thinking it would be cool do make a really cheap version of [Pusher](https://pusher.com/channels/pricing) using this :)

# FaunaDB

I have had my eye on serverless databases for some time now. When working in a serverless context you generally cant use databases that have heavy permanent connections such as Postges or MySQL. [Cloudflare Workers use V8 Isolates](https://developers.cloudflare.com/workers/learning/how-workers-works) which basically means that if it cant run in a web page then it cant work on Cloudflare.

So there are a number of alternatives out there such as DynamoDB, CosmosDB, Firebase, CockroachDB, MongoDB etc. They are all however either too simple (DynamoDB) or too expensive (Cosmos, Firebase) or I simply dont like using them (Mongo). [FaunaDB](https://fauna.com/) however caught my eye with its Document-but-still-Relational nature and its interesting querying options.

Thus far I have listened to a few podcasts on the technology and read a few articles and the following are some of the more interesting points for me:

## Scale & Cost

Even though DynamoDB is famous for its scaling potential there [is still a lot of operational complexity](https://docs.fauna.com/fauna/current/comparisons/compare-faunadb-vs-dynamodb#scalability) one has to worry about with scaling its usage. I like Firebase's fire-and-forget approach to scale but even it does have its limitations at upper bound of number of connections and key contention.

I havent dug very deep into this part of Fauna yet but im excited to see that [it scales](https://docs.fauna.com/fauna/current/comparisons/compare-faunadb-vs-dynamodb#scalability) with ease much like Firebase.

## GraphQL

Fauna has a number of interesting ways it can be queried including its own functional query language [FQL](https://docs.fauna.com/fauna/current/api/fql/). One option that has me curious is its [GraphQL querying option](https://docs.fauna.com/fauna/current/learn/quick_start/gql_quick_start).

If this works as advertised then it could indeed make some DB access operations much simpler. They have even solved [the n+1 problem](https://fauna.com/blog/no-more-n-1-problems-with-faunadbs-graphql-api) for access which is super cool tho I wonder what access patters it prohibits (joins?).

# SolidJS

I first heard about [SolidJS](https://www.solidjs.com/) a number of years ago and remember being impressed at its tiny file size and its [supposedly awesome performance](https://levelup.gitconnected.com/a-solid-realworld-demo-comparison-8c3363448fd8).

![](./solidjs.png)

At the time however I as perfectly comfortable with React and felt like its performance was just fine on my machine. Having worked on [BattleTabs](https://battletabs.com/), a large React app, for some time now I am feeling the pain of slow updates and large initial page load. Many of our users run on low-performance devices and thus experience this pain even more.

So the promise that SolidJS can both be a tiny download AND have incredible performance while staying familiar to the React-JSX-like way of developing has me very much intrigued.

I have worked my way [through their excellent tutorial](https://www.solidjs.com/tutorial/introduction_basics) and read a number of posts on the library and am ready to give it a shot.

The only thing I think it is missing is some NextJS / SveleteKit / RemixRun like server-side-all-batteries-included framework. [I hear that this is in the works however](https://github.com/solidjs/solid-start).

# Roc

[Roc](https://www.roc-lang.org/) is a programming language that captured my interest last year when I [watch](https://youtu.be/vzfy4EKwG_Y)e[d](https://youtu.be/6qzWm_eoUXM) a [num](https://youtu.be/cpQwtwVKAfU?t=75)b[er](https://youtu.be/ZnYa99QoznE?t=4790) of talks on the language.

Its a purely functional language heavily inspired by [Elm](https://elm-lang.org/) but unlike Elm intended to be multi-platform and thus run on the server not just the web.

I have been interested in functional languages for some time now and have tried to get into Elm on a number of occasions but other things kept getting in the way. I however really like the look of Roc which is taking the best of Elm and building on it in some pretty innovative ways.

I also have my eye on [F#](https://fsharp.org/) having [read much](https://www.amazon.com.au/Domain-Modeling-Made-Functional-Domain-Driven/dp/1680502549) on the language. Also [Clojure](https://clojure.org/) and [Elixir](https://elixir-lang.org/) are very interesting to me.

I have a lot of thoughts about functional langues and functional style in non-functional languages like Typescript but perhaps I should leave that to another post. Let me know in the comments if you would like to read more on that.

# Orleans

I have been interested in the actor model for quite some time and find it a fascinating way of building distributed systems that scale. I have read a whole heap about [Akka](https://akka.io/) and Akka.net and am keen to try both of those out.

[Orleans](https://dotnet.github.io/orleans/) from Microsoft Research takes many of the great concepts from Akka but expands and simplifies them. It touts itself as a "Virtual Actors" system and basically doesnt require explicit messages as Actors can communicate using simple function calls as if they were running as standard objects in memory with each other.

It reminds a bit of "true OO" like that found in [Smalltalk / Phaero](https://pharo.org/) but for the the .net ecosystem and distributed server-side computing.

Its a very interesting technology and I want to give it a try soon!

# Joshie

![](./joshie.jpg)

Finally this one isnt a tech project at all but still something that I hold dear to my heart. This little man is growing up so fast and I am incredibly conscious about not letting these precious moments pass me by while I have my head stuck too deep into one of my projects.

Time is passing so fast it wont be long before he gets curious about what daddy does for his work and I hopefully will have a whole new set of projects to tinker with together :)

My PC is awesome but it has a bit of an addiction to Watts. So I wanted to build a low-powered NAS and Plex server so when I put PC asleep at night I can still enjoy some quality time with my content on the TV downstairs. Since I had a spare Raspberry Pi 4 glaring at me from my desk I thought, sure why not, how hard could it be?



# Requirements

- **Low Power**, its going to be on all day so it should just sip from the fountain of joules
- **Quiet**, its going to live in my office, so I don't want it bothering me with it whining all the time
- **Flexible**, I have a bunch of old hard drives, so I want to just sling them in there and have them all just work and contribute to one large pool of "stuff"
- **Redundant**, im not storing my sons baby pics on it or anything but I would rather not loose the data either, so some sort of redundancy would be nice.
- **Powerful**, it doesnt need to be a super computer but it needs to have enough juice to transcode a 4k video
- **Low Cost**, I aint made of money, if I was I would just buy a [Drobo](https://www.drobo.com/)

# Software

[Unraid](https://unraid.net/) would have been my first choice for a NAS / Media Server but it requires an x86 CPU and the Pi is ARM so unfortunately thats a non starter.

So I decided to just go with the standard Raspbian OS, I [grabbed the ISO](https://www.raspberrypi.org/software/) smashed it on an SD card and got cracking. I setup [SSH and VNC](https://www.raspberrypi.org/documentation/computers/configuration.html) for easy access then assigned a [static IP address to the Pi using the Google Home app](https://support.google.com/wifi/answer/6274660?hl=en-AU).

After a bunch of research and experimentation (which I will not bore you with) I decided to go with [Open Media Vault](https://www.openmediavault.org/) (OMV) as my main way of managing the Pi. It provides a nice UI and set of plugins smoothing the way like a butter coated bar of soap.

[A video](https://www.youtube.com/watch?v=FYkdPyCt5FU) by the rather nerdy but very helpful [Techno Dad Life](https://www.youtube.com/channel/UCX2Vhc0LIzSS9aMzhGFZ7PA) got me going with UnionFS which merges disks together so they appear as one large file system and SnapRAID which gives me a simple way to provide redundancy to the NAS.

![](./filesystems.png)

![](./unionfs.png)

![](./snapraid.png)

The final step was to install Plex. I read a bunch of guides to installing it using OMV but they all seemed overly complicated involving Docker or other things. I found that [simply installing it natively using SSH](https://pimylifeup.com/raspberry-pi-plex-server/) worked just great.

Im making this sound all rather straight forward but by this point I had spent many nights and headaches on getting it all to work. But finally I now had a working NAS that had a single large file system that I could access from across the network. The drives were resistant to failure thanks to SnapRAID.

So with the software issues ironed out it was onto the hardware issues..

# Hardware

Its like software but harder.

Well I had the Pi.. so thats a good start. I also had two 2tb Toshiba Canivo drives that were sat around from my adventures around Australia a few years back.

![](./2tb-toshiba.jpg)

The Pi has 4 USB ports on it so I thought I could just hook up these two drives, job done. Oh no, that would be far too easy.. It turns out that the Pi, unlike a normal desktop PC, cannot deliver the full power required by a USB when multiple devices are plugged in. The result is one or both of the drives making a horrible clicking sound as it dies of power-starvation.

The solution? A powered USB hub that can deliver the required power and pass through the data communications to the Pi.

It turns out however, powered USB hubs are rather expensive at the moment for some reason. Particularly if you want each port to deliver the full power for a spinning hard drive.

I'll spare you the evening spent digging through various shopping sites looking for deals and instead show you what I ended up with:

![](./usbhub.jpg)
https://www.amazon.com.au/gp/product/B08222CYSS

This badboy cost only $19.99 and has been great. While I was there I also picked up this for $36:

![](./usbdock.jpg)
https://www.amazon.com.au/dp/B07C9RSZFM

And a couple of these for $15 each:

![](./usbadaptor.jpg)
https://www.amazon.com.au/gp/product/B011M8YACM/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1

I now had a way to get my 2 x portable drives, 2 x 2.5" drives and 2 x 3.5" drives all to work in the Pi.

I just needed a container for them all. I don't have a 3D printer to make one but thats okay because my Targét game is pretty strong, so I snagged this beaut for $8

![](./container.jpg)
https://www.target.com.au/p/rattan-plastic-storage-basket/60093127

It was just a matter of then zip-tying it all together in some semblance of order.

![](./pic1.jpg) ![](./pic2.jpg) ![](./pic3.jpg) ![](./pic4.jpg)

It actually came out pretty nice and neat, pop the lid on and then shove it in the corner and forget about it, exactly what a NAS should be.

# Conclusion

So how did I do against my goals?

- **Quiet**, yep I cant hear it at all
- **Flexible**, yep I was able to mix and match a whole range of different drives and it all just works.
- **Redundant**, with SnapRAID it should be, I haven't fully tested it yet however..
- **Powerful**, yep the Pi 4B is a very capable little device
- **Low cost**, the total I calculated (excluding the drives) was $174 AUD which is quite a bit more that I would have liked but its still far cheaper than a [Drobo](https://www.drobo.com/), even a second hand one.
- **Low Power**, yep it only uses 10w, about 0.25 kWh per day at 30 Aussie cents per kWh that works out to be about $27 per year which is acceptable and much less than what it would be if I left my PC on all the time.

![](./power.PNG)

So all in all im happy with how it all went tho there are probably better ways of doing everything, please let me know in the comments if you have done something similar or have ideas for improvements!