Forem: Paul Allies

The Zero-Rent Architecture: Designing for the Swartland Farmer

Paul Allies — Wed, 31 Dec 2025 10:48:22 +0000

The field is deep in the Swartland, two hours outside of Cape Town. It is 34 degrees Celsius, the air is thick with chaff and dust, and the nearest cell tower is blocked by a massive granite hill.

Here stands a farmer. He has just harvested 40 tonnes of wheat. He needs to log the yield, the location, and the moisture levels now, before he moves to the next block.

If I gave him a standard "Silicon Valley" app - built with a heavy frontend, fetching data from a REST API hosted in Northern Virginia, authenticated via Auth0 - that app would be useless. It would spin. It would wait. It would time out. The data would be lost, or worse, he would stop using the tool entirely because he can't trust it.

To a developer in San Francisco, "Offline Support" is an edge case - a nice-to-have feature for when you enter a subway tunnel. To this farmer, Offline is the only state that matters.

This realisation forced me to rethink how we build software for the "Real World" - the world outside of fibre-optic cities. I stopped asking, "How do I scale this to a million users?" and started asking, "How do I make this unbreakable for one user?"

The answer wasn't in the Cloud. The answer was to delete the Cloud entirely.

1. The Frictionless Handoff: No App Stores, Just a Link

The first hurdle to software adoption isn't technical; it's bureaucratic.

If I want to get a tool into this farmer's hands using the traditional route, I have to wrap it in a native shell, submit it to Apple and Google, wait for approval, and hope they don't reject it because of a minor policy violation. Then, the farmer has to open the store, search for it, remember his Apple ID password (which he forgot three years ago), and download a 150MB binary over a throttled 3G connection.

That is bloat. That is friction.

For the "Zero-Rent" architecture, I chose a different path.

When the farmer is back in his office, connected to his slow but steady Wi-Fi, I don't send him to the App Store. I send him a QR code.

He points his camera at it. The browser opens. A small prompt appears: "Add to Home Screen?"

He taps "Yes."

In three seconds, the app is installed. It sits on his home screen next to WhatsApp and Gallery. It looks native. It feels native. But it bypassed the entire multi-dollar gatekeeping industry.

This isn't just about convenience; it's about freedom. I can update the app instantly by pushing a new HTML file. I don't need permission from a corporation in California to give a farmer in Malmesbury a better tool.

Once that icon is on his screen, the internet connection becomes optional. He can walk out the door, drive 20km of dirt road into the dead zone of the fields, and the app won't care. As far as the software is concerned, the device is the entire universe.

2. The Local Backend: Why SQLite Wins

The standard way to build this app would be to use localStorage or IndexedDB. These are the "toys" of the browser world. They are fine for saving a user's dark mode preference, but they are terrifying places to store critical business data. They are unstructured, limited in size, and can be wiped by the browser on a whim.

If I want the farmer to trust his livelihood to this app, I need a real database.

My bet is on SQLite via OPFS (Origin Private File System).

This isn't some "lite" version of a database. It is the full, ACID-compliant SQL engine that powers Android, iOS, and countless desktop apps - running directly inside the browser.

By using the OPFS, we get direct, high-performance access to the device's file system.

It's Fast: Queries run in milliseconds because there is no network round-trip.
It's Relational: I can run complex SQL queries to show the farmer his "Yield per Hectare" instantly. I don't need to fetch JSON and filter it with JavaScript arrays. The database does the heavy lifting.
It's Persistent: The data lives in a protected sandbox on the phone's storage. It survives reloads, restarts, and flight mode.

In this architecture, the phone isn't a "client." The phone is the server.

The farmer creates an invoice? Saved to SQLite.

He updates inventory? Saved to SQLite.

There is no "loading spinner" because there is no "them." There is only "us." The app feels instant because the physics of the network have been removed from the equation.

3. The Internet as a "Sync Pipe"

There is one obvious risk to making the phone the server: phones are fragile. They get lost, stolen, or dropped in the mud.

If the farmer's device falls into an irrigation ditch, the data dies with it.

This is the only reason we need the internet in this architecture. We don't use it for computation; we use it for insurance. In the "Zero-Rent" model, the internet has been demoted.

The internet is no longer the Computer; it is just the Courier.

I don't need to build a complex backend API on AWS. I don't need to manage user authentication, secure endpoints, or pay for egress fees. I just need a place to put a file.

And the farmer already has one: Google Drive.

Most users in our market have a Google account. The app simply asks for permission to access a specific folder in their Drive.

When the farmer returns to the farmhouse Wi-Fi:

The app detects the connection.
It takes a snapshot of the SQLite database.
It uploads that single file to his Google Drive.

That's it.

Privacy: I (the developer) never see his data. It goes from his phone to his Drive.
Cost: I pay $0 for hosting. He pays $0 because it uses his free tier storage.
Resilience: If he buys a new phone, he logs in, pulls the file from Drive, and picks up exactly where he left off.

We have achieved "Cloud Backup" without "Cloud Dependency."

4. The "Hacker News" Defense: Addressing the Trade-Offs

I can hear the comments already. "This is naive. What about conflicts? What about real-time collaboration? What if he drops his phone in the mud before syncing?"

These are valid questions. But they also reveal a specific bias: the belief that every piece of software must support real-time, multi-user, conflict-free editing.

That belief is why modern web development is so expensive.

Here is how the "Zero-Rent" architecture answers those concerns:

Critique 1: "What if he forgets to backup?"

He doesn't have to remember. The app isn't a passive tool; it's active. Using the Background Sync API or simple connectivity listeners, the app watches the network status. The moment the phone connects to Wi-Fi, the sync triggers automatically in the background.

If he drops his phone in the mud before he gets back to Wi-Fi? Yes, he loses that day's data. But let's compare that to the alternative: A cloud-first app that refused to save the data at all because he had no signal in the field. In the Cloud scenario, the data was never born. In my scenario, it at least had a fighting chance.

Critique 2: "What about multi-user access?"

This is the hardest pill for engineers to swallow: Not every app needs to be multiplayer.

Look, I know this isn't perfect. If the farmer and his wife try to edit the exact same record at the exact same second, one of them is going to lose data. To solve that, you need a server, WebSockets, CRDTs (Conflict-Free Replicated Data Types), and - most importantly - a monthly bill to support that complexity.

But look at the use case. The farmer is in the field. The wife is in the office. They are not co-authoring a novel. They are logging disjointed events. For 90% of small businesses, "Single User" mode is sufficient.

