So, here I was deciding what to pick for my Golang app deployment.

Building an app to deploy wasn’t the problem, setting up the instance WAS the problem, because I had forgotten a lot, thankfully — AWS looked the same since I last deployed anything.

One of the fundamental parts of an application deployment is the reverse-proxy server. Ideally, these are the steps to get your application deployed:

• Write some (runnable) code
• Get a VPS provider (for a server)
• Setup a CI process to build and run your code on the server
• Redirect traffic from a specific URL to your app

Step 1 — Write some (runnable) code

Over here, the amazing “Hello worlds” will wave at us and tell us there’s nothing wrong with that, but I want us to set up a simple API Gateway in code. What’s an API Gateway you may ask? Well, it’s an API that forwards requests to other APIs.

// File: cmd/api-gateway/main.go
package main

import (
 "context"
 "fmt"
 "log"
 "net/http"
 "os"
 "os/signal"
 "syscall"
 "time"
)

func main() {
 // Load configuration
 cfg, err := config.Load()
 if err != nil {
  log.Fatalf("Failed to load configuration: %v", err)
 }

 // Initialize gRPC clients
 grpcClients, err := clients.NewGRPCClients(cfg)
 if err != nil {
  log.Fatalf("Failed to initialize gRPC clients: %v", err)
 }
 defer grpcClients.Close()

 // Initialize gateway
 gw := gateway.New(grpcClients)

 // Setup router
 router := router.NewGatewayRouter(gw).SetupRouter()

 // Start server
 srv := &http.Server{
  Addr:         fmt.Sprintf(":%d", cfg.Port),
  Handler:      router,
  ReadTimeout:  cfg.ReadTimeout,
  WriteTimeout: cfg.WriteTimeout,
  IdleTimeout:  cfg.IdleTimeout,
 }

 // Start server in a goroutine
 go func() {
  log.Printf("Starting API Gateway on port %d (Instance: %s)", cfg.Port, cfg.InstanceID)
  if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
   log.Fatal("Failed to start server:", err)
  }
 }()

 // Wait for interrupt signal
 quit := make(chan os.Signal, 1)
 signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
 <-quit

 log.Println("Shutting down server...")
 ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
 defer cancel()

 if err := srv.Shutdown(ctx); err != nil {
  log.Fatalf("Server forced to shutdown: %v", err)
 }

 log.Println("Server exited")
}

Hey! What are you doing? Just copying some code off the internet hoping it works?? Well, that’s too lazy, don’t keep doing that, you’d not really learn the hard things.

I skipped a lot of parts in the code though — the config settings, the GRPC class, heck I even skipped the router part! Unfortunately, if you can’t write runnable Golang server code without AI help in 2025, you need to jump back into that bootcamp you ran away from.

Although, if you’re here to pick up some Golang skills, sorry about this joke — I will edit this part to point to a crash course in future.

Step 2 — Get a VPS Provider (for a server)

Choose who you prefer to get frustrated by for the next couple of months:

• Amazon?
• DigitalOcean?
• Google?

I chose Amazon’s Web Service, why not? I like to live dangerously.

AWS’s t3.micro EC2 instance works well for me, I don’t need large storage too, so perfect!

Step 3 — Setup a CI process to build and run your code on the server

Now, you might be thinking — “What did I do to deserve this kind of LONG article?” — The simple answer, you’re CHOSEN, that’s all.

Setting up a CI Process is required! I think you should be lazy enough to do this part, stay with me now.

So, for AWS, all you need is your .pem file for connecting to your instance and the IP address of your instance for SSH connectivity.

Secondly, I like to set up a workflow that does much — with workflow dispatch that can be copied to anywhere:

name: Deploy API Gateway

on:
  push:
    branches: [ "main", "dev" ]
  pull_request:
    branches: [ "main" ]
  workflow_dispatch:
    inputs:
      action:
        description: 'Action to perform'
        required: true
        default: 'deploy'
        type: choice
        options:
          - deploy
          - start
          - stop
          - restart
          - status
          - logs
          - setup-service

