DEV Community: Russell 👨🏾‍💻

I Built the Open Source “Microsoft Edge Drop” Replacement Using Cloudflare R2 + Turso

Russell 👨🏾‍💻 — Sun, 22 Feb 2026 20:58:18 +0000

I recently built Cliff Drop, a self-hosted, cross-device text and file sharing app inspired by Microsoft Edge Drop.

But the interesting part isn’t the UI.

It’s the storage architecture.

Instead of going traditional:

❌ Monolithic server
❌ Local disk storage
❌ Single-instance SQLite

I split concerns properly.

Data => Turso (Edge-hosted SQLite)

For structured data (messages, metadata, auth):

I used Turso (libSQL).

Why?

• Edge-hosted SQLite
• Low-latency global reads
• Familiar SQL
• Zero heavy database ops
• Works perfectly with Drizzle ORM

It gives you SQLite simplicity with distributed database characteristics.

No managing Postgres clusters.
No complex replication configs.

Just SQL at the edge.

☁️ File Storage => Cloudflare R2 (S3-Compatible)

For file uploads and images:

I used Cloudflare R2.

Why R2?

• S3-compatible API
• Zero egress fees
• Object storage at scale
• Works seamlessly with Node.js
• Easy local fallback option

That means I can:

Store large file uploads
Generate thumbnails
Serve files globally
Avoid bandwidth surprises

All without vendor lock-in, since it’s S3-compatible.

⚡ Real-Time + Secure

On top of that:

• Native WebSockets for real-time sync
• Argon2id password hashing
• HTTP-only cookies
• CSRF protection
• CSP headers
• Secure file handling

Built with:

SvelteKit (adapter-node)
Tailwind CSS
Node.js
Drizzle ORM
Turso
Cloudflare R2

Why This Architecture Matters

This isn’t just a side project.

It demonstrates:

• Cloud-native storage design
• Separation of structured vs object storage
• Distributed edge database usage
• S3-compatible infrastructure
• Full-stack + DevOps ownership
• Production-ready Linux deployment (systemd / PM2 / Nginx)

Modern full-stack engineering isn’t just React + API.

It’s choosing the right storage layer for the right responsibility.

Database for data integrity.
Object storage for files.
Edge for performance.
Node for control.

Cliff Drop is small - but architected like a real system.

If you’re building side projects, stop defaulting to “everything in one server.”

Split storage properly.
Think about latency.
Think about scale.
Think about cost.

That’s how you level up.

Github Repo: https://github.com/RussellJapheth/cliff-drop

Did you know you can change how SvelteKit bundles your entire app?

Russell 👨🏾‍💻 — Fri, 13 Feb 2026 13:15:58 +0000

When using adapter-static, most people focus on prerendering and deployment targets. But there is another lever that quietly affects performance and portability: output.bundleStrategy.

By default, SvelteKit splits your app into multiple chunks for better caching and lazy loading. That is usually what you want.

But if you are building:
• A fully static site
• An embeddable widget
• A portable demo
• A microfrontend
• Something that needs to work cleanly from simple static hosting

You can switch strategies.
For example:
split → multiple JS/CSS files, better caching
single → one JS file and one CSS file
inline → everything injected directly into the HTML

With adapter-static, this can make your build output dramatically simpler, depending on your use case.
Sometimes performance and portability decisions start in your config file, not your components.

import adapter from '@sveltejs/adapter-static';

export default {
  kit: {
    adapter: adapter(),
    output: {
      bundleStrategy: 'single'
    }
  }
};

Before You Reach for State, Try element.dataset

Russell 👨🏾‍💻 — Wed, 11 Feb 2026 17:21:56 +0000

There is a small JavaScript feature that quietly solves a surprising number of frontend problems, yet it rarely gets discussed:

element.dataset

Most developers reach for IDs, classes, or extra state before remembering that the platform already provides a structured way to attach metadata directly to DOM elements.

That is where data-* attributes and dataset come in.

What Is `dataset`?

Whenever you define a custom data-* attribute in HTML, JavaScript automatically exposes it through the dataset property of that element.

Instead of parsing attributes manually, you get a clean object interface.

For example:

<button 
  class="btn primary"
  data-user-id="42"
  data-role="admin"
>
  View
</button>

<script>
  const button = document.querySelector('button');

  button.addEventListener('click', (event) => {
    const { userId, role } = event.currentTarget.dataset;

    console.log(userId); // "42"
    console.log(role);   // "admin"
  });
</script>

Notice the transformation:

data-user-id → dataset.userId
data-role → dataset.role

Hyphenated attribute names automatically convert to camelCase.

No string parsing. No extra selectors. No brittle logic.

Why This Matters in Real Projects

This is not just syntactic sugar. It is a practical pattern that keeps logic close to the element it belongs to.

Here are a few places where dataset shines:

1. Event Delegation

When handling clicks on dynamic lists, you often need context about the clicked element.

Instead of maintaining separate lookup maps or encoding values in IDs, you can attach structured data directly to the element.

<ul id="users">
  <li data-user-id="101">Alice</li>
  <li data-user-id="102">Bob</li>
</ul>

<script>
  document.getElementById('users').addEventListener('click', (event) => {
    const userId = event.target.dataset.userId;
    if (!userId) return;

    console.log('Selected user:', userId);
  });
</script>

Clean. Scalable. Minimal state.

2. Lightweight UI State

For small interactive components, not everything needs a global store or reactive system.

<div data-expanded="false"></div>

element.dataset.expanded = "true";

It is explicit and easy to inspect in DevTools.

3. Avoiding Over-Engineering

Modern frontend ecosystems encourage abstraction. Sometimes that is necessary. Often, it is not.

Using dataset can eliminate:

Extra wrapper objects
Redundant DOM queries
Temporary state variables
Overcomplicated component logic

Sometimes the simplest solution is already built into the platform.

A Few Things to Keep in Mind

All dataset values are strings. Convert them if you need numbers or booleans.
It is best suited for UI-related metadata, not large or sensitive data.
Keep naming consistent and predictable.

Final Thought

Good frontend engineering is not just about frameworks. It is about understanding the underlying platform well enough to use it intentionally.

dataset is one of those small features that, when used properly, makes your code cleaner, clearer, and easier to maintain.

Sometimes the most underrated tools are the ones that have been there all along.

What I Learned Building a Minimalist Time Tracker with Svelte and Copilot

Russell 👨🏾‍💻 — Mon, 09 Feb 2026 14:11:01 +0000

This past weekend, I shipped a small but complete time-tracking and productivity application.

The goal was straightforward: build a minimalist focus timer with structured work and rest cycles, light presets, and a simple todo list, designed to reduce cognitive load and avoid feature bloat.
From a technical standpoint, the project was built with Svelte, using modern frontend engineering best practices, clean component architecture, and a strong emphasis on performance and maintainability. I also integrated AI-assisted development into the workflow to accelerate ideation, iteration, and refactoring while keeping full control over system design and code quality.

Why share this publicly?
In the current climate, there is a lot of discussion around AI in software development. I think it is important to demonstrate practical, real-world usage where AI augments productivity without compromising engineering discipline, code ownership, or long-term maintainability.

This repository is public and documents:

· Frontend development with Svelte
· AI-assisted software engineering workflows
· UI/UX design for focus and productivity tools
· Component-based architecture and clean state management
· Rapid prototyping to production-ready code

GitHub repository: https://lnkd.in/dpqdT7Gj

Always happy to connect with engineers interested in development, product engineering, AI-augmented workflows, and building thoughtful, user-centric software.

Understanding Cron: Automating Tasks in Linux

Russell 👨🏾‍💻 — Tue, 21 Jan 2025 22:58:02 +0000

Cron is a time-based job scheduling utility in Unix-like operating systems, including Linux and macOS. It allows users to automate repetitive tasks by running scripts or commands at specified intervals. Cron is widely used for system maintenance, backups, monitoring, and automating various tasks.

How Cron Works

Cron runs as a background process and reads job schedules from a file called the crontab (short for "cron table"). Each user on a system can have their own crontab, defining tasks to be executed at specific times.

Cron Daemon