By saying "No" to real-time collaboration, I can build this app in a week, host it for free, and it runs forever. By saying "Yes," I am signing up for months of dev time and a lifetime of maintenance.

For the wheat farmer, the feature he needs most isn't "Real-Time Collaboration." It's "It Works When I Press the Button."

Conclusion: The Future is Local

We spend so much time looking at the Silicon Valley horizon, trying to mimic their scale. We obsess over microservices, edge computing, and serverless functions because that's what Netflix and Uber do.

But in doing so, we often forget who we are actually building for.

We aren't building for Netflix. We are building for the farmer in the Swartland. We are building for the mechanic in Soweto. We are building for the coffee shop owner in Cape Town who watches their profit margin disappear into monthly SaaS fees and data bundles.

The "Zero-Rent" architecture isn't just a workaround for bad infrastructure. It is a challenge to the assumption that software must be rented, that data must live in a data centre, and that an app must stop working when the light turns red on the router.

By betting on Local-First, SQLite, and User-Owned Storage, we return power to the edges of the network.

We give the user Speed (physics beats fibre).
We give the user Ownership (their data, their drive).
We give the user Resilience (it works, always).

Africa is often treated as a market that needs to "catch up" to the West. But in a world that is becoming increasingly conscious of privacy, cloud costs, and energy efficiency, I believe the opposite is true.

By solving for the farmer, we aren't building a lesser version of the web. We are building the next version of it. A web that is lighter, faster, and more respectful of the people who use it.

Originally published at nanosoft.co.za

The Timeless Truth: Store Dates as UTC

Paul Allies — Thu, 10 Apr 2025 09:41:10 +0000

Handling dates and times can be tricky. The best practice? Always store datetimes in UTC (Coordinated Universal Time). It's a universal, consistent standard, avoiding ambiguity with time zones and DST, simplifying calculations, and ensuring historical accuracy.

While GMT is often used interchangeably, UTC is the more precise standard.

For display, format UTC to the user's local time zone. This involves identifying the user's time zone and using appropriate tools to convert and format the UTC timestamp for their context.

Store UTC, display local – for data integrity and happy users worldwide.

SKT: Optionals

Paul Allies — Mon, 24 Mar 2025 18:03:36 +0000

Handling the absence of a value is a common challenge in programming. Swift, Kotlin, and TypeScript offer solutions to this through the concept of optionals (or nullable types), though with some differences.

Swift

Swift introduces optionals to handle situations where a value may be absent. An optional variable can hold either a value or nil.

var optionalName: String? = "Alice" //Optional String
var nilName: String? = nil

//Forced unwrapping (avoid if possible)
let name = optionalName!  //CRASH if optionalName is nil

//Optional binding (safe unwrapping)
if let name = optionalName {
    print("Hello, \(name)")
} else {
    print("No name")
}

//Nil coalescing operator
let name = nilName ?? "Guest"  //Default value if nilName is nil
print("Hello, \(name)")

Kotlin

Kotlin uses nullable types to represent values that can be null. By default, types are non-nullable.

val optionalName: String? = "Alice" //Nullable String
val nilName: String? = null

//Safe call
println(optionalName?.length)  //Prints length if not null, null otherwise

//Elvis operator (null coalescing)
val name = nilName ?: "Guest"
println("Hello, $name")

//Safe call with let
optionalName?.let {
    println("Hello, $it")
}

TypeScript

TypeScript doesn't have an "optional" type in the same way as Swift or Kotlin, but it uses union types with null or undefined to represent the possibility of a missing value. Optional properties in objects also serve a similar purpose.

let optionalName: string | null = "Alice"; //String or null
let nilName: string | null = null;

//Checking for null
if (optionalName != null) { //null or undefined check
  console.log(`Hello, ${optionalName}`);
}

//Nullish coalescing operator
const name: string = nilName ?? "Guest";  // ??  null or undefined
console.log("Hello, " + name);

//Optional chaining
console.log(optionalName?.length);  //No error if optionalName is null/undefined

// Strict null checks
function greet(name: string | null) {
  if (name != null) {
    console.log("Hello, " + name.toUpperCase());
  } else {
    console.log("Hello, Guest");
  }
}
greet("Alice");
greet(null);

Key Similarities

Handling Absence of Value: All three languages provide mechanisms to handle the absence of a value.
Null Coalescing: They offer operators to provide default values when a value is absent (?? in Swift, ?: in Kotlin, ?? in TypeScript).

Key Differences

Explicit Optional Type: Swift has a dedicated optional type (?). Kotlin has nullable types (? on the type). TypeScript uses union types with null or undefined.
Unwrapping: Swift uses optional binding (if let) for safe unwrapping. Kotlin uses safe calls (?.let). TypeScript uses null checks and optional chaining (?.).
Null Safety: Kotlin and Swift are designed to be null-safe by default. TypeScript requires more explicit checks for null and undefined.

SKT: If Statements

Paul Allies — Mon, 24 Mar 2025 16:59:48 +0000

Conditional statements are fundamental to programming logic, allowing code execution to vary based on whether certain conditions are met. Let's explore how if statements work in Swift, Kotlin, and TypeScript.

Swift

Swift provides several ways to control program flow with conditional statements, most notably the if statement.

let temperature = 25

if temperature > 20 {
    print("It's warm")
} else {
    print("It's not so warm")
}

//if-else-if chain
if temperature > 30 {
    print("It's hot!")
} else if temperature > 20 {
    print("It's warm.")
} else {
    print("It's cool.")
}

Kotlin

Kotlin's if statement is similar to Swift's, but it can also be used as an expression that returns a value.

val temperature = 25

if (temperature > 20) {
    println("It's warm")
} else {
    println("It's not so warm")
}

//if-else-if chain
if (temperature > 30) {
    println("It's hot!")
} else if (temperature > 20) {
    println("It's warm.")
} else {
    println("It's cool.")
}

//Using if as an expression
val message = if (temperature > 20) "It's warm" else "It's not so warm"
println(message)

TypeScript

TypeScript's if statements are very similar to those in JavaScript, providing a familiar structure for web developers.

let temperature = 25;

if (temperature > 20) {
  console.log("It's warm");
} else {
  console.log("It's not so warm");
}

//if-else-if chain
if (temperature > 30) {
  console.log("It's hot!");
} else if (temperature > 20) {
  console.log("It's warm.");
} else {
  console.log("It's cool.");
}

//Ternary operator
const message: string = temperature > 20 ? "It's warm" : "It's not so warm";
console.log(message);

Key Similarities