env:
  GO_VERSION: "1.23.4"
  SERVICE_NAME: "api-gateway"
  DEPLOY_PATH: "/usr/local/bin"
  BINARY_NAME: "api"

jobs:
  # Test stage
  test:
    runs-on: ubuntu-latest
    if: github.event_name != 'workflow_dispatch' || github.event.inputs.action == 'deploy'
    steps:
      - uses: actions/checkout@v4
      
      - name: Set up Go
        uses: actions/setup-go@v5
        with:
          go-version: ${{ env.GO_VERSION }}
          cache: true
      
      - name: Create environment file
        run: echo "${{ secrets.ENV }}" > .env
        
      - name: Run tests
        run: go test -v ./...
        
      - name: Run code analysis
        run: go vet ./...

  # Build stage
  build:
    needs: test
    runs-on: ubuntu-latest
    if: github.event_name != 'workflow_dispatch' || github.event.inputs.action == 'deploy'
    steps:
      - uses: actions/checkout@v4
      
      - name: Set up Go
        uses: actions/setup-go@v5
        with:
          go-version: ${{ env.GO_VERSION }}
          cache: true
      
      - name: Install Go dependencies
        run: go mod tidy
        
      - name: Create environment file
        run: echo "${{ secrets.ENV }}" > .env
        
      - name: Build application
        run: GOOS=linux GOARCH=amd64 go build -o bin/${{ env.BINARY_NAME }} ./cmd/api-gateway
    
      - name: Upload build artifact
        uses: actions/upload-artifact@v4
        with:
          name: api-binary
          path: bin/${{ env.BINARY_NAME }}
          retention-days: 7

  # Setup service (manual trigger only)
  setup-service:
    runs-on: ubuntu-latest
    if: github.event_name == 'workflow_dispatch' && github.event.inputs.action == 'setup-service'
    steps:
      - uses: actions/checkout@v4
      
      - name: Set up SSH
        run: |
          mkdir -p ~/.ssh
          chmod 700 ~/.ssh
          echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
          chmod 600 ~/.ssh/id_rsa
          ssh-keyscan -H ${{ secrets.EC2_INSTANCE_IP }} >> ~/.ssh/known_hosts
          chmod 644 ~/.ssh/known_hosts
      
      - name: Setup systemd service
        run: |
          ssh -i ~/.ssh/id_rsa ec2-user@${{ secrets.EC2_INSTANCE_IP }} << 'EOF'
            # Create service user
            sudo useradd --system --home /var/lib/${{ env.SERVICE_NAME }} --create-home --shell /bin/false ${{ env.SERVICE_NAME }} || true
            
            # Create directories
            sudo mkdir -p /var/lib/${{ env.SERVICE_NAME }}
            sudo mkdir -p /var/log/${{ env.SERVICE_NAME }}
            sudo mkdir -p /etc/${{ env.SERVICE_NAME }}
            
            # Set ownership
            sudo chown -R ${{ env.SERVICE_NAME }}:${{ env.SERVICE_NAME }} /var/lib/${{ env.SERVICE_NAME }}
            sudo chown -R ${{ env.SERVICE_NAME }}:${{ env.SERVICE_NAME }} /var/log/${{ env.SERVICE_NAME }}
            sudo chown -R ${{ env.SERVICE_NAME }}:${{ env.SERVICE_NAME }} /etc/${{ env.SERVICE_NAME }}
            
            # Create systemd service file
            sudo tee /etc/systemd/system/${{ env.SERVICE_NAME }}.service > /dev/null << 'SERVICE_EOF'
          [Unit]
          Description=API Gateway Service
          Documentation=https://github.com/yourorg/your-repo
          After=network.target
          Wants=network-online.target

          [Service]
          Type=simple
          User=${{ env.SERVICE_NAME }}
          Group=${{ env.SERVICE_NAME }}
          WorkingDirectory=/var/lib/${{ env.SERVICE_NAME }}
          EnvironmentFile=/etc/${{ env.SERVICE_NAME }}/.env
          ExecStart=${{ env.DEPLOY_PATH }}/${{ env.BINARY_NAME }}
          ExecReload=/bin/kill -HUP $MAINPID
          KillMode=mixed
          KillSignal=SIGINT
          TimeoutStopSec=30

          # Security settings
          NoNewPrivileges=true
          PrivateTmp=true
          ProtectSystem=strict
          ProtectHome=true
          ReadWritePaths=/var/lib/${{ env.SERVICE_NAME }} /var/log/${{ env.SERVICE_NAME }}

          # Resource limits
          LimitNOFILE=65536
          LimitNPROC=4096

          # Logging
          StandardOutput=append:/var/log/${{ env.SERVICE_NAME }}/service.log
          StandardError=append:/var/log/${{ env.SERVICE_NAME }}/error.log
          SyslogIdentifier=${{ env.SERVICE_NAME }}

          # Restart policy
          Restart=always
          RestartSec=5
          StartLimitInterval=60
          StartLimitBurst=3

          [Install]
          WantedBy=multi-user.target
          SERVICE_EOF
            
            # Reload systemd and enable service
            sudo systemctl daemon-reload
            sudo systemctl enable ${{ env.SERVICE_NAME }}
            
            echo "Service setup complete!"
            echo "Service file created at: /etc/systemd/system/${{ env.SERVICE_NAME }}.service"
            echo "Configuration directory: /etc/${{ env.SERVICE_NAME }}/"
            echo "Logs directory: /var/log/${{ env.SERVICE_NAME }}/"
          EOF

  # Service management (manual triggers only)
  service-control:
    runs-on: ubuntu-latest
    if: github.event_name == 'workflow_dispatch' && contains('start,stop,restart,status,logs', github.event.inputs.action)
    steps:
      - name: Set up SSH
        run: |
          mkdir -p ~/.ssh
          chmod 700 ~/.ssh
          echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
          chmod 600 ~/.ssh/id_rsa
          ssh-keyscan -H ${{ secrets.EC2_INSTANCE_IP }} >> ~/.ssh/known_hosts
          chmod 644 ~/.ssh/known_hosts
      
      - name: Execute service action
        run: |
          ssh -i ~/.ssh/id_rsa ec2-user@${{ secrets.EC2_INSTANCE_IP }} << EOF
            case "${{ github.event.inputs.action }}" in
              "start")
                echo "Starting ${{ env.SERVICE_NAME }} service..."
                sudo systemctl start ${{ env.SERVICE_NAME }}
                ;;
              "stop")
                echo "Stopping ${{ env.SERVICE_NAME }} service..."
                sudo systemctl stop ${{ env.SERVICE_NAME }}
                ;;
              "restart")
                echo "Restarting ${{ env.SERVICE_NAME }} service..."
                sudo systemctl restart ${{ env.SERVICE_NAME }}
                ;;
              "status")
                echo "Service status:"
                sudo systemctl status ${{ env.SERVICE_NAME }} --no-pager
                ;;
              "logs")
                echo "Recent service logs:"
                sudo journalctl -u ${{ env.SERVICE_NAME }} --no-pager -n 50
                echo ""
                echo "Recent application logs:"
                sudo tail -n 50 /var/log/${{ env.SERVICE_NAME }}/service.log || echo "No service logs found"
                echo ""
                echo "Recent error logs:"
                sudo tail -n 50 /var/log/${{ env.SERVICE_NAME }}/error.log || echo "No error logs found"
                ;;
            esac
            
            # Always show final status unless it was a logs command
            if [ "${{ github.event.inputs.action }}" != "logs" ]; then
              echo ""
              echo "Current service status:"
              sudo systemctl status ${{ env.SERVICE_NAME }} --no-pager || true
            fi
          EOF

  # Deploy to dev
  deploy-dev:
    if: github.ref == 'refs/heads/dev' && (github.event_name == 'push' || (github.event_name == 'workflow_dispatch' && github.event.inputs.action == 'deploy'))
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Download build artifact
        uses: actions/download-artifact@v4
        with:
          name: api-binary
          path: bin/
      
      - name: Make binary executable
        run: chmod +x bin/${{ env.BINARY_NAME }}
      
      - name: Create environment file
        run: echo "${{ secrets.ENV }}" > .env
      
      - name: Set up SSH
        run: |
          mkdir -p ~/.ssh
          chmod 700 ~/.ssh
          echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
          chmod 600 ~/.ssh/id_rsa
          ssh-keyscan -H ${{ secrets.EC2_INSTANCE_IP }} >> ~/.ssh/known_hosts
          chmod 644 ~/.ssh/known_hosts
      
      - name: Deploy to EC2 Dev
        run: |
          scp -i ~/.ssh/id_rsa bin/${{ env.BINARY_NAME }} .env ec2-user@${{ secrets.EC2_INSTANCE_IP }}:/home/ec2-user/
          
          ssh -i ~/.ssh/id_rsa ec2-user@${{ secrets.EC2_INSTANCE_IP }} << 'EOF'
            # Stop service gracefully
            sudo systemctl stop ${{ env.SERVICE_NAME }} || true
            
            # Update binary
            sudo mv /home/ec2-user/${{ env.BINARY_NAME }} ${{ env.DEPLOY_PATH }}/
            sudo chmod +x ${{ env.DEPLOY_PATH }}/${{ env.BINARY_NAME }}
            sudo chown ${{ env.SERVICE_NAME }}:${{ env.SERVICE_NAME }} ${{ env.DEPLOY_PATH }}/${{ env.BINARY_NAME }}
            
            # Update environment file
            sudo mv /home/ec2-user/.env /etc/${{ env.SERVICE_NAME }}/
            sudo chown ${{ env.SERVICE_NAME }}:${{ env.SERVICE_NAME }} /etc/${{ env.SERVICE_NAME }}/.env
            
            # Start service
            sudo systemctl start ${{ env.SERVICE_NAME }}
            
            # Wait a moment and check status
            sleep 3
            sudo systemctl status ${{ env.SERVICE_NAME }} --no-pager
          EOF
      
      - name: Health check (Optional)
        run: |
          sleep 10
          # Replace with your actual health check endpoint
          if command -v curl >/dev/null 2>&1; then
            curl -f -s http://${{ secrets.EC2_INSTANCE_IP }}:${{ secrets.PORT}}/health || echo "Health check endpoint not available"
          else
            echo "Curl not available, skipping health check"
          fi