The cron daemon (crond) is responsible for executing scheduled tasks. It runs continuously in the background, checking the crontab files every minute to determine if any tasks need to be executed.

Cron Syntax

Cron job entries follow a specific syntax consisting of five time fields followed by the command to execute:

* * * * * command-to-be-executed
| | | | |
| | | | +---- Day of the week (0 - 6) [Sunday=0]
| | | +------ Month (1 - 12)
| | +-------- Day of the month (1 - 31)
| +---------- Hour (0 - 23)
+------------ Minute (0 - 59)

Examples of Cron Jobs

Run a script every day at 2:30 AM:

   30 2 * * * /path/to/script.sh

Run a script every Monday at 9 AM:

   0 9 * * 1 /path/to/script.sh

Run a task every 5 minutes:

   */5 * * * * /path/to/command

Run a backup at midnight on the 1st of every month:

   0 0 1 * * /path/to/backup.sh

Managing Cron Jobs

Viewing Cron Jobs

To list the cron jobs for the current user, run:

crontab -l

Editing Cron Jobs

To add or modify cron jobs, use:

crontab -e

This will open the user's crontab file in the default text editor.

Removing Cron Jobs

To delete all cron jobs for the current user:

crontab -r

Special Strings in Cron

Cron also supports special keywords to simplify scheduling:

@reboot – Run once at system startup
@yearly – Equivalent to 0 0 1 1 *
@monthly – Equivalent to 0 0 1 * *
@weekly – Equivalent to 0 0 * * 0
@daily – Equivalent to 0 0 * * *
@hourly – Equivalent to 0 * * * *

Example:

@daily /path/to/daily_task.sh

Logging and Troubleshooting

Cron logs can be found in the system log files. On most Linux systems, check:

cat /var/log/syslog | grep cron

If a cron job is not running, ensure:

The script has executable permissions.
The full path to the script or command is specified.
Environment variables are correctly set.

Common Use Cases

Cron is commonly used for:

Automating backups
Sending periodic reports
Cleaning temporary files
Syncing data with remote servers

Additional Resources

For an easy way to generate and understand cron expressions, visit crontab.guru.

Conclusion

Cron is a powerful tool for task automation in Unix-based systems. Mastering cron allows system administrators and developers to streamline operations and ensure tasks are executed efficiently without manual intervention.

An Introduction to PHP and SQLite

Russell 👨🏾‍💻 — Mon, 20 Jan 2025 22:21:29 +0000

Introduction

PHP and SQLite are a powerful combination for lightweight web applications and projects that require an embedded database solution. PHP is a popular server-side scripting language, while SQLite is a self-contained, serverless database engine. Together, they provide a simple yet effective way to build data-driven applications without the overhead of a traditional database server.

Understanding PHP

PHP (Hypertext Preprocessor) is an open-source scripting language designed for web development. It allows developers to create dynamic and interactive web pages by embedding code within HTML. Some key features of PHP include:

Easy integration with various databases
Cross-platform compatibility
Extensive community support
Built-in functions for handling forms, cookies, and sessions

Installation and Setup

To get started with PHP:

Download and install PHP from the official website.
Configure the php.ini file for necessary settings.
Run PHP scripts using the built-in server or via a web server like Apache.

Understanding SQLite

SQLite is a lightweight, serverless database management system stored in a single file on disk. It is widely used for small to medium-sized applications, mobile applications, and embedded systems.

Key features of SQLite include:

Self-contained and zero-configuration
High-speed performance for small-scale applications
ACID-compliant transactions
Cross-platform support

Advantages of SQLite

No need for a separate database server
Simple setup and portability
Low memory and disk space requirements

Setting Up PHP and SQLite

Ensure PHP is installed on your system.
Verify that SQLite is enabled by checking the PHP configuration:

   phpinfo();

Use the following command to confirm SQLite support:

   echo extension_loaded('sqlite3') ? 'SQLite enabled' : 'SQLite not enabled';

Working with SQLite in PHP

To interact with SQLite databases in PHP, the SQLite3 extension or PHP Data Objects (PDO) can be used.

Connecting to SQLite

$db = new SQLite3('database.db');
if ($db) {
    echo "Connected successfully";
} else {
    echo "Connection failed";
}

