DEV Community: Almaju

Building an iOS App with Rust Using UniFFI

Almaju — Tue, 17 Jun 2025 20:57:48 +0000

Developing iOS applications typically involves languages like Swift or Objective-C. However, with the advent of Rust, a systems programming language known for its safety and performance, and UniFFI, an interface generator for Rust, it's now possible to create iOS apps in Rust. In this blog post, we'll guide you through the process of building a simple iOS app using Rust and UniFFI.

Prerequisites

Before we begin, ensure you have the following installed:

Rust: Install it from the official Rust website.
Xcode: Available on the Mac App Store.

Step 1: Setting Up Your Rust Library

Start by creating a new Rust library.

cargo new app --lib

Add uniffi to your Cargo.toml file:

[lib]
crate_type = ["cdylib", "staticlib"]
name = "mobile"

[dependencies]
uniffi = { version = "0.25.3", features = [ "cli" ] }

Change your lib.rs file. Here's a basic example:

uniffi::setup_scaffolding!();

#[uniffi::export]
fn say_hi() -> String {
    "Hello from Rust!".to_string()
}

We need uniffi-bindgen as a CLI tool.

fn main() {
    uniffi::uniffi_bindgen_main()
}

Build the library:

cargo build

In target/debug, you should find the libmobile.dylib file.

Generate the bindings:

cargo run --bin uniffi-bindgen generate --library ./target/debug/libmobile.dylib --language swift --out-dir ./bindings

Step 2: Building the iOS binaries

Add these targets to Rust:

rustup target add aarch64-apple-ios-sim aarch64-apple-ios

Build the library for Swift:

cargo build --release --target=aarch64-apple-ios-sim
cargo build --release --target=aarch64-apple-ios

You should have two binaries target/aarch64-apple-ios-sim/release/libmobile.a and target/aarch64-apple-ios/release/libmobile.a.

Step 3: Creating the XCFramework

The XCFramework will allow us to import the library with zero effort in Xcode.

First, we need to rename the file bindings/mobileFFI.modulemap to bindings/module.modulemap.

It is important to rename the file to module.modulemap because Xcode will
not be able to find the module otherwise.

Then, we can create the XCFramework:

xcodebuild -create-xcframework \
        -library ./target/aarch64-apple-ios-sim/release/libmobile.a -headers ./bindings \
        -library ./target/aarch64-apple-ios/release/libmobile.a -headers ./bindings \
        -output "ios/Mobile.xcframework"

Set 4: Import the library in Xcode

Create a new iOS app in Xcode.

Import both the XCFramework Mobile.xcframework and the Swift file bindings bindings/Mobile.swift files into your project (drag and drop should work).

You should be good to go!

import SwiftUI

struct ContentView: View {
    var body: some View {
        VStack {
            Image(systemName: "globe")
                .imageScale(.large)
                .foregroundStyle(.tint)
            Text(sayHi()) // <-- Here we call the Rust function
                .padding()
        }
        .padding()
    }
}

Putting everything together

Create a script named build-ios.sh. This script automates the process of building your Rust library for various iOS targets.

#!/bin/bash

# Build the dylib
cargo build

# Generate bindings
cargo run --bin uniffi-bindgen generate --library ./target/debug/libmobile.dylib --language swift --out-dir ./bindings

# Add the iOS targets and build
for TARGET in \
        aarch64-apple-darwin \
        aarch64-apple-ios \
        aarch64-apple-ios-sim \
        x86_64-apple-darwin \
        x86_64-apple-ios
do
    rustup target add $TARGET
    cargo build --release --target=$TARGET
done

# Rename *.modulemap to module.modulemap
mv ./bindings/mobileFFI.modulemap ./bindings/module.modulemap

# Move the Swift file to the project
rm ./ios/TodoList/Mobile.swift
mv ./bindings/mobile.swift ./ios/TodoList/Mobile.swift

# Recreate XCFramework
rm -rf "ios/Mobile.xcframework"
xcodebuild -create-xcframework \
        -library ./target/aarch64-apple-ios-sim/release/libmobile.a -headers ./bindings \
        -library ./target/aarch64-apple-ios/release/libmobile.a -headers ./bindings \
        -output "ios/Mobile.xcframework"

# Cleanup
rm -rf bindings

The Molecular Architecture

Almaju — Fri, 24 Jan 2025 18:57:08 +0000

We’ve all been there: you start a new project with the best intentions—maybe a Clean Architecture or Onion Architecture approach. You dutifully separate your layers: domain, application, infrastructure, interfaces, and so on. You create ports, adapters, repositories, aggregates, entities… and before you know it, you’re 15 files deep just to implement the simplest feature, trying to remember what the difference is between a “service interface” and a “domain interface.” By the time you add business logic, the overhead is huge, and half your code is either duplicative or plain boilerplate.

Molecular Architecture is a different way to tackle Domain-Driven Design. It’s not about ignoring domains; quite the opposite. The idea is to cut the nonsense and put your attention exactly where it belongs: on meaningful “working pieces of software” that directly represent your domain concepts, without the detour of excessive layers, abstract repositories, or adapters everywhere.

If you’ve ever wished you could treat each domain feature like a mini-application—runnable on its own when needed, but also easy to assemble into a bigger whole—then you’re in the right place. Think of it like microservices or "islands" within a single codebase, except you’re not spinning up 50 containers and deploying them separately. You have one codebase, with multiple self-contained modules (“molecules”) that can be run independently or combined.

Core Philosophy: Working Pieces of Software

At the heart of Molecular Architecture is the concept of a Working Piece of Software. Each module (or “molecule”) should:

Stand Alone – It contains everything it needs to run by itself: database schema, HTTP controllers, domain logic, user interface (if relevant), etc.
Solve One Domain Problem – Each module represents a coherent domain concept (e.g., TodoList, Chat, Auth, Payments, etc.).
Export What It Needs – Each module can be executed on its own (think node run TodoList), but it can also provide a library-like interface for bigger modules to consume.
Hide What’s Irrelevant – Don’t leak internal details if other modules don’t need them. This also helps keep the domain boundaries clearer.

Why Bother?

Why do this instead of layering up everything with Clean Architecture? Because layering can lead to large, horizontally bloated folders where your actual business logic gets drowned out by repetitive code. You end up writing a domain model, an application service, a repository interface, a repository implementation, a data mapper, a controller, an adapter, a port… you get the idea.

Molecular Architecture says: Stop. If you have a concept called TodoList, just make a module called TodoList. It can have a file or two (or a folder) where all domain logic, data handling, and external integrations for that concept live together. Then you decide if you want to spin it up alone or plug it into a larger app.

A Quick Comparison with Traditional Architectures