Basic Structure: All three languages use the same basic structure for if statements: if condition {} else? {}.
Chaining: else if (or similar) is used to chain multiple conditions.
Boolean Conditions: The conditions within the if statements must evaluate to a boolean value (true or false).

Key Differences

Truthy/Falsy: TypeScript, like JavaScript, has the concept of "truthy" and "falsy" values, which can be used in if conditions. Swift and Kotlin require explicit boolean values.
if as Expression: Kotlin allows the if statement to be used as an expression, returning a value.

SKT: Arrays

Paul Allies — Mon, 24 Mar 2025 16:51:42 +0000

Arrays are fundamental data structures in programming, used to store collections of elements. Let's explore how arrays work in Swift, Kotlin, and TypeScript.

Swift

In Swift, arrays are ordered collections of values of the same type. Swift arrays are value types, meaning when you copy an array, you get a completely new copy, not just a reference.

// Creating an array
var numbers: [Int] = [1, 2, 3, 4, 5]
var names = ["Alice", "Bob", "Charlie"] // Type inference

// Accessing elements
let firstNumber = numbers[0] // 1
let secondName = names[1] //Accessing index 1

// Modifying arrays
numbers.append(6) // Adds 6 to the end
numbers[1] = 10    // Changes the second element to 10

// Iterating through an array
for (index, number) in numbers.enumerated() {
    print("Index: \(index), Number: \(number)")
}

Kotlin

In Kotlin, arrays can be created using the arrayOf() function, or by using specific array constructors for primitive types (e.g., intArrayOf(), doubleArrayOf()).

// Creating an array
val numbers: Array<Int> = arrayOf(1, 2, 3, 4, 5)
val names = arrayOf("Alice", "Bob", "Charlie")

val numbers2: IntArray = intArrayOf(1,2,3,4,5)

// Accessing elements
val firstNumber = numbers[0] // 1
val secondName = names[1]

// Modifying arrays
//numbers[1] = 10 //val cannot be changed
val numbers3 = intArrayOf(1,2,3,4,5)
numbers3[1] = 10
// Iterating through an array
for (index, number) in numbers.withIndex() {
    println("Index: $index, Number: $number")
}

TypeScript

TypeScript offers two ways to define arrays: using square brackets or the Array constructor. TypeScript arrays are also ordered collections, and their type system allows for strong typing.

// Creating an array
let numbers: number[] = [1, 2, 3, 4, 5];
let names: string[] = ["Alice", "Bob", "Charlie"];
let numbers2: Array<number> = [1,2,3,4,5];

// Accessing elements
let firstNumber = numbers[0]; // 1
let secondName = names[1];

// Modifying arrays
numbers.push(6);     // Adds 6 to the end
numbers[1] = 10;    // Changes the second element to 10

// Iterating through an array
for (let index = 0; index < numbers.length; index++) {
  console.log(`Index: ${index}, Number: ${numbers[index]}`);
}

Key Similarities

Ordered Collections: All three languages use arrays to store elements in a specific order.
Element Access: Elements are accessed using an index, starting from 0.
Iteration: Similar looping mechanisms are available to iterate through array elements.

Key Differences

Type Specificity: Swift and Kotlin require that all elements in an array have the same type, and while Typescript is also type-safe, it offers more flexibility due to its JavaScript heritage.
Mutability: Swift and Kotlin differentiate more explicitly between mutable and immutable arrays.
Syntax: While the basic concepts are the same, the syntax for declaring, accessing, and modifying arrays varies slightly between the languages.

SKT: Types, Numbers, Booleans, and Strings

Paul Allies — Mon, 24 Mar 2025 16:40:33 +0000

In the modern world of app and web development, three languages are making waves: Swift, Kotlin, and TypeScript (SKT). While each has its own domain (iOS, Android, and Web, respectively), they share fundamental concepts, especially when it comes to basic data types. Let's take a quick tour through numbers, booleans, and strings in these powerful languages.

Types: The Foundation

All three languages are statically typed, meaning you explicitly (or implicitly) define the type of a variable. This helps catch errors early and improves code readability.

Swift: Known for its type safety, Swift strongly encourages explicit type declarations.

Kotlin: Like Swift, Kotlin is statically typed and offers type inference, reducing boilerplate.

TypeScript: Built on JavaScript, TypeScript adds static typing, making large JavaScript projects more manageable.

Numbers: Handling Numerical Data

Numbers are essential for calculations and data manipulation.

Swift:

Swift provides various numeric types: Int (integers), Double (floating-point numbers), and Float.

let integerValue: Int = 10
let doubleValue: Double = 3.14

Kotlin:

Kotlin's numeric types are similar to Java's: Int, Double, Float, Long, Short, and Byte.

val integerValue: Int = 10
val doubleValue: Double = 3.14

TypeScript:

TypeScript has a single numeric type: number, which can represent both integers and floating-point values.

let numericValue: number = 10;
let floatValue: number = 3.14;

Booleans: Representing Truth

Booleans represent true or false values, crucial for conditional logic.

Swift:

Swift uses Bool for boolean values.

let isTrue: Bool = true
let isFalse: Bool = false

Kotlin:

Kotlin uses Boolean.

val isTrue: Boolean = true
val isFalse: Boolean = false

TypeScript:

TypeScript uses boolean.

let isTrue: boolean = true;
let isFalse: boolean = false;

Strings: Working with Text

Strings represent sequences of characters.

Swift:

Swift uses String for text.

let message: String = "Hello, Swift!"

Kotlin:

Kotlin uses String.

val message: String = "Hello, Kotlin!"

TypeScript:

TypeScript uses string.

let message: string = "Hello, TypeScript!";

Common Ground, Different Paths

While Swift, Kotlin, and TypeScript cater to different platforms, their handling of basic data types reflects a shared understanding of fundamental programming concepts. Understanding these similarities makes it easier to transition between these powerful languages.

What is Code Refactoring? A Beginner’s Guide with Simple JavaScript Examples

Paul Allies — Thu, 20 Feb 2025 07:51:31 +0000

Have you ever written code that works but feels messy, confusing, or hard to change later? That’s where code refactoring comes in! Refactoring is the process of cleaning up and improving your code without changing what it does. It’s like tidying up your room so you can find things easier and make space for new stuff.

In this blog, we’ll break down what refactoring is, why it’s important, and show you some simple JavaScript examples to help you get started.

Why Refactor Your Code?

Readability: Clean code is easier for you (and others) to understand.
Maintainability: It’s easier to fix bugs or add new features.
Performance: Sometimes refactoring can make your code run faster.
Future-Proofing: Well-organized code saves you time and headaches later.