Creating a Database Table

$db->exec("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, email TEXT)");

Inserting Data

$db->exec("INSERT INTO users (name, email) VALUES ('John Doe', 'john@example.com')");

Querying Data

$result = $db->query("SELECT * FROM users");
while ($row = $result->fetchArray()) {
    echo "User: " . $row['name'] . " - Email: " . $row['email'];
}

Using PHP PDO with SQLite

PDO offers a more flexible and secure way to interact with SQLite databases.

Establishing a Connection

try {
    $pdo = new PDO('sqlite:database.db');
    $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    echo "Connected successfully";
} catch (PDOException $e) {
    echo "Connection failed: " . $e->getMessage();
}

Executing Queries

$stmt = $pdo->prepare("INSERT INTO users (name, email) VALUES (:name, :email)");
$stmt->execute(['name' => 'Jane Doe', 'email' => 'jane@example.com']);

Building a Simple CRUD Application

Setup the Project Structure: Organize files into index.php, db.php, and functions.php.
Create a Database Schema: Define tables and relationships.
Implement CRUD Operations: Use PHP to insert, retrieve, update, and delete records.
Display Data: Render results in HTML tables.

Best Practices for PHP and SQLite

Security: Use prepared statements to prevent SQL injection.
Performance: Optimize queries and indexes.
Backup: Regularly backup the SQLite database file.

Common Issues and Troubleshooting

Ensure correct file permissions for the database.
Handle concurrency issues with proper locking mechanisms.
Use error handling to debug connection failures.

Conclusion

PHP and SQLite provide an excellent foundation for lightweight web applications and embedded solutions. With their ease of use and flexibility, they are a great choice for developers looking to build scalable yet simple applications.

Systemd vs. Docker: Exploring a Surprising Alternative

Russell 👨🏾‍💻 — Mon, 09 Dec 2024 22:04:04 +0000

What is Docker?

Docker is a platform that allows you to build, run, and manage containers. Containers are like lightweight virtual machines, but they don't emulate the entire operating system. Instead, they provide a sandboxed environment that mimics a virtual machine, allowing you to isolate and run applications with their dependencies in a consistent environment, regardless of the underlying host system.

What is Systemd?

Systemd is an init system and a process manager for Linux. It’s responsible for bootstrapping the user space and managing system processes, including services that run in the background. Systemd can be used to start, stop, and manage processes and services, and it integrates deeply with the operating system.

Why This Article?

At first glance, Docker and Systemd may seem like two very different tools, but both are used to manage the execution of applications. Docker is often used to run applications in isolated containers, while Systemd is traditionally used to manage services that run directly on the host operating system. In this article, we’ll compare these two approaches by setting up Pocketbase, a lightweight backend server, in both environments: one using Docker and the other using Systemd to run it as a regular process.

We'll explore the differences in setup, management, and performance of both approaches and discuss when you might prefer one over the other.

Prerequisites:

Before we begin, make sure you have the following:

A Linux-based system (Ubuntu, CentOS, Debian, etc.).
Docker installed, if you want to run the application in a container.
Basic knowledge of the command line.
The Pocketbase binary. Find the right one for your machine here.

Running Pocketbase in Docker

First, let's look at how to run Pocketbase using Docker. Docker makes it simple to get Pocketbase up and running quickly by encapsulating the application and all its dependencies within a container. Here’s how you would run Pocketbase in Docker:

docker run -d -p 8090:8090 -v ~/pocketbase_data:/pocketbase pocketbase/pocketbase

Explanation:

-d: Runs the container in detached mode.
-p 8090:8090: Maps port 8090 on the host to port 8090 in the container.
-v ~/pocketbase_data:/pocketbase: Mounts the local directory ~/pocketbase_data to /pocketbase inside the container to persist data.
pocketbase/pocketbase: Specifies the Pocketbase image to run.

With Docker, you get a clean, isolated environment, and managing the application is as simple as running or stopping the container. Docker also ensures that your Pocketbase instance runs in a consistent environment, regardless of what system it’s on.

Running Pocketbase with Systemd