Okay, I gave you the workflow file of your dreams, you can worship me now.

You may be wondering why I gave you this and didn’t give you the code. Simple answer, “I don’t know” — I don’t have the answer to everything. Also, I didn’t give you the .env and secrets that I keep making reference to, so…

Step 4 — Redirect traffic from a specific URL to your app

Now, we get to talk about the clickbait I used into pulling you into this article — Caddy.

Before that though, if you don’t know Caddy, you’re missing out — it’s Nginx’s cousin — written in Golang (so I’m super biased). There’s this article that explains why you may choose it even though the article is more biased than I am :) — I love nginx though, but maybe when I have more complex deployments to do — xoxo.

So, who is Nginx and why are we NOT talking about her today? — Yep it’s a her, stick with me now.

These guys know how to do one thing well — “reverse proxying”

They listen on your specified domain and forward the request to the required service, are you with me now?

So, they are my API Gateway’s Gateway — WORD!

Installing Caddy on Amazon Linux

# Add the Caddy repository
sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://caddyserver.com/api/download?os=linux&arch=amd64&arm=&p=github.com%2Fcaddyserver%2Fcaddy

# Install Caddy
sudo yum install caddy

This entire article could simply be the bash script above, Yes. Because the title says so — Why did you click this link without knowing what reverse proxying is? skazhite mne, pozhaluysta!