Simple JavaScript Refactoring Examples

Let’s look at some real-world examples of refactoring in JavaScript.

Example 1: Breaking Down a Long Function

Before Refactoring

Here’s a function that does too much:

function processUserData(user) {
  // Validate user
  if (!user.name || !user.age) {
    console.log("Invalid user data");
    return;
  }

  // Format user name
  let formattedName = user.name.toUpperCase();

  // Check if user is an adult
  let isAdult = user.age >= 18;

  // Log results
  console.log(`Name: ${formattedName}, Adult: ${isAdult}`);
}

This function is doing three things: validating, formatting, and logging. It’s not terrible, but it’s harder to read and reuse.

After Refactoring

Let’s break it into smaller, reusable functions:

function validateUser(user) {
  if (!user.name || !user.age) {
    console.log("Invalid user data");
    return false;
  }
  return true;
}

function formatUserName(user) {
  return user.name.toUpperCase();
}

function isUserAdult(user) {
  return user.age >= 18;
}

function processUserData(user) {
  if (!validateUser(user)) return;

  let formattedName = formatUserName(user);
  let isAdult = isUserAdult(user);

  console.log(`Name: ${formattedName}, Adult: ${isAdult}`);
}

Now, each function has a single responsibility, and the code is easier to read and reuse.

Example 2: Simplifying Conditional Logic

Before Refactoring

Here’s a function with messy conditional logic:

function getTicketPrice(age) {
  if (age < 12) {
    return 5;
  } else if (age >= 12 && age < 18) {
    return 10;
  } else if (age >= 18 && age < 60) {
    return 20;
  } else {
    return 15;
  }
}

This works, but the conditions are repetitive and hard to follow.

After Refactoring

Let’s simplify it:

function getTicketPrice(age) {
  if (age < 12) return 5;
  if (age < 18) return 10;
  if (age < 60) return 20;
  return 15;
}

Now, the logic is cleaner and easier to understand.

Example 3: Using Descriptive Variable Names

Before Refactoring

Here’s some code with unclear variable names:

function calc(a, b) {
  let x = a + b;
  let y = x * 2;
  return y;
}

What do a, b, x, and y mean? It’s not clear.

After Refactoring

Let’s use descriptive names:

function calculateTotalWithDiscount(price, quantity) {
  let subtotal = price + quantity;
  let totalWithDiscount = subtotal * 2;
  return totalWithDiscount;
}

Now, it’s obvious what the function does and what each variable represents.

When Should You Refactor?

When You’re Adding New Features: Clean up the code before adding more to it.
When You Find Bugs: Refactoring can help you spot and fix issues.
When Code Feels “Smelly”: If something feels off (e.g., too many nested loops or unclear names), it’s time to refactor.
During Code Reviews: Refactor as you review your or others’ code.

Tips for Refactoring

Start Small: Refactor one piece at a time.
Test Your Code: Make sure it still works after refactoring.
Use Tools: Linters and formatters (like ESLint or Prettier) can help.
Write Clean Code from the Start: It’s easier to maintain clean code than to clean up messy code later.

Conclusion

Refactoring is like cleaning and organizing your code so it’s easier to work with. It doesn’t change what your code does, but it makes your life (and your team’s life) much easier. By breaking down big functions, simplifying logic, and using clear names, you can turn messy code into something beautiful and maintainable.

So, the next time you write code, take a moment to ask yourself: Can I make this cleaner? Your future self will thank you! 🚀

Creating a Responsive Side Navigation Bar with HTML, CSS, and JavaScript

Paul Allies — Tue, 18 Feb 2025 07:40:02 +0000

In this tutorial, we will build a responsive sidebar navigation menu using only HTML, CSS, and a little JavaScript. The sidebar will have the following features:

A toggle button to open and close the sidenav on mobile devices.
A collapsible menu on desktop that switches between an expanded and icon-only view.

Let's break this down into three main steps: structuring the HTML to create the foundation of the sidebar, styling with CSS to ensure a visually appealing and responsive layout, and adding interactivity with JavaScript to enable dynamic toggling between views.

1. HTML Structure

First, we define the basic structure of our page, including the sidenav, a toggle button, and a content area.

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Responsive SideNav</title>
    <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.7.2/css/all.min.css">
    <link rel="stylesheet" href="styles.css">
</head>

<body>
    <button class="toggle" onclick="toggleSidenav()">
        <i class="fa fa-bars"></i>
    </button>

    <nav id="sidenav">
        <ul>
            <li><a href="#"><i class="fa fa-home"></i><span>Home</span></a></li>
            <li><a href="#"><i class="fa fa-envelope"></i><span>Messages</span></a></li>
            <li><a href="#"><i class="fa fa-cog"></i><span>Settings</span></a></li>
        </ul>
    </nav>

    <main>
        <header>
            <h1>Welcome</h1>
        </header>
        <article>
            <section>Lorem ipsum dolor sit amet...</section>
            <section>Lorem ipsum dolor sit amet...</section>
        </article>
    </main>

    <script src="sidenav.js"></script>
</body>
</html>

Explanation:

The <nav> element contains the sidebar menu.
The toggle button (<button class="toggle">) is used to show/hide the sidebar.
The <main> section represents the main content area.

2. Styling with CSS

Now, let's style the sidenav, main content, and make it responsive.

* {
  margin: 0;
  padding: 0;
  box-sizing: border-box;
}

body {
  font-family: Arial, sans-serif;
  display: flex;
  overflow: hidden;
}

button.toggle {
  z-index: 10;
  position: fixed;
  left: 12px;
  top: 10px;
  background-color: #575757;
  color: white;
  border: none;
  padding: 10px;
  cursor: pointer;
}

nav {
  width: 250px;
  height: 100vh;
  background-color: #333;
  transition: all 0.3s;
  padding-top: 60px;

  &.min {
    width: 60px;

    span {
      opacity: 0;
    }
  }

  ul {
    color: white;

    a {
      display: flex;
      gap: 10px;
      padding: 10px 20px;
      color: white;
      text-decoration: none;
      &:hover {
        background-color: gray;
      }

      span {
        transition: opacity 0.3s ease-in-out;
      }

    }
  }
}

main {
  flex-grow: 1;
  display: flex;
  flex-direction: column;
}

header {
  height: 60px;
  display: flex;
  align-items: center;
  padding: 20px;
  border-bottom: 1px solid #ccc;
}

article {
  padding: 20px;
}