Clean/Onion Architecture
- Pros: Clear separation of concerns, well-defined layers, testability (via ports/adapters).
- Cons: Often leads to a lot of boilerplate, forcing you to create multiple classes/files for even trivial features. The lines between “infrastructure” and “domain” can become fuzzy (e.g., where do you put a simple array merge? Is that “technical” or “business”?).
Microservices
- Pros: Each service is autonomous; you can scale or deploy them separately.
- Cons: Infrastructure overhead, network boundaries, distributed system complexity. Overkill for many projects that don’t need that level of separation in production.
Molecular Architecture
- Pros: Minimal overhead, domain-focused, easy to remove or “kill” a feature by removing its folder, truly independent modules that can stand alone for testing or demonstration. It’s like microservices but all within a single process (unless you really want to break them out).
- Cons: You do need to carefully plan module boundaries and the dependency graph. Some code can become duplicated if you’re not disciplined about shared libraries. Testing might require a slightly different approach than the standard “mock everything” style.

Lego-Style Organization

Think of your system as a box of Lego bricks:

Each molecule (brick) is a self-contained feature or domain concept (e.g. Chat, TodoList).
Larger features (bigger bricks) can incorporate smaller bricks. For example, an App module might combine Chat and TodoList.
The direction of dependencies is crucial: if Auth depends on TodoList, then TodoList must not depend on Auth. Keep it unidirectional to avoid circular references.

And the coolest part? If you decide you don’t want the Chat feature anymore, just remove the Chat folder. No leftover references scattered across your “infrastructure layer,” no big toggles or feature flags. Gone is gone.

Example Project Structure

Let’s illustrate a potential Node.js/TypeScript folder structure for a small system that has two main domain modules: TodoList and Chat. We’ll have a third “wrapper” module called App that orchestrates them.

my-cool-project/
  ├─ lib/
  │   ├─ sql-service.ts     // Shared library for SQL
  │   └─ uuid.ts           // Shared library for generating UUIDs
  │
  ├─ modules/
  │   ├─ todo-list/
  │   │   ├─ todo-list.ts
  │   │   ├─ task.ts
  │   │   └─ main.ts       // "Run" the TodoList module directly
  │   │
  │   ├─ chat/
  │   │   ├─ chat.ts
  │   │   ├─ conversation.ts
  │   │   ├─ message.ts
  │   │   └─ main.ts       // "Run" the Chat module directly
  │   │
  │   └─ app/
  │       └─ main.ts       // This is the aggregator that runs everything
  │
  └─ package.json

Example: `todo-list/main.ts` (Runnable Entry Point)

import { createServer } from 'http';
import { SqlService } from '../../lib/sql-service';
import { TodoList } from './todo-list';

async function main() {
  // 1. Initialize your DB service (could be remote or in-memory)
  const db = SqlService.make({ mode: 'remote' }); // or 'in-memory' for testing

  // 2. Apply schema
  await TodoList.init(db);

  // 3. Create the HTTP server
  const server = createServer((req, res) => {
    // Suppose we have an HTTP controller that handles routes
    TodoList.start(db, req, res);
  });

  // 4. Start listening
  server.listen(3001, () => {
    console.log('TodoList module is running on port 3001!');
  });
}

In this setup:

TodoList can run solo by doing node modules/todo-list/main.js.
Chat can run solo by doing node modules/chat/main.js.
App runs them both, orchestrating how they might interrelate.

That’s the gist: each module has a main.ts that literally runs it. In bigger systems, you might have advanced ways to integrate them—like an API gateway or a shared UI. But the principle remains: each domain concept is encapsulated in its own place, with everything it needs.

Testing Strategy: No (or Minimal) Mocks

One of the common arguments for layered architectures is that they make tests simpler by letting you “inject” different infrastructure adapters. Molecular Architecture handles this differently:

In-Memory vs Remote

If you have a SqlService, it can be configured at startup to either connect to a real database or run in an in-memory mode (SQLite in-memory, for instance). That means no complicated mocking is required—just a different initialization parameter.
Functional Testing

Because each module is fully runnable, you can spin it up and test it end-to-end. This can be more reliable than unit tests that mock half the universe.
Shared Services

For truly domain-agnostic utilities—like generating UUIDs, handling date/time, or logging—put them in a lib/ folder. They don’t hold domain logic, so they’re easy to keep stable and test in isolation.

Example: Setting up a Test DB Mode

// lib/sql-service.ts

export function SqlService(mode: 'in-memory' | 'remote') {
  if (options.mode === 'in-memory') {
    // Return an in-memory DB instance, e.g. using SQLite
  } else {
    // Remote mode
  }
}

In your test, you’d do:

import { SqlService } from '../lib/SqlService';

test('TodoList creation works', async () => {
  const db = SqlService('in-memory');

  // Then call your domain logic, e.g. create a new todo list
  // Confirm results with in-memory checks
});

No MockSQLService, no separate adapter. Just a single service that can switch modes.

Handling the Dependency Graph

One challenge (and also a key benefit) of Molecular Architecture is that you end up with a more explicit dependency graph. For instance:

Auth depends on User.
TodoList depends on Auth (maybe you need to check if the user is logged in).
Chat depends on User as well.
App depends on TodoList, Chat, and Auth.

You might even create small bridging modules if needed. For example, if User and TodoList need some special integration logic, you can create a tiny bridging module called user-todo-integration that depends on both. The rest of the system can choose to integrate that bridging module or not.

Yes, it’s more “mental overhead.” But you’re forced to think about the domain relationships. That’s the entire selling point of Domain-Driven Design—understanding and modeling your domain clearly. If a certain relationship is ambiguous or cyclical, that’s a sign to revisit your domain boundaries.

Addressing Common Critiques

1. “Isn’t This Just Microservices?”

Not exactly. You’re not forced to spin each module up as a separate process or container. You can if you want, but the default idea here is a single deployment artifact. The microservices-like advantage is that each feature is so well-isolated that you could peel it off if you ever needed to. Or you can keep it all in one monolith that’s easy to deploy.

2. “What About Repos, Entities, Aggregates?”

If your domain truly needs them, you can absolutely have classes or files named “Entity” or “Aggregate.” But you don’t have to. You might find that a straightforward approach—like a class or function called TodoList with methods like addTask, removeTask—is enough. The key difference is you’re not forced to make a repository interface, a repository implementation, a domain entity, a domain interface, etc., just to store a row in the database.

3. “Layers Are Good for Separation of Concerns!”

Layers can be good, but they can also be overkill, especially when they artificially break up code that’s conceptually about the same thing. In Molecular Architecture, you can still separate business logic from technical code—just do it within the same module. For instance, have a todolist-business.ts file with business logic and a todolist-db.ts file with database logic inside your todo-list module. That’s a smaller-scale layering that doesn’t lead to a system-wide sprawl.

4. “Won’t We End Up Duplicating Code?”

Potentially, yes—if multiple modules implement the same feature logic. The remedy is to pull truly shared code into a library module that is domain-neutral. Or, if the code is domain-specific, decide which domain “owns” it and let other domains depend on it in a unidirectional fashion. The key is to keep it explicit.