The CaddyFile

<your-domain.com> {
    reverse_proxy [::1]:9000
}

My app is hosted on port 9000, so I pointed my entire domain there, because I like to live dangerously.

Conclusion

Doing all these things and feeling like a boss doesn’t mean your app would automatically become available, sorry to burst your bubble. If it worked, Phew! — If it didn’t , you’re on your own — 🌚

Issues you may face:

I can’t see my app on that URL

• Are you sure you’ve set up the URL correctly?
• run dig <your-domain.com> from anywhere and check to see if you see your machine IP on the results
• Is your domain registrar aware of this your deployment? If you haven’t heard of Route 53 and you’re using AWS — There’s no way this article worked. If it did, please send me an email so that I can help stop that abomination.

Thank you for reading this unorganized mess of ideas flying from my head.

Johnpaul Muoneme: Code Architect — 8Ball NG

— My visual idea of Postgres migrations

It was a quiet night, the kind where you can hear your thoughts bounce off the walls. My to-do list for the day had already been ambitious, but a pressing problem emerged that couldn’t wait for the light of day: a tangled mess of database migrations.

As a software engineer, I’ve always enjoyed (that’s a strong word?) the methodical nature of working with migrations. They’re the lifeblood of evolving systems — incrementally improving schemas while preserving the past. But that (this?) night, I was confronted with a common yet tedious problem: renumbering and restructuring migration files still in development.