@media (max-width: 768px) {
  header {
    padding-left: 55px;
  }
  nav {
    position: fixed;
    left: -250px;
    top: 0;
  }

  nav.active {
    left: 0;
  }
}

Explanation:

The sidebar starts with a width of 250px and collapses to 60px when minimized.
On mobile (max-width: 768px), the sidebar is hidden (left: -250px) and slides in when active.
The toggle button is fixed in the top-left corner.

3. JavaScript for Interactivity

Finally, we add JavaScript to handle sidebar toggling.

function toggleSidenav() {
  const sidenav = document.querySelector("#sidenav");

  if (window.innerWidth <= 768) {
    sidenav.classList.remove("min");
    sidenav.classList.toggle("active");
  } else {
    sidenav.classList.remove("active");
    sidenav.classList.toggle("min");
  }
}

Explanation:

The function checks if the screen is mobile (max-width: 767px).
If mobile, it toggles the .active class to show/hide the menu.
If desktop, it toggles the .min class to collapse/expand the menu.

Conclusion

With this setup, we have a responsive side navigation that:

Expands and collapses on desktops.
Slides in and out on mobile devices.
Implemented using JavaScript for interactivity.

Checkout demo at https://codepen.io/nanosoftonline/pen/wBvKRgQ

Getting started with TDD: Swift Unit Testing

Paul Allies — Thu, 28 Oct 2021 06:35:53 +0000

The TDD (Test Driven Development) approach is important when it comes to testing small portions of business logic code in isolation.

In this blog, I'll cover how I would use TDD to build a clean architecture To-do SwiftUI application

I'll cover implementing the "Get To-dos" use case.

For this type of application, we need 2 types for application testing; UI Testing and Unit Testing. We'll be concentrating on the business logic, so we'll only be covering TDD unit testing. Before we write any production code, we'll write the test first.

The application will be structured in the following file and folder structure:

.
├── MyApp
    ├── Data
    │   ├── DataSource
    │   │   ├── TodoDataSource.swift
    │   │   └── DB
    │   │       ├── Entity
    │   │       │    └── TodoDBEntity.swift
    │   │       └── TodoDBDataSourceImpl.swift
    │   └── Repository
    │       └── TodoRepositoryImpl.swift
    ├── Domain
    │    ├── Model
    │    │   └── Todo.swift
    │    ├── Repository
    │    │   └── TodoRepository.swift
    │    └── UseCase
    │        └── GetTodos.swift
    └── Presentation
        ├── TodoViewModel.swift
        └── TodoListView.swift
└── MyAppTests
    ├── Data
    │   ├── DataSource
    │   │   └── DB
    │   │       └── TodoDBDataSourceImplTest.swift
    │   └── Repository
    │       └── TodoRepositoryImplTest.swift
    ├── Domain
    │    └── UseCase
    │        └── GetTodosTest.swift
    └── Presentation
        └── TodoViewModelTest.swift

We'd like to develop the "TodoViewModel" through the practice of TDD

A note on TDD

TDD is a software development process in which the unit test will be written first and after that the original code. In TDD, the design and development of the code are through unit tests.

In the traditional unit tests, the unit test is written after the original code is written. This is only for long-term maintainability. But in TDD the unit test is written first and code evolved through it.

Red Green Refactor

Red Green Refactor is an interesting concept in TDD. The stages are given below:

Red - First a failing unit test is created, and it results in red status

Green - We will modify the associated code to just make the unit test pass - resulting in green status

Refactor - Once the test is passing we can refactor the code so that the original implementation is done.

To get started with testing in your iOS SwiftUI project, we need to add a test target:

This now creates a test template:
To run the entire test suite click on the run button next to the class name or to run individual tests click the diamond button next to each test. Also note that each test needs to begin with the word "test"

Let's create the test and application file and folder structure. We'll just create the file without any production code. All development code will be driven by test code.

Let's start with our first test:

MyAppTests/Presentation/TodoViewModelTest.swift

Of course, this test doesn't build and therefore fails because the file doesn't exist.
We're in the RED Stage.

Let's write the minimum code to make the test pass.

import Foundation

class TodoViewModel: ObservableObject {

}

If we run the test again, it passes - GREEN Stage

We also notice that the View Model takes a dependency so we'll have to change the test to include the getTodosUseCase

We're back in RED stage

Let's update the view model

import Foundation

class TodoViewModel: ObservableObject {

    private var getTodosUseCase : GetTodos

    init(getTodosUseCase: GetTodos){
        self.getTodosUseCase = getTodosUseCase
    }

}

We need to create the protocol and mock implementation for GetTodosUseCase. While we are at it let's create the Todo Model

enum UseCaseError: Error{
    case dataSourceError, decodingError
}

protocol GetTodos {
    func execute() async -> Result<[Todo], UseCaseError>
}

MyApp/Domain/UseCase/GetTodos.swift

import Foundation

struct Todo: Identifiable {
    let id: Int
    let title: String
    let isCompleted: Bool
}

MyApp/Domain/Model/Todo.swift

Because we're testing and developing the view model, we don't need a GetTodos use case implementation at this stage, we will need to create a mock use case that implements the protocol

import Foundation
@testable import MyApp

class MockGetTodosUseCase: GetTodos{
    func execute() async -> Result<[Todo], UseCaseError> {
        Result.success([
            Todo(id: 1, title: "Mock Title One", isCompleted: true),
            Todo(id: 2, title: "Mock Title Two", isCompleted: false)
        ])
    }
}

MyAppTests/Domain/UseCase/MockGetTodosUseCase.swift

The test passes - GREEN stage

Let's add a few more tests to drive the development of the view model

testTodoViewModel_Should_Return_An_Empty_Todos_List

import Foundation

class TodoViewModel: ObservableObject {

    private var getTodosUseCase : GetTodos

    init(getTodosUseCase: GetTodos){
        self.getTodosUseCase = getTodosUseCase
    }

    @Published
    var todos: [Todo] = []

}

testTodoViewModel_Should_Return_2_Todos_When_getTodos_Is_Invoked

import Foundation

class TodoViewModel: ObservableObject {

    private var getTodosUseCase : GetTodos

    init(getTodosUseCase: GetTodos){
        self.getTodosUseCase = getTodosUseCase
    }

    @Published
    var todos: [Todo] = []

    func getTodos() async {

        let result = await self.getTodosUseCase.execute()
        switch result{
        case .success(let todos):
            self.todos = todos
        case .failure(_):
            self.todos = []

        }
    }
}

testTodoViewModel_Should_Display_Error_Message_When_getTodos_Results_In_Error