The Beauty of Killing Features

One of the underrated superpowers of Molecular Architecture is how trivial it is to remove a feature. Let’s say you built a “Chat” feature for your product, but nobody uses it. In a layered monolith, that code might be peppered across domain/, app/, infra/, db migrations, who knows where else. In Molecular Architecture, you literally:

Delete the chat module folder.
Remove its mention from app/main.ts (if it was aggregated).
Done.

No messing around with feature flags or complicated branching. If the rest of your domain needed “just the user’s name” for something in Chat, they should’ve gotten it from the User module, not from Chat. So your domain dependencies remain unaffected (or they break loudly if they were incorrectly reaching into Chat’s domain—good, now you can fix that).

Points of Weakness (And Why We Accept Them)

Complex Dependency Graph

Yes, figuring out which module depends on which can be more work up front. But that’s the domain modeling you’re supposed to be doing anyway. If it’s complicated, it might reflect real domain complexity.
Potential Duplication

If you don’t define clear boundaries or shared libraries, you might rewrite the same logic in multiple modules. The solution is to carefully factor out domain-agnostic code into a library. For domain-specific logic, decide which module truly owns it.
Testing Without Mocks

Some developers love mocking everything. This architecture tends to prefer real (but configurable) services—like an in-memory DB for tests. It’s a matter of taste, but we argue it leads to more reliable tests and less mock scaffolding.
Scalability

As your application grows, you must keep modules well-structured, watch for cyclical dependencies, and maintain clarity in how the domain is split. This is an ongoing effort, but you’d be doing something similar with bounding contexts in a traditional DDD approach anyway.

Final Thoughts

Molecular Architecture is about focusing on meaningful domain concepts and building fully functional chunks of software around them. It’s:

Pragmatic: Instead of layering your domain into oblivion, you keep the code close together—domain logic, database schema, and interfaces that matter to that domain.
Flexible: Each module can be developed, tested, and even run independently.
Explicit: Dependencies are actual references between modules, not hidden behind an ocean of adapters and abstract interfaces. You have to think about them, which is the whole point.
Removable: If a feature isn’t needed, kill it. Delete the folder, remove it from the aggregator. Done.

Yes, you’ll spend more time discussing and refining your module boundaries and dependency graph. But that’s domain-driven design in a nutshell—tackling the real complexity head-on, not burying it in layers. Meanwhile, you avoid the swirling black hole of 50-file sprawl for every little feature.

If you’re looking for a middle ground between microservices and monolithic layered architectures, give Molecular Architecture a shot. It lets you keep a single app in production, but develop your features as if they were independent micro-applications. It’s domain-driven design made practical, without forcing you to write novel-length code just to store a single row in a database.

Happy building—go forth and assemble your molecules!

6 Rules to Write Better Programs at Scale

Almaju — Wed, 14 Aug 2024 08:52:59 +0000

1. Choose One Pair of Scissors

Imagine you’re cutting a piece of paper. Some might reach for scissors, others a knife, or maybe even fold and tear it by hand. Experimenting with different methods is fine, but if our goal is to cut paper all day—and do it efficiently—we need to agree on one method. Let's pick scissors: they’re consistent and safer, though that doesn’t mean they’re inherently better than other methods. It just means we’ve agreed, as a team, that this is our go-to approach.

The same applies to our work. In some programming languages, like Gleam, there’s one clear way to do things, making it easier to stay focused. But in TypeScript, the options are endless—no set file naming conventions, multiple ways to export, string concatenation, nullable values and debates over mutability, classes, and variables. Without a consistent approach, it can quickly become a free-for-all, with everyone doing things their way.

That’s why we need a single agreed-upon method, documented or verbally agreed upon. This doesn’t mean we can’t ever challenge the status quo—if we find a better way, we should discuss it as a team. But if we do decide to change, we need to commit fully, refactoring our work to avoid a confusing mix of old and new methods. What is our file naming convention? Do we default or named exports? Do we use null or undefined? All of these questions need an answer to maintain consistency.

Bad Code:

const MyFunction = () => "";
const myFunction = () => "";
const my_function = () => "";
// Make up your mind!

Key Takeaways:

Consistency matters: Agree on one way to do things to avoid chaos.
Document the standard: Whether written or verbal, make sure everyone’s on the same page.
Stay flexible, but committed: Challenge the standard if needed, but fully commit to changes.

2. A Notebook Page Needs a Title

Think of your code like a notebook. When I jot down ideas, I always put a big, clear title at the top of each page, so I can easily find what I'm looking for later. I also start a new page for each new idea, and if I need to reference another page, I write it in all caps to make it obvious. Now, imagine if I didn’t do this—if I mixed all my ideas together on the same pages, drawing arrows between them. It would be a mess, like trying to navigate a chaotic maze!

This is exactly the kind of organization we need in our code. Too often, I see files that are like those messy notebook pages—packed with multiple ideas, repeating concepts, and tangled references that create spaghetti code.

Now, you might think this is just common sense. But let me ask: do you have a helpers folder filled with random functions, like capitalize, just because you didn’t know where else to put them? Maybe you even have the same function duplicated because someone didn’t know it was already there.

Instead of stuffing everything into these catch-all files, think about the concepts behind your code. For example, instead of throwing a capitalize function into a generic text-utils.ts file, consider what you’re really working with—a word. Create a word.ts file that focuses solely on the concept of a word, and put all related functions there. This makes your code more meaningful and organized, eliminating the need for vague “helpers” or “utils” folders.

Good Code:

// word.ts
export type Word = string;

export const capitalize = (self: Word) =>
  string.charAt(0).toUpperCase() + string.slice(1);

Key Takeaways:

One file, one concept: Keep each file focused on a single idea.
Mindful references: Only mention other concepts, don’t define or manipulate them in the same file.
Clear structure: Start your file with a type definition to set the subject, followed by functions that interact with that concept.

3. Stop Using a Wrench as a Hammer

Imagine you’re building a house. Now, you could use basic tools like a hammer and nails for everything—sure, they’ll get the job done, but wouldn’t it be better if you had a saw for cutting wood, a level for checking alignment, and a wrench for tightening bolts? Each tool is designed for a specific task, making the work not only easier but also more precise and professional. It’s the same in programming.

Too often, we rely on basic data structures like strings, numbers, objects, and promises. They’re flexible and can represent many things, but leaning on them too much is like building a house with just a hammer and nails. We have the opportunity to represent our ideas more clearly and efficiently by using more specialized structures—without the extra burden of deciphering complex functions.

Think about HTML. Technically, you could build an entire webpage using just <div>, <a>, and <input>. But wouldn’t it be nicer to use elements like lists, headings, and navbars? Clean HTML code allows you to understand the structure and purpose of the page at a glance, without needing to see the final design or inspect the CSS. The same principle applies to programming:

Want to represent errors as values? Use a Result<T, E> structure.
Want to ensure a string is never empty? Try newtype patterns.
Managing unique documents? Use a Set.
Need to identify documents by unique IDs? Use a HashMap.

If there isn’t a native data structure that fits your idea, create one that does. Just like using the right tools in construction, using the right data structures in programming makes your work cleaner, clearer, and more effective.

Bad Code:

const getWeatherForecast = (): Promise<number[]> => { ... }

Good Code:

type Result<T, E> = Ok<T> | Err<E>;

type Ok<T> = { _tag: "Ok", value: T };

type Err<E> = { _tag: "Err", error: E };

const getWeatherForecast = (): Promise<Result<WeatherForecast, HttpError>> => { ... }

Key Takeaways:

Specialized tools: Don’t rely solely on basic data structures; use ones that match your specific needs.
Clarity in code: Well-chosen data structures make your code easier to understand and maintain.
Custom solutions: If a native structure doesn’t fit, create one that does.

4. Don’t Bake a Cake with a Shovel

Imagine you’re trying to bake a cake, but instead of using the recipe’s recommended tools—a whisk, measuring cups, and a mixing bowl—you decide to use a shovel, a bucket, and a pair of chopsticks. Sure, you might get something resembling a cake in the end, but it’s going to be a messy, frustrating process, and the results won’t be nearly as good. The same idea applies to programming languages.

In TypeScript, I love how it handles type inference, dynamic unions, closures, and async functions. It’s like using the right kitchen tools for the right tasks. But try to force those same tasks into Rust, and you might end up with a complex and convoluted mess like Arc<dyn Fn(R) -> Pin<Box<dyn Future<Output = Result<T, E>> + Send>> + Send + Sync>. It’s not that Rust is bad; it’s just better suited for other tasks, like working with traits and structs.

In TypeScript, it’s important to play to the language’s strengths instead of trying to force it into something it’s not. For instance, mutability can be a nightmare to manage, leading to all sorts of bugs. Classes and enums can also be problematic, as TypeScript doesn’t always distinguish between a class and an object with the same shape, leading to frustrating issues.

So, instead of bending TypeScript to act like a different language, embrace its functional nature. Skip the classes and use types and functions. It might be a bit more verbose, but it’s cleaner and less buggy. Don’t try to shoehorn in traits with inheritance, avoid mutation-heavy methods like delete or Array.sort, and steer clear of prototypes.

Just like using the right tools in the kitchen makes baking easier and more enjoyable, using the right features in a programming language makes coding smoother and more effective.

Bad Code:

class Foo extends ToString { // Inheritance is bad
  constructor(private _data: string) {}

  get data() { // Getters might mess with Typescript
    return this._data;
  }
}

// Playing with prototypes is hacky
Foo.prototype.setData = function(str: string) {
  // `this` and mutations are a source of bugs
  this._data = str;
}

Good Code:

type Foo = {
  data: string;
}

const fromString = (str: string): Foo => ({
  data: str
});

const update = (str: string) => (self: Foo): Foo => ({
   ...self,
   data: str
});

Key Takeaways:

Embrace the language’s strengths: Don’t force it to be something it’s not.
Avoid common pitfalls: Be wary of mutability, classes, and methods that can lead to bugs.
Stick to functional programming: Use types and functions to keep your code clean and maintainable.

5. Don’t Put Ketchup on Top of the Sandwich,

Think about making a sandwich. You start with the basics: bread, meat, cheese, and some veggies. Each ingredient is its own thing, but when you stack them together, you get something more—an actual sandwich! The key here is that each layer builds on the previous one, creating a final product that’s greater than the sum of its parts. In coding, we should aim for the same approach: letting concepts naturally build on one another to create clear, testable, and scalable programs.

Let’s say you want to write a simple program that sends a friendly “Hello!” email every day. You’ll need to handle a few concepts: the message, the email address, and the email client that sends the email. By breaking these down into their own modules and building them up step by step, we can create a clean and organized program.

Here’s how you could do it:

// message.ts
type Message = string;

const create = (): Message => "Hello!";

// email.ts
type Email = string;

const create = (): Email => "friend@example.com";

// email-client.ts
type EmailClient = {
    send: (email: Email, message: Message) => Promise<void>
}

// daily-email.ts
import * as Message from './message';
import * as Email from './email';
import { EmailClient } from './email-client';

type DailyEmail = {
  email: Email;
  message: Message;
}

const create = (): DailyEmail => ({
  email: Email.create(),
  message: Message.create(),
})

const send = (self = create()) => async (emailClient: EmailClient) => emailClient.send(self.email, self.message);

In this example, each concept (message, email, email client) is defined separately and clearly, making it easy to understand and test each part. The final function, send, naturally builds on these concepts, combining them in a straightforward way to achieve the desired outcome.

By letting concepts derive from one another, you create code that’s clean, maintainable, and ready to grow—just like stacking the perfect sandwich!

Key Takeaways:

Readability: The code is easy to read and follow, like following a recipe.
Testability: Each concept is isolated, making it easy to test individual components without getting tangled up in other logic.
Scalability: New features or changes can be added without disrupting the existing structure, just like adding new ingredients to your sandwich.

6. Start with the Big Picture

Imagine you’re trying to assemble a piece of furniture. You’d expect the instructions to start with an overview: the final product image, a list of tools, and a step-by-step guide. But what if it started by explaining how to use a screwdriver, followed by a detailed description of each screw, and only at the very end showed you what you were building? That would be confusing and frustrating, right?

In coding, the same principle applies. In Clean Code, Uncle Bob states that good code should be pleasing to read. Reading it should make you smile the way a well-crafted music box or well-designed car would.

Your code should begin with the big picture—the main function—before diving into the smaller, supporting details. This way, anyone reading it can quickly grasp the purpose of the code without getting lost in the minutiae.

Here’s an example to illustrate this:

Bad Code:

// Starts with detailed helper functions
const calculateArea = (length: number, width: number): number => {
    return length * width;
};

const getDimensions = (): { length: number; width: number } => {
    return { length: 5, width: 10 };
};

const main = () => {
    const dimensions = getDimensions();
    const area = calculateArea(dimensions.length, dimensions.width);
    console.log(`The area is ${area}`);
};

Good Code:

// Starts with the big picture
const main = () => {
    const dimensions = getDimensions();
    const area = calculateArea(dimensions.length, dimensions.width);
    console.log(`The area is ${area}`);
};

const getDimensions = (): { length: number; width: number } => {
    return { length: 5, width: 10 };
};

const calculateArea = (length: number, width: number): number => {
    return length * width;
};

Key Takeaways:

Start with the big picture: Kick off with the primary function or purpose of the code to give context.
Support comes later: Place helper functions and smaller details after the main function to maintain clarity.
Focus on readability: Organize your code like a clear set of instructions, guiding the reader through the main idea before diving into the details.

Why null is an abomination

Almaju — Wed, 10 Apr 2024 17:57:24 +0000