The Problem: Manual Renumbering Chaos

If you’ve ever worked on a project with evolving migrations, you know the drill — adding a new migration to a sequence means renaming several existing files to make room and forgetting to do this properly leads to out-of-order migrations, causing headaches for your team and future-you. While tools exist for production-ready migrations, few handle in-development migrations gracefully.

Inspiration Strikes

Frustrated by the repetitive renumbering process and aware of the looming morning deadline, I decided to automate this problem. The idea was simple: write a Zsh script that could:

1. Insert new migrations seamlessly, renumbering existing files where necessary.
2. Create both .up.sql and .down.sql files for the new migration.
3. Allow easy reversion of migrations by removing the relevant files and renumbering only the subsequent ones.

I settled specifically for ZSH just out of habit, it’s not offering any special functionalities (yet).

The Solution: Migration Editor Script

What emerged in the early hours of the morning was a concise, efficient script. With a single command, I could:

• Add a new migration to a specific folder, ensuring all filenames stayed sequential.
• Remove an existing migration and maintain order without disturbing unrelated files.

Why It’s Useful

This script filled a glaring gap in my development workflow. It’s not uncommon for migrations to change multiple times before release. Having a tool that lets me focus on the actual migration logic instead of micromanaging file names was a game changer. It also improved collaboration by making the migration structure predictable for everyone on the team.

Lessons from Midnight Coding

Building this script reminded me of a few things:

1. Necessity Breeds Innovation: The best tools often come from solving immediate, personal pain points.
2. Automation is Key: If something is repetitive and error-prone, automate it. Future-you will thank you.
3. Simplicity Wins: By keeping the script’s functionality focused and intuitive, it became easier to use and maintain.

A Call to Action

If you’ve ever been in a similar situation, juggling migration files while racing against a deadline, consider giving this script a try. View the implementation on GitHub. It’s a small tool, but it is saving me hours and a fair share of frustration. Plus, there’s something deeply satisfying about turning a problem into a somewhat polished solution — even if it means burning the midnight oil to do it.

Picture this: You’re standing in line at a digital coffee shop, clutching your virtual wallet. The person ahead orders a $3 latte, then winces as they’re charged a $47 “convenience fee” to process the transaction. Welcome to the world of Ethereum, where paying more in gas fees than the actual transaction value isn’t a bug — it’s a feature.

Blockchain evangelists promised us a decentralized utopia. What we got instead was a digital toll booth on every corner, operated by miners who make highway robbers look charitable. Ethereum’s gas fees aren’t just high — they’re a masterclass in absurdity, fluctuating with the reliability of a weather vane in a hurricane.

But perhaps that’s fitting for a technology that’s essentially a solution searching for a problem. Blockchain: the answer to the question nobody asked, unless that question was “How can we make databases less efficient while consuming the energy output of a small nation?”

The true joke isn’t the technology itself — it’s the collective suspension of disbelief required to keep this circus running. We’ve created a system where digital artists spend more energy minting an NFT than their great-grandparents used in their entire lifetime, all while preaching about democratizing finance.