let's create a use case that results in an error

import Foundation
@testable import MyApp

class MockGetTodosErrorUseCase: GetTodos{
    func execute() async -> Result<[Todo], UseCaseError> {
        Result.failure(.dataSourceError)
    }
}

MyAppTests/Domain/UseCase/MockGetTodosErrorUseCase.swift

import Foundation

class TodoViewModel: ObservableObject {

    private var getTodosUseCase : GetTodos

    init(getTodosUseCase: GetTodos){
        self.getTodosUseCase = getTodosUseCase
    }

    @Published
    var todos: [Todo] = []


    @Published
    var errorMessage = ""

    func getTodos() async {

        let result = await self.getTodosUseCase.execute()
        switch result{
        case .success(let todos):
            self.todos = todos
        case .failure(let error):
            self.todos = []

            if(error == UseCaseError.dataSourceError){
                errorMessage = "Error"
            }

            if(error == UseCaseError.decodingError){
                errorMessage = "Data Decoding Error"
            }
        }
    }
}

Our test is finally picking up that the error message is incorrect. We need to rename it from "Error" to "Data Source Error" and all the tests finally pass

     if(error == UseCaseError.dataSourceError){
                errorMessage = "Data Source Error"
            }

Our code for the todo view model is finally done. We can use the same process for all other business logic in other layers.

Kotlin Dependency Injection with Hilt

Paul Allies — Mon, 25 Oct 2021 09:12:22 +0000

It is encouraged that you divide your code into classes to benefit from separation of concerns, a principle where each class of the hierarchy has a single defined responsibility. This leads to more, smaller classes that need to be connected together to fulfil each other’s dependencies.

Of course, we can use good old manual dependency injection as follows:

class MainActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {

        val viewModel = TodoViewModel(
            GetTodos = GetTodosUseCase(
                todoRepository = TodoRepositoryImpl(
                    datasource = TodoDataSourceImpl()
                )
            ),
            CreateTodo = CreateTodoUseCase(
                todoRepository = TodoRepositoryImpl(
                    datasource = TodoDataSourceImpl()
                )
            ),
            DeleteTodo =  DeleteTodoUseCase(
                todoRepository = TodoRepositoryImpl(
                    datasource = TodoDataSourceImpl()
                )
            )
        )

        super.onCreate(savedInstanceState)
        setContent {
            TodoView(viewModel)
        }
    }
}

class TodoViewModel  constructor(
    private val GetTodos: GetTodos,
    private val CreateTodo: CreateTodo,
    private val DeleteTodo: DeleteTodo
) : ViewModel() {

...

}

class GetTodosUseCase(private val todoRepository: TodoRepository) : GetTodos {
    ...
}


class TodoRepositoryImpl(private val datasource: TodoDataSource) : TodoRepository {
    ...
}

class TodoDataSourceImpl() : TodoDataSource {
    ...
}

To ease the pain of dependency injection, we are going to use Hilt to manage and resolve our dependencies.

To use Hilt, add the following build dependencies to the Android Gradle module’s build.gradle file:

plugins {
    ...
    id 'dagger.hilt.android.plugin'
}
dependencies {
    ...
    implementation 'com.google.dagger:hilt-android:2.39.1'
    implementation 'androidx.hilt:hilt-navigation-compose:1.0.0-alpha03'
    kapt "com.google.dagger:hilt-compiler:2.39.1"
    kapt "androidx.hilt:hilt-compiler:1.0.0"
}

Note: you only need “hilt-navigation-compose” if you intend to inject view models

Let’s start.

Make your project aware of Hilt and that's it’s going to do DI for you
Mark the android activity that is going to be the root or starting point of all DI
Tell Hilt how to provide instances of a ViewModel.
Mark class constructors with @Inject to tell Hilt how to create instances of a class.
Create your IOC container

Create Hilt Android App

All apps that use Hilt must contain an application class that is annotated with @HiltAndroidApp.

Create a file in the root package:

import android.app.Application
import dagger.hilt.android.HiltAndroidApp

@HiltAndroidApp
class TodoApp : Application()

Update your application name in your AndroidManifest.xml file

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.diexample">

    <application
        android:name=".TodoApp"
        ...
    >
        ...                 
    </application>

</manifest>

Mark MainActivity as AndroidEntryPoint

For Hilt to be able to inject dependencies into an activity, the activity needs to be annotated with @AndroidEntryPoint. Let’s change our MainActivity from before to:

@AndroidEntryPoint
class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            TodoView()
        }
    }
}

@Composable
fun TodoView(vm: TodoViewModel = hiltViewModel()) {
   ... 
}

Create IOC Container

Next, we create our container to list and resolve our dependencies.

@Module
@InstallIn(SingletonComponent::class)
object AppModule {

    @Provides
    @Singleton
    fun providesTodoDatasource(db: TodoDatabase): TodoDataSource {
        return TodoRoomDataSourceImpl()
    }

    @Provides
    @Singleton
    fun providesTodoRepository(dataSource: TodoDataSource): TodoRepository {
        return TodoRepositoryImpl(datasource = dataSource)
    }

    @Provides
    @Singleton
    fun providesGetTodosUseCase(repository: TodoRepository): GetTodos {
        return GetTodosUseCase(todoRepository = repository)
    }


    @Provides
    @Singleton
    fun providesCreateTodoUseCase(repository: TodoRepository): CreateTodo {
        return CreateTodoUseCase(todoRepository = repository)
    }

    @Provides
    @Singleton
    fun providesDeleteTodoUseCase(repository: TodoRepository): DeleteTodo {
        return DeleteTodoUseCase(todoRepository = repository)
    }


}

Clean Architecture: React and Typescript

Paul Allies — Mon, 25 Oct 2021 07:10:26 +0000

By employing clean architecture, you can design applications with very low coupling and independent of technical implementation details, such as databases and frameworks. That way, the application becomes easy to maintain and flexible to change. It also becomes intrinsically testable. Here I’ll show how I structure my clean architecture projects. This time we are going to build a React todo application using Typescript.

The folder/group structure of the project takes on the following form:

├── Core
├── Data
├── Domain
└── Presentation

Let’s start with the Domain Layer.

This layer describes WHAT your project/application does. Let me explain, Many applications are built and structured in a way that you cannot understand what the application does by merely looking at the folder structure. Using a building of a house analogy, you can quickly identify what a building would look like and its functionality by viewing the floor plan and elevation of the building

In the same way, the domain layer of our project should specify and describe WHAT our application does. In this folder, we would use models, repository interfaces, and use cases.