Imagine you're halfway through your third cup of coffee, navigating through a sea of null in your codebase, and you can't help but whisper to yourself, "What in the world..." Perhaps you're even tempted to unleash a fiery comment into the void of the internet. It’s widely known that Tony Hoare, the architect behind the null reference back in 1965, has famously labeled it his "billion-dollar blunder."

Let’s dive into the intricacies of null through the lens of TypeScript, a language that you all know (and hate?).

Unraveling the Mystery of `null`

At its core, null signifies the intentional absence of a value. Its sibling, undefined, serves a similar role, denoting an uninitialized state. Here’s a simple breakdown:

undefined: A variable not yet blessed with a value.
null: A conscious decision to embrace emptiness.

Consider this example:

type User = {
  username: string,
  pictureUrl?: string,
};

type UpdateUser = {
  username?: string,
  pictureUrl?: string | null,
};

const update = (user: User, data: UpdateUser) => {
  if (data.pictureUrl === undefined) {
    // No action required
    return;
  }
  if (typeof data.pictureUrl === "string") {
    // Update in progress
    user.pictureUrl = data.pictureUrl;
  }
  if (data.pictureUrl === null) {
    // Time to say goodbye
    delete user.pictureUrl;
  }
}

This scenario is common when working with partial objects from APIs, where undefined fields imply no change, and null explicitly requests data deletion.

However, how clear is it that null means "I am going to delete something"? You better hope that you have a big warning banner in your documentation and that your client will never inadvertently send a null value by mistake (which is going to happen by the way).

It feels natural because you have "NULL" in your database but employing null in your programming language solely because it exists in formats like JSON or SQL isn’t a strong argument. After all, a direct one-to-one correspondence between data structures isn't always practical or necessary. Just think about Date.

The trouble with `null`

The introduction of null into programming languages has certainly stirred the pot, blurring the lines between absence and presence. This ambiguity, as demonstrated earlier, can lead to unintuitive code. In fact, the TypeScript team has prohibited the use of null within their internal codebase, advocating for clearer expressions of value absence.

Moreover, the assumption that null and undefined are interchangeable in JavaScript leads to bewildering behavior, as illustrated by the following examples:

console.log(undefined == null); // Curiously true
console.log(undefined === null); // Definitely false
console.log(typeof null); // Unexpectedly "object"
console.log(typeof undefined); // As expected, "undefined"
console.log(JSON.stringify(null)); // Returns "null"
console.log(JSON.stringify(undefined)); // Vanishes into thin air

Regrettably, I've written code like this more often than I'd like to admit:

function isObject(value: unknown): value is Record<string, unknown> {
  return typeof value === "object" && value !== null;
}

Furthermore, if you begin incorporating both null and undefined into your codebase, you will likely encounter patterns like the following:

const addOne = (n: number | null) => (n ? n + 1 : null);

const subtractOne = (n?: number) => (n ? n - 1 : undefined);

const calculate = () => {
  addOne(subtractOne(addOne(subtractOne(0) ?? null) ?? undefined) ?? null);
};

The undefined conundrum

Okay, so we just ban null from our codebase and only use undefined instead. Problem solved, right?

It’s easy to assume that optional properties {key?: string} are synonymous with {key: string | undefined}, but they’re distinct, and failing to recognize this can lead to headaches.

const displayName = (data: { name?: string }) =>
  console.log("name" in data ? data.name : "Missing name");

displayName({}); // Displays "Missing name"
displayName({ name: undefined }); // Displays undefined
displayName({ name: "Hello" }); // Greets you with "Hello"

Yet, in other scenarios such as JSON conversion, these distinctions often evaporate, revealing a nuanced dance between presence and absence.

console.log(JSON.stringify({})); // {}
console.log(JSON.stringify({ name: undefined })); // {}
console.log(JSON.stringify({ name: null })); // {"name": null}
console.log(JSON.stringify({ name: "Bob" })); // {"name":"Bob"}

So, sometimes there are differences, sometimes not. You just have to be careful I guess!

Another problem of undefined, is that you often end up doing useless if statements because of them. Does this ring a bell?

type User = { name?: string };

const validateUser = (user: User) => {
  if (user.name === undefined) {
    throw new Error('Missing name');
  }

  const name = getName(user);

  // ...
}

const getName = (user: User): string  => {
  // Grrrr... Why do I have to do that again?
  if (user.name === undefined) {
    throw new Error('Missing name');
  }

  // ... and we just created a potential null exception
  return user.name!;
}

Consider this scenario, which is even more problematic: a function employs undefined to represent the action of "deleting a value." Here's what it might look like:

type User = { id: string, name?: string };

const updateUser = (user: User, newId: string, newName?: string) => {
  user.id = newId;
  user.name = newName;
}

updateUser(user, "123"); // It's unclear that this call actually removes the user's name.

In this example, using undefined ambiguously to indicate the deletion of a user's name could lead to confusion and maintenance issues. The code does not clearly convey that omitting newName results in removing the user's name, which can be misleading.

A path forward

Instead of wrestling with null-ish values, consider whether they’re necessary. Utilizing unions or more descriptive data structures can streamline your approach, ensuring clarity and reducing the need for null checks.

type User = { id: string };

type NamedUser = User & { name: string };

const getName = (user: NamedUser): string => user.name;

You can also have a data structure to clearly indicate the absence of something, for example:

type User = {
  id: string;
  name: { kind: "Anonymous" } | { kind: "Named", name: string }
}

If we jump back to my first example of updating a user, here is a refactored version of it:

type UpdateUser = {
  name:
    | { kind: "Ignore" }
    | { kind: "Delete" }
    | { kind: "Update"; newValue: string };
};

This model explicitly delineates intent, paving the way for cleaner, more intuitive code.

Some languages have completely abandoned the null value to embrace optional values instead. In Rust for example, there is neither null or undefined, instead you have the Option enum.

type Option<T> = Some<T> | None;

type Some<T> = { kind: "Some", value: T };

type None = { kind: "None" };

I recommend this lib if you want to try this pattern in JS: https://swan-io.github.io/boxed/getting-started

Conclusion

Adopting refined practices for dealing with null and undefined can dramatically enhance code quality and reduce bugs. Let the evolution of languages and libraries inspire you to embrace patterns that prioritize clarity and safety. By methodically refactoring our codebases, we can make them more robust and maintainable. This doesn't imply you should entirely abandon undefined or null; rather, use them thoughtfully and deliberately, not merely because they're convenient and straightforward.

An arrow in Hexagonal Architecture's foot

Almaju — Mon, 08 Apr 2024 20:47:51 +0000

If I were to name two major factors that contribute to poor code quality, I would highlight: coupling and abstractions.

Coupling can be summarized as the degree of dependency one piece of code has on another. The less, the better. Some enthusiasts, obsessed with minimizing dependencies, even pioneered a nearly zero-coupling approach to coding: microservices. Initially, it seemed promising. However, some developers were dissatisfied with the need to duplicate code, leading them to create a /shared directory for consolidating their reused code and importing it across their microservices.