And yet, like a casino where everyone thinks they’ll be the exception, the crypto world keeps spinning. Developers keep building, investors keep investing, and somewhere, a computer is burning enough electricity to power a small city — all to process someone’s $5 transaction with a mere $150 gas fee.

The emperor isn’t just naked — he’s trying to sell you his invisible clothes as an NFT.

The real magic of blockchain isn’t in its technology — it’s in its ability to make intelligent people abandon common sense. Venture capitalists who wouldn’t buy a sandwich without a 50-page due diligence report suddenly throw millions at projects whose white papers read like science fiction written by a ChatGPT prompt gone wrong.

Consider the evolutionary path: Bitcoin appears, promising freedom from banks. Then comes Ethereum, promising to run the world’s computer. Now we have thousands of blockchains, each promising to be the next big thing, while collectively delivering all the utility of a digital pet rock. It’s like watching a game of technological telephone, where each iteration gets progressively more divorced from reality.

The Layer 2 solutions they’re building? That’s like adding a second story to a house with no foundation. “But it’ll scale!” they cry, as if bolting on complexity to a fundamentally flawed system is the answer. It’s the equivalent of solving a traffic jam by building roads on top of roads — eventually, you’re just creating skyscrapers of problems.

And let’s talk about the community — a fascinating blend of libertarian idealists, get-rich-quick schemers, and tech enthusiasts who’ve convinced themselves that paying $200 to move $50 is somehow the future of finance. They’ve created a culture where losing money is called “having diamond hands” and common sense is FUD (Fear, Uncertainty, and Doubt).

The truly ironic part? The same people who rail against traditional finance’s 2% transaction fees will happily pay 50% in gas fees because it’s “decentralized.” It’s as if the mere act of making something more complicated and less efficient somehow makes it more valuable.

But perhaps the most entertaining aspect is watching blockchain try to solve real-world problems. It’s like watching someone try to eat soup with a fork — technically possible, but there are clearly better tools for the job. Need a database? Here’s a blockchain! Want to track shipping? Blockchain! Have a headache? You guessed it — there’s probably a blockchain solution for that too.

The emperor is still naked, but now he’s giving a TED talk about how clothes are outdated technology anyway.

I think people simply need to use the tools at their disposal to try to get better instead of hating on these tools and claiming that every smart person is high on GPT.

In this AGE or dare I say ‘Period’ of the ‘AI’ fad, there have been series of incidents that have caused this article to spawn out of the brain of an angry writer onto the inter-webs to be consumed not by the target audience (aka Naysayers), but by people that share a similar sentiment with me — Smarty Pants.

As a Software Engineer, I’m held to high standards (fortunately) when there’s a need to produce working and usable software but my opinions are blatantly disregarded concerning how that software should be built or how it even works! This is me digressing because I’m in the angry mood, but there’s a reason for that, AI.

Artificial Intelligence is simply ‘smarter computing’ — but the term ‘smarter’ seems not to be able to be comprehended by people. It isn’t a brand new thing but an enhancement on the existing functionalities of computers made possible by an enormous amount of data being excreted by the holy and infallible minds on the internet.

There are 2 things I want people who read this article to do:

Stop blaming your lack of verbal dexterity and awareness on the existence of Artificial Intelligence.

Stop looking for every avenue to SCREAM Bloody Murder! when someone sounds or writes like they have read a book or two.

Before we go into the ethics of the usability of AI, let us start by understanding what the possible reasons for it were. A couple of my friends have compared it to the days of the calculator (that’s the little machine we use to add, subtract, divide and multiply for my default intelligence brethren), where the new portable machine made it possible to make complex calculations without the need to shed brain cells like lookup-tables storing complex results. It made it so that people who could do those things now looked like entertainers (every single person that knows the first 50 digits of Pi is always looking for an avenue to say it — Entertainer).

The advent of computing caused a relegation of mundane things to the metal beasts we basically currently survive on, so why is it that we are riding on the wave of AI both super-positively — like its a fix-it-all solution and super-negatively — like it will bring upon the end of human intelligence (like humanity hasn’t already crossed that bridge since social media).