Now, let’s look at how we can run Pocketbase as a regular process using Systemd. With Systemd, you will be directly managing the Pocketbase process, and it will be tied to the underlying system, rather than running in a container. Here’s how to do it:

Create a Systemd Service File

sudo nano /etc/systemd/system/pocketbase.service

Add the following content to the file:

[Unit]
Description=Pocketbase Application
After=network.target

[Service]
ExecStart=/usr/local/bin/pocketbase serve --http=0.0.0.0:8090
WorkingDirectory=/home/yourusername/pocketbase
Restart=always
User=yourusername
Group=yourgroup

[Install]
WantedBy=multi-user.target

Reload Systemd and Start the Service:

sudo systemctl daemon-reload
sudo systemctl start pocketbase
sudo systemctl enable pocketbase

Explanation:

ExecStart: Specifies the command to run Pocketbase.
WorkingDirectory: Sets the directory where Pocketbase will run (you can adjust this to your Pocketbase installation path).
Restart=always: Ensures that the process is restarted if it crashes.
User and Group: Specifies the user and group that should run the process.

With Systemd, you manage the Pocketbase process like any other system service. You can control it using standard Systemd commands like start, stop, restart, and status.

Comparison: Docker vs. Systemd

Ease of Setup:
- Docker offers a more streamlined setup with fewer dependencies since it isolates the application within a container. It’s a great choice if you need a quick, portable solution that works across different environments.
- Systemd requires setting up a service file, managing dependencies, and ensuring the application runs directly on the system. It's a more manual process but offers deeper integration with the host OS.
Isolation:
- Docker provides full isolation for the application, meaning it runs in a self-contained environment. This is especially useful when you want to avoid conflicts with other applications or dependencies on your system.
- Systemd runs the application directly on the system, which can lead to potential conflicts with other system services if not properly managed, but it allows for better integration with the system’s process management.
Management and Monitoring:
- Docker simplifies management by encapsulating all the application dependencies within the container. You can easily stop, restart, or scale the application by interacting with the Docker container.
- Systemd gives you more control over how the process interacts with the system. You can manage logging, resource allocation, and service dependencies more granularly with Systemd.
Performance:
- Docker adds a small overhead due to containerization, though the performance difference is usually negligible for most applications.
- Systemd typically offers better performance for long-running processes since there’s no container overhead, and it runs natively on the host system.

Conclusion

In this article, we’ve explored two different methods for running Pocketbase: inside a Docker container and as a regular process managed by Systemd. Docker is ideal for creating isolated environments and easily managing dependencies, while Systemd gives you more control and deeper integration with the host system.

Which method you choose depends on your needs. If portability and isolation are key, Docker might be the better choice. If you prefer direct integration with the operating system and need more control over service management, Systemd is a great option. Both approaches have their strengths, and understanding them can help you make the right decision for your application deployment.

Building CLI Tools with Go (Golang): A JSON File Formatter

Russell 👨🏾‍💻 — Wed, 20 Mar 2024 10:36:14 +0000

Introduction

Go is a simple language, it supports concurrency out of the box and compiles to executable files so users do not need to have Go installed to run our apps, this makes Go ideally suited for building CLI tools. In this article, we will be going over how to build a CLI utility to format JSON files in Go.

Prerequisites

A working Go installation. You can find instructions here to set up Go if you do not.
A code editor (VsCode is a popular choice).
This article assumes you have basic knowledge of programming concepts and the CLI.

Getting ready

To confirm you have Go installed and ready to use run

go version

You should get a response like

go version go1.22.1 linux/amd64

If you did not, please follow the instructions here to install Go.

With that out of the way here is the flow of our tool:

// 1. Get the path for our input file from 
//    the command line arguments
// 2. Check if the input file is readable and contains 
//    valid JSON
// 3. Format the contents of the file
// 4. Save formatted JSON to another file
// 5. Compile our binary

Step 0:

In a folder of your choosing, create a main.go file using your code editor. Here are the contents of the file:

// 1. Get the path for our input file from 
//    the command line arguments
// 2. Check if the input file is readable and contains 
//    valid JSON
// 3. Format the contents of the file
// 4. Save formatted JSON to another file
// 5. Compile our binary