On the other hand, abstraction is the process of identifying significant elements within mundane details and transforming them into an unintelligible mess that seldom functions as intended. An example of this is new QueryBuilder(new Select(Filter.ALL), new Repository("users")). The concept here is that you can effortlessly swap out one piece of code for another later on because you abstracted it well in advance. Clever, right? Except, you've likely forgotten how it was done, so you'll probably end up redoing everything from scratch anyway.

Hexagonal (or Ports & Adapters) Architecture embodies the latter philosophy. It segregates business logic from technical logic. The idea is that business logic uses ports (placeholders) for operations, and concrete implementations are defined in adapters later on.

// My port
type FetchBalance = () => Promise<number>;

// My business logic
const canGive = (amount: number) => async (fetch: FetchBalance) => {
  const balance = await fetch();
  if (amount <= balance) return true;
  else return false;
}

// My adapter/technical logic
const fakeFetch: Fetch = () => Promise.resolve(100);

// My app
const program = canGive(10)(fakeFetch);

Nothing overly complex, right? But when is the right time to abstract? What if you're certain you'll always approach a task in a specific manner? Consider if you liberally use new Date() and someone suggests: "Perhaps we could use moment or Temporal instead." It might prompt you to think about abstracting dates. In essence, even a simple array.map(...) is technically an implementation of an iterator. In the future, there might be alternative methods, suggesting you could abstract some Iterator functionality instead of directly using .map()... Stop! Let me use the damn .map()!

You see where I am going, right? When an architecture prompts more questions than it resolves, this is when I get some itching.

There should be a better way

Thus, we aim to isolate our code to avoid spaghetti code, ensure it's testable, reusable, etc., while avoiding unnecessary abstractions. If there's a simple, standard way of doing something, that's what we should use. We want to adhere to the principle of being "Open for extension" but "Closed for modification." If a new method for .map() arises, it should be integrable in a plug-and-play fashion.

Let's try to organize our thoughts.

We aim to isolate our code to avoid spaghetti code, ensure it's testable, reusable, etc., while avoiding unnecessary abstractions. If there's a simple, standard way of doing something, that's what we should use. We want to adhere to the principle of being "Open for extension" but "Closed for modification." If a new method for .map() arises, it should be integrable in a plug-and-play fashion.

Breaking down things

Imagine a basic program: a /login endpoint that exchanges a code for an access token from a third party, then generates and returns our own access token to the user.

A straightforward initial version might look like this:

import axios from "axios";
import jwt from "jsonwebtoken";

const login = async (code: string): Promise<string> => {
  const accessToken = (await axios.post("...", { code })).data;
  return jwt.sign({ accessToken }, "");
}

For proponents of "Clean Code" / "Hexagonal Architecture," this could be alarming. The instinct might be to critique: "Why not just inject an HTTPClient and a JWTService?" Relax, I got you.

Indeed, dividing our code to reduce coupling is beneficial.

const exchangeCode = async (code: string) => (await axios.post("...", { code })).data;

const signAccessToken = (accessToken: string) => jwt.sign({ accessToken }, "");

const login = async (code: string): Promise<string> => {
  const accessToken = await exchangeCode(code);
  return signAccessToken(accessToken);
}

This approach feels more refined. It's also clearer that we have two types of functions: simple unit functions that could be swapped via a plugin, and a workflow that orchestrates these functions.

There is a really good way of representing workflows in programming: a finite state machine. We could envision our "login" function transitioning through states like "ReceivedCode" to "ReceivedAccessToken" to "ReceivedJwt".

type LoginState = 
  | { kind: "ReceivedCode", code: string }
  | { kind: "ReceivedAccessToken", accessToken: string }
  | { kind: "ReceivedJwt", jwt: string };

We then design our functions as transformers of this state.

const exchangeCode = async (state: LoginState & { kind: "ReceivedCode" }): LoginState & { "ReceivedAccessToken" } => ({
  kind: "ReceivedAccessToken",
  accessToken: (await axios.post("...", { code: state.code })).data,
});

By now, you might see the potential of this approach. Can you see where this is taking us?

We can conceptualize a program as a finite set of states and a collection of functions that evolve these states until a final outcome is reached. It's akin to an automaton where the gears interlock and propel the machine. We can interchange some gears - these intermediary functions - if needed, allowing for flexible code with minimal abstraction.

Let's wrap it up.

A new way of doing "Clean Architecture"?

type LoginState =
  | { kind: "ReceivedCode"; code: string }
  | { kind: "ReceivedAccessToken"; accessToken: string }
  | { kind: "ReceivedJwt"; jwt: string };

const exchangeCode = async (
  state: LoginState & { kind: "ReceivedCode" }
): Promise<LoginState> => ({
  kind: "ReceivedAccessToken",
  accessToken: await Promise.resolve("some-access-token"),
});

const signAccessToken = async (
  state: LoginState & { kind: "ReceivedAccessToken" }
): Promise<LoginState> => ({
  kind: "ReceivedJwt",
  jwt: await Promise.resolve("some-jwt"),
});

const handlers = { exchangeCode, signAccessToken };

const login =
  ({ exchangeCode, signAccessToken } = handlers) =>
  async (code: string) => {
    let state: LoginState = { kind: "ReceivedCode", code };

    while (state.kind !== "ReceivedJwt") {
      switch (state.kind) {
        case "ReceivedCode":
          state = await exchangeCode(state);
          break;
        case "ReceivedAccessToken":
          state = await signAccessToken(state);
          break;
      }
    }

    return state.jwt;
  };

login()("123").then(console.log);

Conclusion

This strategy might seem akin to the ports and adapters model, but there's a distinction. Although we effectively inject our handlers in a similar manner, it's better conceived as customizing the current implementation rather than reserving space for future implementation. This approach maintains the benefits of low coupling and minimal abstraction. The introduction of state management not only simplifies complex scenarios but also naturally aligns code towards business logic. Notice how it would be difficult to have raw SQL for example in the middle of a state. Also, it would be quite easy to dissociate business logic handlers vs. technical logic ones.

This is how you get flexibility while always having a functional app and not an empty shell which is so abstracted that it basically never works.

If you found this discussion engaging, I encourage feedback or comments. I'm working towards a comprehensive guide on a "no-coupling and zero-abstraction" architecture. Let me know if this has piqued your interest!

Someone finally fixed Javascript

Almaju — Mon, 08 Apr 2024 13:05:27 +0000

The JavaScript ecosystem evolves at a breakneck pace. Just as you get comfortable with a certain technique, a slew of new methodologies emerges. Some, like TypeScript, gain widespread adoption, while others, such as CoffeeScript, quietly fade away. Each innovation initially stirs excitement, but over time, the community often splits, with detractors eventually spawning their own frameworks. This endless cycle has made me increasingly wary of the latest "magic" frameworks purported to solve all problems. I've shifted from seeking tools as solutions to embracing the understanding of patterns over the constant chase for new technology.