There are 3 things (more like 2 things) I want people who read this article to know:

Artificial Intelligence has given us a lot of tools like LLMs (ChatGPT, BERT) and Generative AI like MidJourney (not-so-mid if you ask me).

Please learn to use them to ENHANCE yourself as an individual and improve your workflow.

Don’t rely on Pre-AI generic methods for evaluating people in tests or interviews, use reliable methods like situational-evaluation etc.

SideNote: It’s funny how the world has always wanted people to have access to knowledge, but it’s like everyone is now scared that every other person MAY be on some very accessible knowledge — like isn’t that what we wanted.

NOTE: Don’t school me on how AI may be wrong at times, simply perform knowledge verification as we do with our textbooks and articles.

ALSO: I find it hard to stay talking about one thing, so I digress a lot, please ask me questions if you need specifics.

Don’t be bitter, be better.

Thank you for reading this article.

Johnpaul Muoneme

There’s a reason you clicked this article. It’s not because this has any code snippets you need to solve the problem you’re looking for.

Take and eat.

// Function to generate the Fibonacci sequence up to the nth term
func fibonacci(n int) []int {
    fib := make([]int, n)
    fib[0], fib[1] = 0, 1
    for i := 2; i < n; i++ {
        fib[i] = fib[i-1] + fib[i-2]
    }
    return fib
}

Oh! well, look at that. It’s the fibonacci generator in Go (Programming Language).

How many times has this function been written? Your first guess will be wrong (99.9% probability).

The seemingly useless function has helped a lot of undergraduate students and self-taught programmers understand recursion. I’m also not about to talk about the Mathematical implementation. I’m just partial to actual code in this article (No hard feelings).

I’m actually having a seemingly interesting code-block, that is what inspired me to write this article. It’s mainly a jumble of words that seem to reflect the state of my mind while I struggle to concentrate hard enough to figure out how to continue with what I’m working on, I really hope this isn’t ‘burnout’ disguised as code-block. Oh well, I may never know.

There’s the proverbial noose around my motivation’s neck as it stands on the ledge of purpose.

And because AI can’t help me render that, here’s an equivalent image of how I feel.

Also, sorry if I didn’t offer any solutions in this article. If I did, the article’s title would have been different.

Thank you for reading.

Johnpaul Muoneme

I’m tired.

Backward compatible code ← → Forward compatible thinking is a principle that emphasises writing code that can gracefully accommodate changes in both past and future environments. Here’s what it means in practice:

Backward Compatible Code

• This aspect focuses on ensuring that your code remains functional and compatible with older versions of dependencies, platforms, or APIs.
• It involves writing code that can run without issues on older versions of libraries, frameworks, or platforms, ensuring a smooth transition for users who haven’t upgraded yet.
• Backward compatible code allows existing users to upgrade their software without facing compatibility issues or breaking changes.

Let’s say we have an API that serves users their account balance such as the following

GET /api/account/{accountId}/balance

RESPONSE
{
  "balance": 1000.50,
  "currency": "USD",
  "lastUpdated": "2024-05-23T12:00:00Z"
}

Here’s how the API might work:

• Method: GET
• Path: /api/account/{accountId}/balance
• Description: Retrieve the account balance for the user with the specified accountId.
• NOTE: Although simple, we have to assume this is a secure banking system so users do not have access to PATHs that may contain other users’ information (e.g. userId).

If this API functionality is to be updated, the assumption is that breaking backwards compatibility is bad, even in situations where we may not need the accountId object anymore, the preferred approach is still allow the user pass the values, as long as we DO NOT officially propose a complete system overhaul.

Moving from this:

GET /api/account/{accountId}/balance

RESPONSE
{
  "balance": 1000.50,
  "currency": "USD",
  "lastUpdated": "2024-05-23T12:00:00Z"
}

To this:

GET /api/account/{accountId}/balance

RESPONSE
{
  "balance": {
    "amount": 1000.50,
    "currency": "USD"
  },
  "lastUpdated": "2024-05-23T12:00:00Z",
  "accountStatus": "active",
  ...
}

Is a very terrible way of migration, as existing systems may not be able to accomodate for this.