package main

import "fmt"

func main() {
    fmt.Println("Hello, 你好")
}

To execute the following code in your CLI run

go run main.go

Which would give us the output

Hello, 你好

Step 1:

First, we check that we have at least 1 argument passed to our program; the input file. To do this we would need to import the OS module

import (
    "fmt"
    "os"
)

We check that at least 1 argument was passed and display an error otherwise:

// Get the arguments passed to our program
arguments := os.Args[1:]

// Check that at least 1 argument was passed
if len(arguments) < 1 {
    // Display error message and exit the program
    fmt.Println("Missing required arguments")
    fmt.Println("Usage: go run main.go input_file.json")
    return
}

Step 2

Next, we confirm that our input file is readable and contains valid JSON

// We add the encoding/json, errors and bytes module
import (
    "bytes"
    "encoding/json"
    "errors"
    ...
)

// A function to check if a string is valid JSON
// src: https://stackoverflow.com/a/22129435
func isJSON(s string) bool {
    var js map[string]interface{}
    return json.Unmarshal([]byte(s), &js) == nil
}

// We define a function to check if the file exists
func FileExists(name string) (bool, error) {
    _, err := os.Stat(name)
    if err == nil {
        return true, nil
    }
    if errors.Is(err, os.ErrNotExist) {
        return false, nil
    }
    return false, err
}

// A function to pretty print JSON strings
// src: https://stackoverflow.com/a/36544455 (modified)
func jsonPrettyPrint(in string) string {
    var out bytes.Buffer
    err := json.Indent(&out, []byte(in), "", "    ")
    if err != nil {
        return in
    }
    return out.String()
}


// In our main function, we check if the file exists
func main() {
....
    // Call FileExists function with the file path
    exists, err := FileExists(arguments[0])

    // Check the result
    if exists != true {
        fmt.Println("Sorry the file", arguments[0], "does not exist!")
    return
    }
    if err != nil {
        fmt.Println("Error:", err)
        return
    }

    raw, err := os.ReadFile(arguments[0]) // just pass the file name
    if err != nil {
        fmt.Print(err)
    }

    // convert the files contents to string
    contents := string(raw)

    // check if the string is valid json
    if contents == "" || isJSON(contents) != true {
        fmt.Println("Invalid or empty JSON file")
        return
    }
}

Step 3

We format the contents of the file and display it

    // print the formatted string; this output can be piped to an output file
    // no prefix and indenting with 4 spaces
    formatted := jsonPrettyPrint(contents)

    // Display the formatted string
    fmt.Println(formatted)

Step 4

Save formatted JSON to another file, and to do that we pipe the output to a file

go run main.go input.json > out.json

The angle brackets > redirects the output of our program to a file out.json

Step 5

Compile our code to a single binary. To do this we run

# Build our code
go build main.go

# list the contents of the current directory
# we would have an executable binary called "main"
ls
# main main.go

#We will rename our executable prettyJson
mv main prettyJson

We can run our new binary as we would any other executable

Let's update our usage instructions

// fmt.Println("Usage: go run main.go input_file.json")
// becomes
fmt.Println("Usage: ./prettyJson input_file.json")

Here is the completed code

// 1. Get the path for our input file from
//    the command line arguments
// 2. Check if the input file is readable and contains
//    valid JSON
// 3. Format the contents of the file
// 4. Save formatted JSON to another file
// 5. Compile our binary

package main

import (
    "bytes"
    "encoding/json"
    "errors"
    "fmt"
    "os"
)

// A function to check if a string is valid JSON
// src: https://stackoverflow.com/a/22129435 (modified)
func isJSON(s string) bool {
    var js map[string]interface{}
    return json.Unmarshal([]byte(s), &js) == nil

}

func FileExists(name string) (bool, error) {
    _, err := os.Stat(name)
    if err == nil {
        return true, nil
    }
    if errors.Is(err, os.ErrNotExist) {
        return false, nil
    }
    return false, err
}

// A function to pretty print JSON strings
// src: https://stackoverflow.com/a/36544455
func jsonPrettyPrint(in string) string {
    var out bytes.Buffer
    err := json.Indent(&out, []byte(in), "", "\t")
    if err != nil {
        return in
    }
    return out.String()
}