This is why I'm pointing you towards something special for your TypeScript projects, not just another tool but a paradigm that encourages good practices: Effect.

Let's take a look at why you should take the leap.

Colored functions

Have you ever asked yourself what color is your function?

Let me summarize it for you. Imagine you have blue and red functions in your code base. The rule is simple: you can use red functions inside your blue functions but not the other way. Wouldn't that be a nightmare? Now replace blue by "async". Yep, you got function coloring in Javascript.

Wait, I could just put "async/await" everywhere and no more problems.

Yes, more problems. I won't enter the details but the way Promise work in Javascript since it's single threaded is with a stacking queue so just by adding "async" you will actually make your program really slow.

const then = Promise.prototype.then;

let n = 0;

Promise.prototype.then = function (onFulfilled, onRejected) {
  n++;
  return then.apply(this, [onFulfilled, onRejected]);
};

const fibonacci = async (a: number): Promise<number> => {
  return a <= 1 ? a : (await fibonacci(a - 1)) + (await fibonacci(a - 2));
};

await fibonacci(10);

console.log(n); // n = 55

Congratulations, you just added 55 ticks to your event loop and made your simple program way slower.

So how do we fight this coloring thing? If we want to remove colored functions, we would need to create some sort of wrapper that will use a Promise only when needed. Like "Future" or... "Effect"?

import { Effect, pipe } from "effect";

const then = Promise.prototype.then;

let n = 0;

Promise.prototype.then = function (onFulfilled, onRejected) {
  n++;
  return then.apply(this, [onFulfilled, onRejected]);
};

const fibonacci = (a: number): Effect.Effect<number> =>
  a <= 1
    ? Effect.succeed(a)
    : pipe(
        Effect.all([fibonacci(a - 1), fibonacci(a - 2)]),
        Effect.map(([a, b]) => a + b)
      );

await Effect.runPromise(fibonacci(10));

console.log(n); // n = 1

mic drop

Typesafe errors

Let's look at this function:

const divide = (a: number, b: number) => a / b;

We just introduced a problem here, we cannot divide by zero. So let's refactor the code a little bit:

const divide = (a: number, b: number) => {
  if (b === 0) throw new Error('Cannot divide by zero.');
  return a / b;
}

Looks good to you? It is not. Because it is not typesafe. Someone that will want to use your function won't have any idea that your function can throw. This might look trivial with a simple function like this one but when you have dozens of potential errors, it can become a nightmare. Other more mature languages have notions such as Either or Result to have typesafe errors. It looks like that:

type Result<T, E> = { kind: "Ok", data: T } | { kind: "Err", err: E }

With Effect, you will have that out of the box: Effect<T, E>. You won't ever have to ask yourself what kind of errors can occur during the run, you can know it directly from the function signature. It also comes with helper functions to recover from errors.

Newtypes or branded types

You know, looking back at my previous function I realize we could do better.

const divide = (a: number, b: NonZeroNumber) => ...

How do you define NonZeroNumber though? If you just do type NonZeroNumber = number it won't prevent people to call it with "0". There is a pattern for that: newtypes. And yeah, Effect supports that too:

import { Brand } from "effect"

type NonZeroNumber = number & Brand.Brand<"NonZeroNumber">

const Int = NonZeroNumber.refined<Int>(
  (n) => n !== 0, // Check if the value is a non-zero number
  (n) => Brand.error(`Expected ${n} to be a non-zero number`)
)

This way, you know your function cannot be called with any number: it expects a special type of number which exclude zero.

Dependency injection

If you want to follow the "Inversion of Control" principle, you might want to look into "Dependency Injection". This concept is really simple: a function should have access to what it needs from its own context.

// With a singleton
const read = (filename) => FileReader.read(filename);

// With dependency injection
const read = (reader: FileReader) => (filename) => reader.read(filename);

It's better to do it this way for many reasons such as uncoupling things, allowing for easy testing, having different contexts etc.

While several frameworks assist with this, Effect really crushed it by making it straightforward: put your dependencies as the third parameter of an Effect.

const read = (filename): Effect<File, Error, FileReader> => ...

Conclusion

There are many other reasons why you should consider Effect. For sure, it's not going to be easy at first, you will have to learn to code differently. But contrary to many frameworks that make you learn "their" way of doing something, Effect actually teaches you good patterns that have made their proofs in other languages. Actually, Effect is heavily inspired by ZIO from Scala which itself has been inspired by Haskell which is still today considered as one of the pinacle of good programming patterns.

Someone finally fixed Javascript

Almaju — Mon, 08 Apr 2024 13:05:27 +0000

This is why I'm pointing you towards something special for your TypeScript projects, not just another tool but a paradigm that encourages good practices: Effect.

Let's take a look at why you should take the leap.

Colored functions

Have you ever asked yourself what color is your function?

So how do we fight this coloring thing? If we want to remove colored functions, we would need to create some sort of wrapper that will use a Promise only when needed. Like "Future" or... "Effect"?

import { Effect, pipe } from "effect";

const fibonacci = (a: number): Effect.Effect<number> =>
  a <= 1
    ? Effect.succeed(a)
    : pipe(
        Effect.all([fibonacci(a - 1), fibonacci(a - 2)]),
        Effect.map(([a, b]) => a + b)
      );

await Effect.runPromise(fibonacci(10));

The key difference when using Effect instead of Promise lies in how concurrency is handled. Effect provides fibers, which are lightweight concurrency structures similar to green threads or goroutines. This feature allows us to perform long-running or asynchronous tasks without blocking the main thread, which can be initiated even within traditionally synchronous functions.

import { Effect, Console, pipe } from "effect";

const longRunningTask = pipe(
  Console.log("Start of long running task"),
  Effect.delay(1000),
  Effect.tap(Console.log("End of long running task"))
);

console.log("Start of program");
Effect.runFork(longRunningTask);
console.log("End of program");

/**
 * OUTPUT:
 * Start of program
 * End of program
 * Start of long running task
 * End of long running task
 */

While Effect does not eliminate the inherent async/sync distinctions (function coloring) in JavaScript, by using fibers to handle asynchronous operations, it allows synchronous functions to invoke asynchronous effects without becoming asynchronous themselves, thereby mitigating the "coloring" problem to a significant extent.

Typesafe errors

Let's look at this function:

const divide = (a: number, b: number) => a / b;

We just introduced a problem here, we cannot divide by zero. So let's refactor the code a little bit:

const divide = (a: number, b: number) => {
  if (b === 0) throw new Error('Cannot divide by zero.');
  return a / b;
}

type Result<T, E> = Ok<T> | Err<E>;

// With something like:
type Ok<T> = { kind: "Ok", data: T };
type Err<E> = { kind: "Err", err: E };