├── Core
├── Data
├── Presentation
└── Domain
    ├── Model
    │   ├── Todo.ts
    │   └── User.ts
    ├── Repository
    │   ├── TodoRepository.ts
    │   └── UserRepository.ts
    └── UseCase
        ├── Todo
        │   ├── GetTodos.ts
        │   ├── GetTodo.ts
        │   ├── DeleteTodo.ts
        │   ├── UpdateTodo.ts
        │   └── CreateTodo.ts
        └── User
            ├── GetUsers.ts
            ├── GetUser.ts
            ├── DeleteUser.ts
            ├── UpdateUser.ts
            └── CreateUser.ts

Model: A model typically represents a real-world object that is related to the problem. In this folder, we would typically keep classes to represent objects. e.g. Todo, User, Product, etc
Repository: Container for all repository interfaces. The repository is a central place to keep all model-specific operations. In this case, the Todo repository interface would describe repository methods. The actual repository implementation will be kept in the Data layer.
UseCases: Container to list all functionality of our application. e.g Get Todos, Delete Todo, Create Todo, Update Todo

The PRESENTATION layer will keep all of the consumer-related code as to HOW the application will interact with the outside world. The presentation layer can be WebForms, Command Line Interface, API Endpoints, etc. In this case, it would be the screens for a List of Todos and its accompanying view model.

├── Core
├── Data
├── Domain
└── Presentation
    └── Todo
        └── TodoList
            ├── TodoListViewModel.tsx
            └── TodoListView.tsx

The DATA layer will keep all the external dependency-related code as to HOW they are implemented:

├── Core
├── Domain
├── Presentation
└── Data
    ├── Repository
    │   ├── TodoRepositoryImpl.ts
    └── DataSource
        ├── TodoDataSource.ts
        ├── API
        │   ├── TodoAPIDataSourceImpl.ts
        │   └── Entity
        │       ├── TodoAPIEntity.ts
        │       └── UserAPIEntity.ts
        └── DB
            ├── TodoDBDataSourceImpl.ts
            └── Entity
                ├── TodoDBEntity.ts
                └── UserDBEntity.ts

Repository: Repository implementations
DataSource: All data source interfaces and entities. An entity represents a single instance of your domain object saved into the database as a record. It has some attributes that we represent as columns in our DB tables or API endpoints. We can’t control how data is modeled on the external data source, so these entities are required to be mapped from entities to domain models in the implementations

and lastly, the CORE layer keep all the components that are common across all layers like constants or configs or dependency injection (which we won’t cover)
Our first task would be always to start with the domain models and data entities. Let’s start with the model

//Domain/Model/Todo.ts
export interface Todo {
  id: number;
  title: string;
  isComplete: boolean;
}

We need it to conform to Identifiable as we’re going to display these items in a list view.

Next, let’s do the todo entity

//Data/DataSource/API/Entity/TodoAPIEntity.ts
export interface TodoAPIEntity {
  id: number;
  title: string;
  completed: boolean;
}

Let’s now write an interface for the TodoDatasource

//Data/DataSource/TodoDataSource.ts
import { Todo } from "../../Domain/Model/Todo";

export default interface TodoDataSource {
  getTodos(): Promise<Todo[]>;
}

We have enough to write an implementation of this interface and we’ll call it TodoAPIImpl:

import { Todo } from "../../../Domain/Model/Todo";
import TodoDataSource from "../TodoDataSource";
import { TodoAPIEntity } from "./Entity/TodoAPIEntity";

const BASE_URL = "https://jsonplaceholder.typicode.com";

interface TypedResponse<T = any> extends Response {
  json<P = T>(): Promise<P>;
}

function myFetch<T>(...args: any): Promise<TypedResponse<T>> {
  return fetch.apply(window, args);
}

export default class TodoAPIDataSourceImpl implements TodoDataSource {
  async getTodos(): Promise<Todo[]> {
    let response = await myFetch<TodoAPIEntity[]>(`${BASE_URL}/todos`);
    let data = await response.json();
    return data.map((item) => ({
      id: item.id,
      title: item.title,
      isComplete: item.completed,
    }));
  }
}

Note: this data source's getTodos function returns a list of Todo. So, we have to map TodoEntity -> Todo:
Before we write our TodoRepositoryImpl let’s write the interface for that in the Domain layer

//Domain/Repository/TodoRepository.ts
import { Todo } from "../Model/Todo";

export interface TodoRepository {
  getTodos(): Promise<Todo[]>;
}

//Data/Repository/TodoRepositoryImpl.ts
import { Todo } from "../../Domain/Model/Todo";
import { TodoRepository } from "../../Domain/Repository/TodoRepository";
import TodoDataSource from "../DataSource/TodoDataSource";

export class TodoRepositoryImpl implements TodoRepository {
  dataSource: TodoDataSource;

  constructor(_datasource: TodoDataSource) {
    this.dataSource = _datasource;
  }

  async getTodos(): Promise<Todo[]> {
    return this.dataSource.getTodos();
  }
}

Now that we have our todo repository, we can code up the GetTodos use case

//Domain/UseCase/GetTodos.ts
import { Todo } from "../Model/Todo";
import { TodoRepository } from "../Repository/TodoRepository";

export interface GetTodos {
  invoke(): Promise<Todo[]>;
}

export class GetTodosUseCase implements GetTodos {
  private todoRepo: TodoRepository;

  constructor(_todoRepo: TodoRepository) {
    this.todoRepo = _todoRepo;
  }
  async invoke(): Promise<Todo[]> {
    return this.todoRepo.getTodos();
  }
}

and then in turn we can write our presentation’s view model and view

//Presentation/View/Todo/TodoListViewModel.ts
import { useState } from "react";
import TodoAPIDataSourceImpl from "../../../Data/DataSource/API/TodoAPIDataSourceImpl";
import { TodoRepositoryImpl } from "../../../Data/Repository/TodoRepositoryImpl";
import { Todo } from "../../../Domain/Model/Todo";
import { GetTodosUseCase } from "../../../Domain/UseCase/GetTodos";

export default function TodoViewModel() {
  const [todos, setTodos] = useState<Todo[]>([]);

  const UseCase = new GetTodosUseCase(
    new TodoRepositoryImpl(new TodoAPIDataSourceImpl())
  );

  async function getTodos() {
    setTodos(await UseCase.invoke());
  }

  return {
    getTodos,
    todos,
  };
}

//Presentation/Views/Todo/TodoListView.ts
import { useEffect } from "react";
import useViewModel from "./TodoListViewModel";
import {
  List,
  ListItem,
  ListItemIcon,
  Checkbox,
  ListItemText,
} from "@mui/material";