func main() {
    // Get the arguments passed to our program
    arguments := os.Args[1:]

    // Check that at least 1 argument was passed
    if len(arguments) < 1 {
        // Display error message and exit the program
        fmt.Println("Missing required argument")
        fmt.Println("Usage: ./prettyJson input_file.json")
        return
    }

    // Call FileExists function with the file path
    exists, err := FileExists(arguments[0])

    // Check the result
    if exists != true {
        fmt.Println("Sorry the file", arguments[0], "does not exist!")
        return
    }
    if err != nil {
        fmt.Println("Error:", err)
        return
    }

    raw, err := os.ReadFile(arguments[0]) // just pass the file name
    if err != nil {
        fmt.Print(err)
    }

    // convert the files contents to string
    contents := string(raw)

    // check if the string is valid json
    if contents == "" || isJSON(contents) != true {
        fmt.Println("Invalid or empty JSON file")
        return
    }

    // print the formatted string; this output can be piped to an output file
    // no prefix and indenting with 4 spaces
    formatted := jsonPrettyPrint(contents)

    // Display the formatted string
    fmt.Println(formatted)
}

Conclusion

We have seen how to create a JSON formatter utility with Go. The code is available as a GitHub gist here. Feel free to make improvements.

Configuring Wildcard Subdomains: A Comparison of Nginx and Caddy

Russell 👨🏾‍💻 — Fri, 23 Feb 2024 15:25:39 +0000

Introduction

Wildcard subdomains allow you to dynamically handle multiple subdomains under a parent domain without explicitly defining the configuration for each subdomain.

A common use case for wildcard subdomains is in multitenant applications where each customer accesses the application from their unique domain. Manually configuring each subdomain is impractical in this scenario.

In this article, we will look at configuring wildcard subdomains on Nginx and Caddy and compare both options.

Requirements

The article assumes you have Nginx and Caddy installed

Nginx Configuration

To get started, we'll create a new config file. You need root access to update the configuration so we will prefix the command with sudo



sudo nano /etc/nginx/sites-available/app.com

Add the following configuration to the file