const divide = (a: number, b: number): Effect<number, "DivisionByZeroError"> => {
  if (b === 0) return Effect.fail("DivisionByZeroError");
  return Effect.succeed(a / b);
}

Newtypes or branded types

You know, looking back at my previous function I realize we could do better.

const divide = (a: number, b: NonZeroNumber) => ...

import { Brand } from "effect"

type NonZeroNumber = number & Brand.Brand<"NonZeroNumber">

const NonZeroNumber = Brand.refined<NonZeroNumber>(
  (n) => n !== 0, // Check if the value is a non-zero number
  (n) => Brand.error(`Expected ${n} to be a non-zero number`)
)

This way, you know your function cannot be called with any number: it expects a special type of number which exclude zero.

Dependency injection

// With a singleton
const read = (filename) => FileReader.read(filename);

// With dependency injection
const read = (reader: FileReader) => (filename) => reader.read(filename);

It's better to do it this way for many reasons such as uncoupling things, allowing for easy testing, having different contexts etc.

While several frameworks assist with this, Effect really crushed it by making it straightforward: put your dependencies as the third parameter of an Effect.

const read = (filename): Effect<File, Error, FileReader> => {
  return Effect.flatMap(FileReader, fileReader => {
    return fileReader.read(filename);
  })
}

Conclusion

How Facebook killed the internet

Almaju — Sun, 07 Apr 2024 23:05:36 +0000

Reflecting on my childhood in the '90s, my father's words resonate deeply: "Never use your real name or address on the internet." This advice was simpler to follow back then. Our online interactions were mostly confined to forums where the idea of revealing our real names would never even cross our mind. We embraced aliases, usernames, nicknames, and pseudonyms, which granted us a liberating anonymity. It was a realm where you couldn't judge someone based on their appearance, where introductions might casually mention nationality or age, but even those tidbits were optional. You could express the silliest or most profound thoughts without fear of personal judgment.

This era felt alive with a spirit of mutual assistance and self-organization; it was truly exhilarating. Even as we progressed to voice communication tools like Mumble or Teamspeak, we clung to our pseudonyms, not unlike how we interact on Discord today.

4chan stands out from those times, notorious for its raw, unfiltered discourse, yet it wasn't as politically charged as it is now. Its policy of enforced anonymity, labeling every participant as "Anonymous," fascinated me. By the way, this is the origin of the similarly named cyber-activist group.

The shift began subtly, with transactions on platforms like Amazon requiring our real names and addresses. It made sense—these were direct, tangible exchanges. But in online communities, we remained veiled.

Everything changed with the arrival of Facebook. It presented itself as a private circle, a digital reflection of your personal contact list. For the first time, I entered my real name on a website, accompanied by a genuine photo of myself—actions unimaginable on any previous online forum. It felt safe, as if this information would remain within my chosen circle. Despite some opting for slight anonymity by tweaking their names, most of us laid our identities bare.

Around 2010, the debate around internet anonymity reached its peak, with contrasting views from Mark Zuckerberg and 4chan's founder. They exchanged through the media whether real names could sanitize online interactions or whether they stifled freedom of speech. I remember feeling torn, unsure which vision I supported.

Fifteen years on, my perspective has solidified. Facebook's ascent and the fortune it generated for its creators wasn't merely due to its novelty as a social network. Its success hinged on a deception: convincing us that sharing personal information, under the illusion of privacy, was harmless. We soon realized that our supposedly private data was accessible to a far broader audience than intended. It's startling how often we stumble upon a stranger's profile, accessing intimate details after a single awkward comment. This ease of access, once reserved for our eyes only, is now a commodity for any entity with internet access.

And here we are. Now everything about identity. Internet is a place where you show your face, name, city on personal billboards.

This, I believe, is why Facebook amassed its wealth. By unlocking this simple thing. This is what allowed them to do all the rest: OAuth login, targeted ads, APIs. It convinced us that handing over our personal data was safe, an assumption that fundamentally altered the internet's landscape. Looking back, I see how this shift not only enriched Facebook but also eroded the foundational principles of internet privacy and freedom.

So, what comes next? It's not about lamenting a bygone era; rather, it's about acknowledging its existence and recognizing our choices. There's a crucial reminder here: surrendering our identity isn't a prerequisite for participation in the digital world. We must champion the right to remain anonymous, emphasizing the value of what is said over who says it. For a long time, I've harbored a desire to voice my thoughts without the weight of my name or face attached. Not out of shame, but from a belief that personal details often detract rather than add to the discourse.

This is what motivated me to write this article. This fear I had and that I wanted to share. And by extension, I want to encourage those who remember the era I speak of and those curious about it: let's advocate for a web that preserves this option. Admittedly, anonymity might complicate revenue generation, but let's not forget our influence as developers. We've been instrumental in shaping the past two decades.

It's time we do so once more.

DEV Community: Almaju

Building an iOS App with Rust Using UniFFI

Prerequisites

Step 1: Setting Up Your Rust Library

Step 2: Building the iOS binaries

Step 3: Creating the XCFramework

Set 4: Import the library in Xcode

Putting everything together

See also

The Molecular Architecture

Core Philosophy: Working Pieces of Software

Why Bother?

A Quick Comparison with Traditional Architectures

Lego-Style Organization

Example Project Structure

Example: todo-list/main.ts (Runnable Entry Point)

Testing Strategy: No (or Minimal) Mocks

Handling the Dependency Graph

Addressing Common Critiques

1. “Isn’t This Just Microservices?”

2. “What About Repos, Entities, Aggregates?”

3. “Layers Are Good for Separation of Concerns!”

4. “Won’t We End Up Duplicating Code?”

The Beauty of Killing Features

Points of Weakness (And Why We Accept Them)

Final Thoughts

6 Rules to Write Better Programs at Scale

1. Choose One Pair of Scissors

Bad Code:

Key Takeaways:

2. A Notebook Page Needs a Title

Good Code:

Key Takeaways:

3. Stop Using a Wrench as a Hammer

Bad Code:

Good Code:

Key Takeaways:

4. Don’t Bake a Cake with a Shovel

Bad Code:

Good Code:

Key Takeaways:

5. Don’t Put Ketchup on Top of the Sandwich,

Key Takeaways:

6. Start with the Big Picture

Bad Code:

Good Code:

Key Takeaways:

Why null is an abomination

Unraveling the Mystery of null

The trouble with null

The undefined conundrum

A path forward

Conclusion

An arrow in Hexagonal Architecture's foot

There should be a better way

Breaking down things

A new way of doing "Clean Architecture"?

Conclusion

Someone finally fixed Javascript

Colored functions

Typesafe errors

Newtypes or branded types

Dependency injection

Conclusion

Someone finally fixed Javascript

Colored functions

Typesafe errors

Newtypes or branded types

Dependency injection

Conclusion

How Facebook killed the internet

Example: `todo-list/main.ts` (Runnable Entry Point)

Unraveling the Mystery of `null`

The trouble with `null`