GET /api/account/{accountId}/balance 
GET /api/account/balance

Instead, offering a clearer or newer way of accessing the same object type in form of versioning works, or simply returning the same object with the old fields unaffected while enhancing with newer fields.

RESPONSE
{
  "balance": 1000.50,
  "currency": "USD",
  "lastUpdated": "2024-05-23T12:00:00Z",
  "accountStatus": "active",
  "new_balance": {
    "amount": 1000.50,
    "currency": "USD"
  },
  ...
}

This may seem repetitive, but WOULD those few bytes you save actually SAVE you from the infuriated clients and developers that are currently depending on your systems? — I think not.

Code Level Backward Compatibility

Most times, we face a situation where we need to make certain functionality more dynamic. For example, migrating the simple function below:

/// Combine two objects using an implementation hidden functionality
int combine(Object a, Object b){
  ...
}

To one of the following

/// Force the users to add a combineFunction or else their function won't work
int combine(Object a, Object b, Function combineFunction){
  ...
}

/// Add an optional function parameter with a DEFAULT VALUE to the parameter list
int combine(Object a, Object b, {Function combineFunction = add()}){
  ...
}

If it feels like you’re going to break some old things with your new implementation, try to ensure that you’ve had enough sleep.
— Johnpaul Muoneme

Forward Compatible Thinking

• Forward-compatible thinking involves anticipating and preparing for future changes, updates, or advancements in technology.
• It means designing your codebase with flexibility and extensibility in mind, so it can adapt to future requirements and updates without requiring significant rework.
• This includes considering potential future changes in APIs, platform requirements, or business needs and designing your code to accommodate them seamlessly.

Practical Strategies

To achieve backward compatibility and forward-compatible thinking, we would need to do the following:

• Version Checking: Check the version of dependencies or platforms your code relies on and adjust behaviour accordingly to maintain compatibility with older versions.
• Feature Detection: Use feature detection techniques to determine whether certain functionality is available in the current environment and provide alternative implementations if necessary.
• API Design: Design clear and stable APIs that are unlikely to change frequently, but also allow for extension and evolution without breaking existing implementations.
• Documentation and Communication: Document any compatibility considerations, version requirements, or potential breaking changes to help users understand how to use your code effectively across different environments.
• Testing: Write comprehensive tests that cover various use cases and edge cases, including scenarios where backward compatibility or forward compatibility may be crucial.

By embracing the principle of “Backward Compatible Code | Forward Compatible Thinking,” you can build software that not only works reliably in current environments but also remains adaptable and resilient to future changes and advancements. — Johnpaul Muoneme

Thank you for reading 👏🏽

Johnpaul Muoneme
Code Architect — 8Ball NG 🎱🇳🇬

So, user sessions are basically like a passport for your interaction with a website or app. When you log in, you’re starting a session, and as long as you’re active, it keeps track of your actions and preferences. If you’re inactive for a while, it might log you out for security. It’s like having a virtual ticket to stay connected until you’re done using the platform.

So, say cheese!

So why would users need to have passports to access your app?

Well, it’s pretty simple: You want to know who they are so you can understand what they’re doing on your platform.

Personalisation: By knowing who’s using the app, you can tailor the experience to their preferences. Think about how Netflix recommends shows based on your watch history or how Amazon suggests products based on your past purchases.

Security: Having users log in helps ensure that only authorised individuals are accessing sensitive information or performing certain actions within the app. It’s like having a bouncer at the door of a club to keep out unwanted guests.

Analytics: Understanding who your users are and how they interact with your app can provide valuable insights for improving the user experience. You can track things like which features are most popular, where users are dropping off, and how long they’re spending in the app.

Communication: User sessions allow you to communicate with users more effectively. For example, you can send targeted notifications or emails based on their behaviour or preferences, leading to higher engagement and retention rates.

So what have we learned?

User sessions might seem like a hassle, but they’re essential for creating personalised, secure, and engaging experiences for users. So next time you log in, remember that little passport is there to make your journey smoother.

Until next time!

Johnpaul Muoneme