server {

    server_name *.app.com;

    location / {
        proxy_pass http://127.0.0.1:8090;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

This configuration proxies all requests to a service running on port 8090. The key bit is server_name *.app.com;, this tells nginx to handle all requests made to *.app.com (customer1.app.com, customer2.app.com ...).

Caddy Configuration

Just like Nginx, we'll begin by editing the main configuration file and prefixing the call with sudo since it requires root access:



sudo nano /etc/caddy/Caddyfile

And the contents:



*.app.com {

    request_body {

        max_size 10MB

    }

    reverse_proxy 127.0.0.1:8090 {

        transport http {

            read_timeout 360s

        }

    }

}

Comparison and Conclusion

Both Nginx and Caddy have similar configuration patterns they both have distinct approaches so the syntax differs greatly. They however both provide nearly the same levels of flexibility and functionality with Caddy being more akin to JSON and supporting it natively.

Deploying Pocketbase with Docker, Nginx and SSL

Russell 👨🏾‍💻 — Thu, 15 Feb 2024 14:28:25 +0000

Introduction

What is Pocketbase? Pocketbase is an open-source backend solution offering a real-time database, file storage, and seamless user authentication with OAuth integration, all readily available right out of the box.

In this post, we’ll cover how to deploy Pocketbase using Docker and Nginx on an Ubuntu machine (although the instructions would also work for any Debian-based Linux distribution). Additionally, we will cover provisioning an SSL certificate using Certbot for enhanced security.

Prerequisites

Before we begin, ensure that you have the following:

An Ubuntu machine or server (these instructions apply to other Debian-based Linux distributions as well).
Docker installed on your system.
Basic knowledge of Docker and command-line usage.
Nginx installed on your system with certbot

Here are articles on installing docker, nginx and certbot.

Installing PocketBase With Docker

We'll use a slightly modified version of the docker-compose.yml from the muchobien/pocketbase-docker repository.

Step 1. Create a docker-compose.yml file in a directory of your choice. The contents of the file are provided below:

version: "3.7"
services:
  pocketbase:
    image: ghcr.io/muchobien/pocketbase:latest
    container_name: pocketbase
    restart: unless-stopped
    command:
      - --encryptionEnv 
      - ENCRYPTION 
    environment:
      ENCRYPTION: YOUR_ENCRYPTION_KEY 
    ports:
      - "8091:8090"
    volumes:
      - ./pb_data:/pb_data
      - ./pb_public:/pb_public 
      - ./pb_migrations:/pb_migrations 
    healthcheck: 
      test: wget --no-verbose --tries=1 --spider http://localhost:8090/api/health || exit 1
      interval: 5s
      timeout: 5s
      retries: 5

Step 2. To start the docker container we run the following command in the terminal:

$ docker compose up -d --build

This starts a pocketbase instance and exposes it on port 8091. The pb_data, pb_public, and pb_migrations folders created are bound to the folder in the container.

Step 3. Next, we create an Nginx instance to give access to our application. To keep things simple, we will work with the default configuration file. Run the command below:

$ nano /etc/nginx/sites-available/default

Add the following code to the end of the file and save, replacing app.example.com with your domain name or the subdomain you want to create:

server {
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:8091;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

}

Next, test that your Nginx configuration is valid:

$ sudo nginx -t

You should get a message like the one below if everything is fine:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Then restart Nginx:

$ sudo systemctl restart nginx

Finally, we generate our SSL certificates using certbot:

$ sudo certbot --nginx -d app.example.com

Congrats, you have now set up PocketBase secured with SSL. The following are the routes:

https://app.example.com - Serves the static content (html, css, images, etc.) from the pb_public directory.
https://app.example.com/_/ - The admin dashboard UI
https://app.example.com/api/ - The REST API

Conclusion

Following this tutorial, you now have deployed PocketBase successfully.

DEV Community: Russell 👨🏾‍💻

I Built the Open Source “Microsoft Edge Drop” Replacement Using Cloudflare R2 + Turso

Data => Turso (Edge-hosted SQLite)

☁️ File Storage => Cloudflare R2 (S3-Compatible)

⚡ Real-Time + Secure

Why This Architecture Matters

Did you know you can change how SvelteKit bundles your entire app?

Before You Reach for State, Try element.dataset

What Is dataset?

Why This Matters in Real Projects

1. Event Delegation

2. Lightweight UI State

3. Avoiding Over-Engineering

A Few Things to Keep in Mind

Final Thought

What I Learned Building a Minimalist Time Tracker with Svelte and Copilot

Understanding Cron: Automating Tasks in Linux

How Cron Works

Cron Daemon

Cron Syntax

Examples of Cron Jobs

Managing Cron Jobs

Viewing Cron Jobs

Editing Cron Jobs

Removing Cron Jobs

Special Strings in Cron

Logging and Troubleshooting

Common Use Cases

Additional Resources

Conclusion

An Introduction to PHP and SQLite

Introduction

Understanding PHP

Installation and Setup

Understanding SQLite

Advantages of SQLite

Setting Up PHP and SQLite

Working with SQLite in PHP

Connecting to SQLite

Creating a Database Table

Inserting Data

Querying Data

Using PHP PDO with SQLite

Establishing a Connection

Executing Queries

Building a Simple CRUD Application

Best Practices for PHP and SQLite

Common Issues and Troubleshooting

Conclusion

Further Reading

Systemd vs. Docker: Exploring a Surprising Alternative

Running Pocketbase in Docker

Running Pocketbase with Systemd

Comparison: Docker vs. Systemd

Conclusion

Building CLI Tools with Go (Golang): A JSON File Formatter

Introduction

Prerequisites

Getting ready

Step 0:

Step 1:

Step 2

Step 3

Step 4

Step 5

Conclusion

Configuring Wildcard Subdomains: A Comparison of Nginx and Caddy

Introduction

Requirements

Nginx Configuration

Caddy Configuration

Comparison and Conclusion

Deploying Pocketbase with Docker, Nginx and SSL

Introduction

Prerequisites

Installing PocketBase With Docker

Conclusion

What Is `dataset`?