export default function TodoView() {
  const { getTodos, todos } = useViewModel();

  useEffect(() => {
    getTodos();
  }, []);

  return (
    <List>
      {todos.map((todo, i) => {
        return (
          <ListItem key={i}>
            <ListItemIcon>
              <Checkbox checked={todo.isComplete} />
            </ListItemIcon>
            <ListItemText primary={todo.title} />
          </ListItem>
        );
      })}
    </List>
  );
}

So to recap:

CoreData and Swift

Paul Allies — Tue, 19 Oct 2021 13:55:07 +0000

Continuing with our clean architecture, let's write a simple Todo CoreData Datasource in swift. Our applications repository method would use the a DataSource, in this case the TodoCoreDataSource. Here is a proposed files and their locations:

├── Core
└── Data
    ├── DataSource
        ├── TodoDataSource.swift
        └── CoreData
            ├── Main.xcdatamodeld
            └── TodoCoreDataSourceImpl.swift
    ├── Repository
        └── TodoRepositoryImpl.swift

├── Presentation
└── Domain
    ├── Model
    │   └── Todo.swift
    ├── Error
    │   └── TodoError.swift
    └── Repository
        └── TodoRepository.swift

Let's first specify our Domain Model and Repository

Domain/Model/Todo.swift

struct Todo: Identifiable{
    let id: UUID
    let title: String
    let isCompleted: Bool
}

Domain/Error/TodoError.swift

enum TodoError: Error{
    case DataSourceError, CreateError, DeleteError, UpdateError, FetchError
}

Domain/Repository/TodoRepository.swift

protocol TodoRepository {
    func getTodos() async  -> Result<[Todo], TodoError>
    func getTodo(id: UUID) async  -> Result<Todo? , TodoError>
    func deleteTodo(_ id: UUID) async  -> Result<Bool, TodoError>
    func createTodo(_ todo: Todo) async  -> Result<Bool, TodoError>
    func updateTodo(_ todo: Todo) async  -> Result<Bool, TodoError>
}

Data/DataSource/TodoDataSource.swift

protocol TodoDataSource{
    func getAll() async throws -> [Todo]
    func getById(_ id: UUID) async throws  -> Todo?
    func delete(_ id: UUID) async throws -> ()
    func create(todo: Todo) async throws -> ()
    func update(id: UUID, todo: Todo) async throws -> ()
}

let's now create a CoreData Model by adding a new file and choosing Core Data -> Data Model and creating at TodoCoreDataEntity:

Domain/DataSource/CoreData/Main.xcdatamodeld

To use the CoreData Main Model we need to create a data source that conforms to the TodoDataSource so that our TodoRepository can use it:

struct TodoCoreDataSourceImpl: TodoDataSource {
    let container: NSPersistentContainer

    init(){
        container = NSPersistentContainer(name: "Main")
        container.loadPersistentStores { description, error in
            if error != nil {
                fatalError("Cannot Load Core Data Model")
            }
        }
    }

    func getAll() throws -> [Todo]{
        let request = TodoCoreDataEntity.fetchRequest()
        return try container.viewContext.fetch(request).map({ todoCoreDataEntity in
            Todo(
                id: todoCoreDataEntity.id!,
                 title: todoCoreDataEntity.title!,
                isCompleted: todoCoreDataEntity.is_completed
            )
        })

    }

    func getById(_ id: UUID)  throws  -> Todo?{
        let todoCoreDataEntity = try getEntityById(id)!
        return Todo(
            id: todoCoreDataEntity.id!,
            title: todoCoreDataEntity.title!,
            isCompleted: todoCoreDataEntity.is_completed
        )

    }

    func delete(_ id: UUID) throws -> (){
        let todoCoreDataEntity = try getEntityById(id)!
        let context = container.viewContext;
        context.delete(todoCoreDataEntity)
        do{
            try context.save()
        }catch{
            context.rollback()
            fatalError("Error: \(error.localizedDescription)")
        }

    }

    func update(id: UUID, todo: Todo) throws -> (){
        let todoCoreDataEntity = try getEntityById(id)!
        todoCoreDataEntity.is_completed = todo.isCompleted
        todoCoreDataEntity.title = todo.title
        saveContext()
    }

    func create(todo: Todo) throws -> (){
        let todoCoreDataEntity = TodoCoreDataEntity(context: container.viewContext)
        todoCoreDataEntity.is_completed = todo.isCompleted
        todoCoreDataEntity.title = todo.title
        todoCoreDataEntity.id = todo.id
        saveContext()
    }


    private func getEntityById(_ id: UUID)  throws  -> TodoCoreDataEntity?{
        let request = TodoCoreDataEntity.fetchRequest()
        request.fetchLimit = 1
        request.predicate = NSPredicate(
            format: "id = %@", id.uuidString)
        let context =  container.viewContext
        let todoCoreDataEntity = try context.fetch(request)[0]
        return todoCoreDataEntity

    }

    private func saveContext(){
        let context = container.viewContext
        if context.hasChanges {
            do{
                try context.save()
            }catch{
                fatalError("Error: \(error.localizedDescription)")
            }
        }
    }

}

and then lastly our TodoRepositoryImpl would implement our TodoRepository and call our Datasource:

struct TodoRepositoryImpl: TodoRepository{

    var dataSource: TodoDataSource

    func getTodo(id: UUID) async  -> Result<Todo?, TodoError> {
        do{
            let _todo =  try await dataSource.getById(id)
            return .success(_todo)
        }catch{
            return .failure(.FetchError)
        }

    }

    func deleteTodo(_ id: UUID) async ->  Result<Bool, TodoError>  {
        do{
            try await dataSource.delete(id)
            return .success(true)
        }catch{
            return .failure(.DeleteError)
        }

    }

    func createTodo(_ todo: Todo) async ->  Result<Bool, TodoError>   {
        do{
            try await dataSource.create(todo: todo)
            return .success(true)
        }catch{
            return .failure(.CreateError)
        }

    }

    func updateTodo(_ todo: Todo) async ->  Result<Bool, TodoError>   {
        do{
            try await dataSource.update(id: todo.id, todo:todo)
            return .success(true)
        }catch{
            return .failure(.UpdateError)
        }

    }

    func getTodos() async -> Result<[Todo], TodoError> {
        do{
            let _todos =  try await dataSource.getAll()
            return .success(_todos)
        }catch{
            return .failure(.FetchError)
        }
    }
}