DEV Community: Ezeana Micheal

The Bilingual Developer: Python and Go Core Functions

Ezeana Micheal — Fri, 19 Jun 2026 18:32:56 +0000

The Bilingual Developer: Python and Go Core Functions

So far in our journey, we have explored the building blocks of programming:

How to store data using variables,
How to guide the flow of execution using conditional statements, and
How to repeat actions efficiently using loops.

These tools are enough to write simple scripts that can process data or automate mundane tasks.

However, as you start to write larger, more ambitious applications, a new and significant challenge emerges. Imagine you are building an e-commerce platform. You will need the logic for calculating prices based on complex discount rules, validating user credentials against a database, sending transactional emails, and even securely processing credit card payments.

If you try to cram all of this functionality into one massive, linear/sequential file, the code quickly descends into what developers affectionately refer to as "spaghetti code." The logic becomes intertwined, variables conflict with each other, and making a single change to a pricing rule might unexpectedly break the email system. Tracking down a single bug in a 10,000-line file becomes a detective's nightmare, and collaborating with other developers becomes nearly impossible.

This is precisely where functions come into play.

Why Functions?

A function allows us to encapsulate a specific piece of logic into an independent, reusable, and named block of code. We can define the logic once and then "call" it whenever we need that specific behavior.

Think of a function like a specialized machine on an assembly line. You place raw materials at the entrance (these are the inputs or parameters). The gears and motors inside turn and process those materials (this is the internal processing). Finally, a finished product rolls out at the end (this is the return value).

For example, consider a calculator function: the input would be the numbers and the operation (e.g., 5 + 10), the processing would be the internal addition logic, and the output would be the answer (15). This separation between the "how" (the internal mechanics) and the "what" (the input/output) is what makes functions so powerful.

Both Python and Go rely heavily on functions, but once again, the way they define, structure, and treat these functions showcases a fundamental difference in the philosophies of the two languages.

What is a Function?

At its core, a function is a reusable block of code designed to perform a single, specific task. Think of it as a verb in your program; it acts.

Instead of writing the same code repeatedly, like manually printing a welcome message for each user:

print("Welcome Michael")  
print("Welcome Sarah")  
print("Welcome David")

You can create a function named welcome_user() and simply reuse that one-liner over and over again.

This simple abstraction provides benefits to software development:

Avoiding Repetition (DRY Principle): Standing for Don't Repeat Yourself, this is a core tenet of software engineering. If you need to change the welcome message from "Welcome" to "Greetings", you only need to change the code inside the function once, rather than searching through hundreds of files.
Better Organization: Functions allow you to break a massive, monolithic program into small, digestible, logical modules. You can group related tasks together (e.g., putting all user authentication logic into a single file of functions).
Simplified Debugging: When a bug occurs, functions help isolate the problem. If the pricing calculation is wrong, you know exactly which function to inspect without sifting through irrelevant code for user validation.
Reusable Components: Once you write a function, you can use it in different parts of your application, or even copy it into a completely different project, saving precious development time.

The Anatomy of Function Definition

The very first difference we encounter between Python and Go is the syntax required to declare a function to the compiler or interpreter.

Python: Using def

Python prides itself on readability, and its function definition syntax is an excellent example. It uses the straightforward keyword def, which is an abbreviation for "define."

def greet():  
    print("Hello Developer")

To execute this function, you simply call it by its name followed by parentheses:

greet()

Output:

Hello Developer

We can notice how Python's structure almost reads like plain English: Define a function called greet. Furthermore, Python does not use brackets to define the scope of the function. Instead, it strictly relies on indentation(as we have seen in loops and conditions too). The indented block of code directly underneath the def statement is what belongs to the function. This forces clean, uniform formatting across all Python code.

Go: Using func

Go takes a slightly more terse, brace-oriented approach. It uses the keyword func to declare a function.

func greet() {  
    fmt.Println("Hello Developer")  
}

Calling the function is syntactically similar to Python:

greet()

Output:

Hello Developer

However, the structural differences are immediately apparent. Go uses curly braces { } to define the beginning and end of the function's logic, much like C, Java, or JavaScript. Additionally, Go is strict about syntax; the opening curly brace must be on the same line as the function declaration, otherwise, the compiler will throw an error. While Python relies on the developer to maintain consistent whitespace, Go offloads that structural enforcement to the compiler using braces.

Passing Information: Functions With Parameters

Most functions are not meant to do the exact same thing every single time. They need dynamic information to work with. For instance, instead of creating a function that always prints "Hello Michael", we want a function that works for anyone.

Python Parameters

Python allows you to define parameters inside the parentheses. Because Python is dynamically typed, you just provide the variable name without specifying what kind of data it is.

def greet(name):  
    print("Hello", name)

When you call this function, you pass the value:

greet("Michael")

Output:

Hello Michael

Python's approach emphasizes flexibility. You can pass a string, an integer, or even a list into that name parameter. While this is convenient, it means the interpreter will only realize you passed a wrong type (like a number that breaks the print formatting) when the code is actually running. Although in newer versions of python you can specify a type hint to specify datatype, see more below.

Go Parameters

Go, on the other hand, requires explicit type declarations. When defining the function, you must tell the compiler exactly what data type the name parameter is expected to hold.

func greet(name string) {  
    fmt.Println("Hello", name)  
}

The name string part is mandatory. It tells Go: "This function expects a single argument called 'name', and it must strictly be a string." Calling the function remains the same:

greet("Michael")

This requirement ensures that the Go compiler knows exactly how much memory to allocate for the variable and prevents you from accidentally passing an integer to a function that expects text.

Understanding Function Signatures

In computer science, a function signature acts as the "contract" of a function. It defines the function's name, the types and order of its parameters, and the types of values it returns. This is where Python and Go fundamentally diverge.

Python: Optional Type Hints

Python operates on dynamic typing. By default, Python does not care about the data types, so a signature is simply the name and parameter list:

def add(a, b):  
    return a + b

The interpreter figures out what a and b are only when the function runs.

However, Python 3 introduced "Type Hints" to add optional clarity:

def add(a: int, b: int) -> int:  
    return a + b

Here, we communicate our intention: a and b should be integers, and the output should be an integer. This is fantastic for documentation and helps IDEs catch potential issues. Crucially, however, Python does not enforce these hints. You could still write:

add("Hello", "World")

Depending on the context, this might run perfectly fine (it would concatenate the strings) or crash. The responsibility lies entirely with the developer and third-party tools like mypy.

Go: Mandatory Types

Go is a statically typed language. Types are not optional; they are part of the language's DNA. The function signature is explicitly defined:

func add(a int, b int) int {  
    return a + b  
}

Here, the signature is rigid and unmistakable:

Inputs: a (int) and b (int).
Output: int.

The Go compiler rigorously checks these type definitions during the compilation phase, which happens before the code ever runs. This is known as compile-time safety. Consequently, if you try to compile add("Hello", "World"), the compiler will halt and refuse to build the executable, throwing a type mismatch error instantly.

This difference highlights the core philosophies: Python acts like a flexible workshop where you can modify things quickly with few restrictions, while Go acts like a precision engineering lab where everything must be measured and declared upfront to prevent catastrophic failures later.

Returning Data

Most functions are designed not just to perform an action but to compute a result and hand it back to the part of the program that called them. For example, a calculator function isn't helpful if it just calculates internally and throws the answer away; it must return the answer.

Python: Returning Values

Python uses the return keyword to send data back.

def add(a, b):  
    return a + b

result = add(5, 10)  
print(result) # Output: 15

While Python appears to support returning multiple values, it actually does so using a trick. When you write return "Michael", 25, Python is internally creating a tuple and returning that single container.

def user_info():  
    return "Michael", 25

name, age = user_info() # This is tuple unpacking

The function didn't natively return two separate things; it returned one tuple, and Python gracefully unpacked it into two variables.

Go: Native Multiple Return Values

Go has native support for returning multiple distinct values directly from the function, without wrapping them in a container.

func userInfo() (string, int) {  
    return "Michael", 25  
}

name, age := userInfo()  
// name is now "Michael", age is now 25

The (string, int) part of the signature explicitly declares that this function will produce two separate values. This is a language-level feature, not a trick.

Why Multiple Returns Are a Game-Changer in Go

The native support for multiple return values isn't just a syntactic convenience; it fundamentally shapes how Go handles errors.

In many other languages (including Python), errors are often handled using try/except blocks. These exceptions can be thrown deep inside a function and caught elsewhere, potentially leading to situations where a developer forgets to catch an error entirely, causing the program to crash unpredictably.

Go takes a radically different approach. It discourages exceptions in favor of explicit error handling. The most idiomatic pattern in Go is to return two values:

The actual result (if successful).
An error value (if something went wrong).

func divide(a int, b int) (int, error) {  
    if b == 0 {  
        return 0, errors.New("cannot divide by zero")  
    }  
    return a / b, nil // nil means "no error"  
}

When you call this function, you are forced to immediately acknowledge both the result and the possibility of an error:

result, err := divide(10, 2)  
if err != nil {  
    fmt.Println("Oops:", err)  
} else {  
    fmt.Println("Result:", result)  
}

This pattern appears everywhere in Go. It forces the developer to confront the possibility of failure right at the point of execution, leading to more robust, predictable software.

Python vs. Go: The Underlying Philosophies

Python's Angle: Python focuses on developer velocity and flexibility. It uses def, treats types as optional enhancements, and allows functions to accept a variety of data without strict declarations.

Go's Angle: Go focuses on clarity, maintainability, and safety. It uses func, mandates types, and ensures that the inputs and outputs of every function are crystal clear to both the developer and the compiler.

Finally

Mastering functions is an exciting leap in the programming journey. It marks the transition from writing small, disposable scripts to architecting real, maintainable applications. Functions allow you to take complex, tangled logic and break it down into small, reusable pieces.

A Python developer moving to Go might initially feel constrained, asking, "Why do I have to write all these types and explicitly handle every error?"

I felt this way before, and honestly, its worth it. This constraint is a feature, not a bug. Go pushes you to clearly articulate how data moves through your program, ensuring you understand the flow of information thoroughly before the code even runs. Learning to appreciate this enforced clarity doesn't just make you better at Go; it fundamentally sharpens your discipline as a developer. It trains you to think critically about data flow and architecture, a skill that is invaluable regardless of which language you ultimately choose to write your applications in.

Thanks for reaching the end of my article, like, comment and share, lets keep-on our journey dual-learning.

Why Go's Goroutines Made Concurrency Finally Click for Me

Ezeana Micheal — Fri, 19 Jun 2026 18:12:27 +0000

I’ve been writing Python for a long time, and like many developers in that space, I got used to a certain way of thinking about concurrency: async/await, event loops, and carefully managing when things pause and resume. It worked well but sometimes it felt like I was always negotiating with the runtime instead of just expressing what I actually want: “run these things at the same time.”

Then I started studying Go (programming language), and specifically goroutines.

The Python Mental Model: Concurrency as Coordination

In Python, especially with asyncio, concurrency often feels like structured waiting. With Python (programming language), you typically deal with:

An event loop
async functions
await points that explicitly yield control
Tasks that must cooperate

You don’t just “run things at the same time.” You define where they can pause.

That design is nice, especially for I/O-heavy workloads. But mentally, there’s always overhead:

Where do I await?
Am I blocking the loop?
Why isn’t this coroutine running?

Even when you understand it, concurrency still feels like something you carefully orchestrate.

Enter Goroutines: Concurrency as a Default State

Then I met goroutines. A goroutine is deceptively simple:

go doSomething()

That’s it, no need for an async keyword, event loop management or even explicit suspension points. The runtime handles scheduling. You don’t coordinate concurrency, you declare it.

At first, this feels almost too simple. But that’s the shift: Go already made the hard decisions for you.

The Mental Shift: From Await Points to Independent Workers

To illustrate, Python async feels like a single chef multitasking in one kitchen. Go feels like hiring multiple cooks.

In Python:

One worker switches tasks
You define pause points
Everything shares a single execution flow

In Go:

Each goroutine is a worker
Tasks run independently
You just assign work and move on

That difference is why goroutines clicked: they match how systems feel in real life, not how we simulate them.

Async vs Go: Pros and Cons

Python Async (async/await)

Pros:

Very explicit control over execution flow
Excellent for structured I/O concurrency (web servers, APIs)
Easier debugging in some cases (you can trace await chains)
Fine-grained control over when tasks yield

Cons:

Requires careful mental tracking of the event loop
“Async all the way down” problem (one blocking call breaks everything)
More boilerplate and discipline required
Easy to accidentally mix sync + async and create issues
Concurrency feels manual rather than natural

Go Goroutines

Pros:

Extremely simple syntax (go function())
Concurrency feels natural and lightweight
Runtime handles scheduling automatically
Scales easily to thousands/millions of goroutines
Cleaner mental model for independent tasks

Cons:

Less explicit control over scheduling
Can accidentally create race conditions if not careful
Requires channels or sync primitives for safe communication
Debugging concurrency issues can feel more opaque
“Too easy to start tasks” can lead to uncontrolled goroutine growth

Channels Made It Even Clearer

Goroutines alone are powerful, but channels complete the picture. Instead of shared memory and locks, Go encourages communication:

ch := make(chan int)  
go func() {  
    ch <- 42  
}()  
value := <-ch

The idea is simple:

Don’t share memory. Communicate instead. That forces a clean mental model:

Who sends data?
Who receives it?
What flows through the system?

Why It Clicked After Python Async

Ironically, I don’t think goroutines would’ve made sense to me without first struggling through Python async.

Python taught me:

Concurrency is not parallelism
Blocking matters
Coordination is hard

Go removed the ceremony and exposed the core idea: Concurrency is just structuring multiple flows of work.

Control vs Trust

Python async gives you control, so you decide when things pause. Go gives you trust, the runtime handles scheduling.

That shift is subtle but powerful:

Python: “I will manage concurrency carefully”
Go: “I will describe work and let the system handle it”

At first, trust feels risky. But it’s also what makes Go feel effortless.

Final Thought

Learning Go didn’t just give me a new tool, it changed how I think about concurrent systems. I still use Python and appreciate async/await, but I see it more clearly: it’s structured concurrency with explicit control. And in Go, I stop thinking about pauses . I just think: Start this. Let it run. Communicate when needed. That’s what finally made concurrency click. Its been a pretty fun journey, Let me know your thoughts, Like, Share and Comment what you think.

The Bilingual Developer: Python and Go Looping & Iteration

Ezeana Micheal — Fri, 12 Jun 2026 18:13:42 +0000

In the last article, I wrote about how programs make decisions using conditionals. We went through how a program can make a decision, choosing one path over another based on whether a condition is true or false.

But what if we need to perform the same action multiple times? Let's say you have a list of about 1,000 users and want to email each of them. You wouldn't write the email-sending code 1,000 times. Instead, you would write it once and have the program repeat it for each user. This is where looping comes in.

Looping allows a program to repeatedly execute a block of code until a condition is met or until all items in a collection have been processed. It's one of the most powerful concepts in programming because it helps us automate repetitive tasks and work with large amounts of data efficiently. Whether you're building a web application, analyzing data, processing files, or developing APIs, you'll find loops everywhere. Let's see how Python and Go approach this concept.

Understanding Iteration

Iteration simply means moving through a collection of data one item at a time. For example, if you have:

students = ["John", "Sarah", "David"]

Iteration means accessing:

John
Sarah
David

one after another. Loops are the mechanism that makes iteration possible. We will now consider some types of loops, first the for loop.

The For Loop

A for loop is used when you want to repeat something a specific number of times or go through a collection of items.

Python's Approach: for item in sequence

Python's for loop is designed around iteration. Instead of asking you to manage counters manually, Python allows you to directly loop through a sequence.

students = ["John", "Sarah", "David"]  
for student in students:  
    print(student)

If you read that aloud, it almost sounds like English: “For each student in students, print the student.” That's one of the reasons Python is often praised for readability. Python also provides the range() function when you want to repeat something a specific number of times.

for i in range(5):  
    print(i)

Output:

We can note that Python focuses less on how the loop works internally and more on what you're trying to accomplish.

Go's Approach: The Universal for Keyword

Instead of providing separate loop structures for different situations, Go uses a single keyword: for. This one keyword handles almost every looping scenario.

A traditional Go for loop looks like this:

for i := 0; i < 5; i++ {  
    fmt.Println(i)  
}

This structure contains three parts: initialization; condition; post-action

In this example:

i := 0 initializes the counter
i < 5 determines how long the loop runs (in this case limiting to 5)
i++ updates the counter by 1 after each iteration

When iterating over collections, Go uses the range keyword.

students := []string{"John", "Sarah", "David"}

for index, student := range students {  
    fmt.Println(index, student)  
}

Unlike Python, Go exposes both the position and the value by default.

This reflects Go's preference for being explicit about what's happening during execution.

The While Loop

Not every situation involves iterating through a collection. Sometimes you want code to keep running as long as a condition remains true.

For example:

Keep asking for a password until the user enters the correct one.
Continue processing requests while the server is running.
Retry an operation until it succeeds.

This is where while loops become useful.

Python's Explicit while Loop

Python provides a dedicated keyword for this purpose:

count = 0  
while count < 5:  
    print(count)  
    count += 1

The logic is straightforward, It continues running this block while the condition remains true and each time the loop runs, the condition is checked again So once the condition becomes false, the loop stops.

Go's Approach: Using for as a While Loop

Go does not have a while keyword.

Instead, Go reuses its universal for loop. To create while-loop behavior, you simply remove the initialization and post-action sections.

count := 0  
for count < 5 {  
    fmt.Println(count)  
    count++  
}

Infinite Loops

Sometimes a loop is intended to run forever until something inside it stops execution.

Python:

while True:  
    print("Running...")

Go:

for {  
    fmt.Println("Running...")  
}

You'll often see these in:

Web servers
Background workers
Event listeners
Real-time systems

Breaking and Continuing

To understand breaking and continuing, we should understand that not every loop should run to completion. Sometimes we want to stop a loop early or skip a particular iteration. This is where break and continue become useful.

Using break

The break statement immediately terminates the loop.

Python example:

for number in range(10):  
    if number == 5:  
        break  
    print(number)

Output:

The moment the value reaches 5, the loop stops completely. Go works the same way:

for i := 0; i < 10; i++ {  
    if i == 5 {  
        break  
    }

    fmt.Println(i)  
}

Again, execution stops as soon as the break statement is reached.

Using continue

The continue statement is slightly different. Instead of stopping the loop, it skips the current iteration and moves to the next one.

Python:

for number in range(5):  
    if number == 2:  
        continue  
    print(number)

Output:

Notice that 2 is skipped. Go behaves the same way:

for i := 0; i < 5; i++ {  
    if i == 2 {  
        continue  
    }

    fmt.Println(i)  
}

The current iteration is skipped, but the loop itself continues running.

Python's Angle vs Go's Angle

Looking at loops gives us another glimpse into the philosophy of both languages.

Python's Angle

Python is designed to make iteration feel natural.

for item in sequence
Dedicated while keyword
Readable syntax
Focus on expressing intent clearly

Python often hides implementation details so you can focus on solving the problem.

Go's Angle

Go prefers consistency over having many specialized constructs.

One loop keyword (for)
Multiple looping styles using the same structure
Explicit control over loop behavior
Less language complexity

Go's mindset is:

Learn one loop mechanism and use it everywhere.

Finally

Looping is one of the fast ways programs get work done in programming. Without loops, applications would struggle to process lists, handle user input, analyze data, or automate repetitive tasks. Python gives you specialized, highly readable constructs for iteration. Go gives you a single, versatile tool that can adapt to different situations.Both approaches are effective.

The real skill as a bilingual developer isn't memorizing syntax, but it's understanding the underlying concept. Once you understand what a loop is trying to achieve, switching between Python and Go becomes much easier. The syntax may change, but the logic remains exactly the same: repeat a task until you're done. Thanks for reading this article, hit the like and comment what you think, thanks.

I Rewrote Our REST API in GraphQL, Here's When It's Worth It

Ezeana Micheal — Tue, 09 Jun 2026 09:55:34 +0000

For most of my development career, REST was my only way of building APIs. It was what I learned first, and it stayed with me. I used it in different applications, including business applications, GIS platforms, dashboards, and e-commerce systems. REST felt natural because it was structured around resources, and the HTTP protocol made everything predictable.

I never really had a strong reason to explore GraphQL. It always felt like something that introduced extra level complexity and uncertainty without a clear benefit in a real production environment. That changed when I decided to rebuild part of an existing REST API using GraphQL, not as a replacement, but as an experiment to understand where it actually fits.

How REST Structures Systems

REST works by exposing resources through endpoints. In an e-commerce system, this typically looks like a clear separation of concerns across entities.

GET /products/100

GET /products/100/reviews

GET /products/100/related

GET /sellers/20

Each endpoint returns a specific dataset, and the frontend is responsible for combining them.

A simple product response might look like this:

{  
  "id": 100,  
  "name": "Wireless Headphones",  
  "price": 120,  
  "seller_id": 20  
}

Then another request is required to fetch the seller:

{  
  "id": 20,  
  "name": "Tech Store",  
  "rating": 4.7  
}

This structure works well because it is simple, explicit, and easy to debug. REST aligns strongly with business workflows where operations are clearly defined.

Where REST Starts to Show Limits

The challenge appears when frontend screens become more data-heavy. A single page in a modern application is rarely powered by a single endpoint. For a product page in an e-commerce system, the frontend may need product details, seller information, reviews, inventory, and related products.

With REST, this often becomes multiple sequential or parallel requests.

GET /products/100  
GET /sellers/20  
GET /products/100/reviews  
GET /inventory/100  
GET /products/100/related

The frontend is forced to merge these responses into one coherent view. On fast networks, this is manageable. On slower networks or mobile devices, it introduces latency and complexity in state management.

How GraphQL Changes the Model

GraphQL shifts the responsibility from multiple endpoints to a single query system. So Instead of the server deciding what each endpoint returns, the client defines exactly what it needs.

A GraphQL query for the same product page might look like this:

query {  
  product(id: 100) {  
    name  
    price

    seller {  
      name  
      rating  
    }

    reviews {  
      user  
      comment  
      rating  
    }

    inventory {  
      quantity  
      warehouse  
    }

    relatedProducts {  
      name  
      price  
    }  
  }  
}

The response comes back in a single structured payload:

{  
  "data": {  
    "product": {  
      "name": "Wireless Headphones",  
      "price": 120,  
      "seller": {  
        "name": "Tech Store",  
        "rating": 4.7  
      },  
      "reviews": [  
        {  
          "user": "John",  
          "comment": "Very good quality",  
          "rating": 5  
        }  
      ],  
      "inventory": {  
        "quantity": 34,  
        "warehouse": "Lagos Hub"  
      },  
      "relatedProducts": [  
        {  
          "name": "Bluetooth Speaker",  
          "price": 80  
        }  
      ]  
    }  
  }  
}

Instead of multiple requests, everything is resolved in one round trip.

Backend Structure Comparison

A REST controller typically looks like this:

@app.route("/products/<int:id>")  
def get_product(id):  
    return get_product_by_id(id)

@app.route("/products/<int:id>/reviews")  
def get_reviews(id):  
    return get_reviews_by_product(id)

In GraphQL, the structure shifts to types and resolvers:

class Product(graphene.ObjectType):  
    name = graphene.String()  
    price = graphene.Float()  
    seller = graphene.Field(Seller)  
    reviews = graphene.List(Review)

class Query(graphene.ObjectType):  
    product = graphene.Field(Product, id=graphene.Int(required=True))

    def resolve_product(self, info, id):  
        return fetch_product_with_relations(id)

The important difference lies in how data relationships are modeled. REST separates concerns by endpoint. GraphQL models relationships directly inside the type system.

GIS Example Where GraphQL Becomes More Obvious

In GIS and land management systems, data is naturally relational. A single land parcel is connected to many entities.

With REST, this might require multiple endpoints:

GET /lands/100  
GET /owners/25  
GET /surveys/10  
GET /documents?land_id=100  
GET /transactions?land_id=100

With GraphQL, the same structure becomes:

query {  
  land(id: 100) {  
    parcelNumber

    owner {  
      name  
      phone  
    }

    survey {  
      surveyor  
      date  
    }

    documents {  
      fileName  
    }

    transactions {  
      amount  
      date  
    }  
  }  
}

The response mirrors the real-world relationship between entities instead of forcing the frontend to assemble it manually.

Where GraphQL Does Not Replace REST

GraphQL is not designed for business operations. It is not ideal for workflows that involve state changes, validations, and side effects.

Actions like the following still fit REST better:

POST /orders

POST /login

POST /payments

POST /upload-document

POST /approve-transaction

These operations represent business intent rather than data retrieval. REST communicates that intent more clearly through HTTP semantics.

Protocol and Architectural Difference

REST is built directly on HTTP methods and resource-based URLs. Each endpoint represents a specific resource or operation, and caching is naturally supported at the HTTP layer.

GraphQL typically exposes a single endpoint:

POST /graphql

The complexity moves into the query layer. This flexibility allows precise data fetching but introduces challenges in caching, monitoring, and query optimization.

When GraphQL Is Worth It

GraphQL becomes valuable in systems where data is highly connected and frontend requirements change frequently. This includes dashboards, analytics platforms, GIS systems, social applications, and mobile apps that require aggregated data from multiple sources.

REST remains stronger in systems that are workflow-driven, transactional, and action-oriented.

Finally,

After working with both approaches, the conclusion is not that one replaces the other. It is that they solve different categories of problems. REST is better suited for business operations and system workflows. GraphQL is better suited for flexible data retrieval in highly relational systems.In most real-world architectures, the right answer is not choosing one over the other, but understanding where each one fits and combining them intentionally.

What’s your opinion? Let me know in the comments below, give a good read, like and share.

The Bilingual Developer: Python and Go Conditionals

Ezeana Micheal — Fri, 05 Jun 2026 16:09:06 +0000

So far, we've talked about how data is stored in memory and the different data types available in Python and Go. Storing data is only part of programming. At some point, our programs need to make decisions.

When thinking about real-world applications, you can think:

Should a user be allowed to log in?
Is a student eligible for admission?
Has a customer completed payment?
Should an email notification be sent?

In all these situations, the program needs to decide what action to take based on certain conditions. This is where conditionals come in. Conditionals allow a program to make decisions based on whether a condition is true or false.

Although Python and Go solve the same problem, they approach conditionals in slightly different ways. In this article, we’ll explore both.

The Syntax Shift: How Python and Go Define Code Blocks

One of the first things you'll notice when writing conditionals in Python and Go is that they define code blocks differently.

In Python, Indentation Matters

Python uses a combination of colons (:) and indentation to indicate which code belongs to a condition.

age = 18  
if age >= 18:  
    print("You are an adult")

Notice two things:

The condition ends with a colon (:).
The code inside the condition is indented.

The indentation is not optional.

For example:

age = 18  
if age >= 18:  
print("You are an adult")

This produces an error because Python relies on indentation to understand the structure of your program. Python's philosophy here is simple:

Code should be readable and visually organized.

By forcing indentation, Python ensures that developers write code in a consistent format.

In Go, Curly Braces Define Structure

Go takes a different route. Instead of indentation, it uses curly braces {} to define blocks of code.

age := 18  
if age >= 18 {  
    fmt.Println("You are an adult")  
}

The braces tell Go exactly where the conditional block starts and ends. Even if you change the spacing or indentation, Go still understands the structure because the braces define it. One important thing to note is that Go does not require parentheses around conditions.

if age >= 18 {  
    fmt.Println("Adult")  
}

Not:

if (age >= 18) {  
    fmt.Println("Adult")  
}

While the second style is common in some languages, Go intentionally keeps the syntax cleaner.

If/Else Chains

A single condition is useful, but real applications often need multiple possible outcomes.

For example:

A score above 70 is an A.
A score above 60 is a B.
A score above 50 is a C.
Anything lower is a fail.

This is where if/else chains become useful.

Python's elif

Python introduces the elif keyword, which stands for "else if."

score = 75  
if score >= 70:  
    print("Grade A")  
elif score >= 60:  
    print("Grade B")  
elif score >= 50:  
    print("Grade C")  
else:  
    print("Fail")

The program checks each condition from top to bottom. As soon as one condition evaluates to True, Python executes that block and skips the rest. This keeps the code concise and easy to read.

Go's else if

Go achieves the same thing using else if.

score := 75

if score >= 70 {  
    fmt.Println("Grade A")  
} else if score >= 60 {  
    fmt.Println("Grade B")  
} else if score >= 50 {  
    fmt.Println("Grade C")  
} else {  
    fmt.Println("Fail")  
}

Functionally, this behaves exactly like Python's elif. The main difference is syntax. Python creates a special keyword (elif). Go combines two existing keywords (else if).

Quick Comparison

Python	Go
if	if
elif	else if
else	else
Uses indentation	Uses braces

Pattern Matching and Multi-Way Decisions

Sometimes an application needs to compare a value against many possible options. Imagine you're building a system that handles user roles:

Admin
Staff
Student
Guest

Using multiple if statements can become messy. Both Python and Go provide a cleaner solution, but they do it differently.

Python's match/case

Starting from Python 3.10, Python introduced match/case.

role = "Admin"  
match role:  
    case "Admin":  
        print("Full access")  
    case "Staff":  
        print("Limited access")  
    case "Student":  
        print("Student access")  
    case _:  
        print("Guest access")

Think of match as saying:

"Compare this value against several patterns and execute the matching block."

The underscore (_) acts as a default case. One reason match/case is powerful is that it can do more than simple value comparisons.

It can match:

Values
Lists
Tuples
Object structures
Complex patterns

This makes it much more powerful than traditional switch statements found in many languages.

Go's switch Statement

Go uses switch.

role := "Admin"  
switch role {  
case "Admin":  
    fmt.Println("Full access")  
case "Staff":  
    fmt.Println("Limited access")  
case "Student":  
    fmt.Println("Student access")  
default:  
    fmt.Println("Guest access")  
}

At first glance, this looks similar to Python's match/case. However, Go's switch statement has a few interesting capabilities.

Switch Without an Expression

One unique feature of Go is that a switch can be used without directly switching on a variable.

score := 75  
switch {  
case score >= 70:  
    fmt.Println("Grade A")  
case score >= 60:  
    fmt.Println("Grade B")  
default:  
    fmt.Println("Fail")  
}

This behaves almost like an organized replacement for a long if/else if chain.

Multiple Values in a Case

Go also allows multiple matching values.

day := "Saturday"  
switch day {  
case "Saturday", "Sunday":  
    fmt.Println("Weekend")  
default:  
    fmt.Println("Weekday")  
}

This can make decision logic much cleaner.

Conclusion: Python's Angle vs Go's Angle

Python's Angle

Python focuses on readability and expressiveness.

Indentation clearly shows structure.
elif makes multi-condition chains easy to read.
match/case supports powerful pattern matching.
The language tries to make decision logic feel natural and close to plain English.

Go's Angle

Go focuses on simplicity and predictability.

Curly braces explicitly define blocks.
else if keeps the language small by reusing existing keywords.
The switch is versatile enough to replace many if/else chains.
The language avoids adding too many specialized features.

Thanks for reading. Hope you learned something new. Read, like and comment, thanks.

7 REST API Mistakes I Made as a Junior Developer

Ezeana Micheal — Tue, 02 Jun 2026 16:27:15 +0000

REST APIs are one way applications exchange information, especially between the client and server sides of modern systems. APIs are created on the server and consumed by web, mobile, or desktop clients.

When I started my career as a junior developer, I built several APIs that worked, but I learned lessons through experience. My APIs were not always designed with scalability, maintainability, or even best practices in mind. As I gained more experience, I discovered some mistakes that I repeatedly made and learned how to correct them.

Here are seven REST API mistakes I made as a junior developer and the lessons I learned from them.

1. Not Versioning My APIs Early

One of the biggest mistakes I made was launching APIs without versioning them from the start. At first, this seemed fine because there was only one client consuming the API. However, as the requirements changed, introducing breaking changes became difficult because existing clients depended on the old structure.

What I Learned is this:

Always version your APIs from day one, even if you don't think you'll need multiple versions.

For Example:

/api/v1/users
/api/v1/orders

Versioning helps to give you the flexibility to evolve your API without breaking existing consumers.

2. Overloading GET Endpoints

I used to create GET endpoints that returned every piece of information about a resource, including large nested objects and related records. This often resulted in slow responses and unnecessary data transfer.

What I Learned is this:

Not every endpoint needs to return full details. It's perfectly acceptable to have(For Example):

GET /users

To return a summarized view:

{  
  "id": 1,  
  "name": "John Doe",  
  "email": "john@example.com"  
}

And then use:

GET /users/1

To return complete information about the user. This approach improves performance and reduces payload sizes.

3. Exposing My Database Structure Directly

Early in my career, I mapped database tables directly to API responses. As a result, clients became tightly coupled to the database design.

Bad Example:

{  
  "tbl_user_id": 1,  
  "tbl_user_fname": "John"  
}

What I Learned is this:

An API should represent business resources, not database tables. A cleaner response would be:

{  
  "id": 1,  
  "first_name": "John"  
}

This gives us the freedom to modify our database without affecting API consumers.

4. Not Implementing Pagination Early

One mistake I made was returning entire datasets from the API. This worked fine during development when there were only a few records, but it quickly became a performance issue as the application grew.

What I Learned is this:

Large datasets should be paginated from the beginning. Instead of:

GET /users

Returning thousands of records, use pagination:

GET /users?page=1&limit=20

Pagination improves performance, reduces bandwidth usage, and provides a better experience for API consumers.

5. Not Thinking About Authentication and Authorization Early

As a junior developer, I focused heavily on making endpoints work and sometimes overlooked who should be allowed to access them.

What I Learned is this:

Authentication and authorization should be part of the API design process from the start.

Ask questions such as:

Who can access this endpoint?
Should this action require login?
Are there admin-only operations?
What happens if an unauthorized user makes a request?

Implementing proper access control early helps prevent security issues during development and future refactoring.

6. Not Standardizing Error Responses

In some projects, every endpoint returned errors differently. One endpoint might return a message, another might return a list of errors, while another might return a completely different structure.

What I Learned is this:

Error responses should follow a consistent format throughout the API.

For example:

{

  "success": false,
  "message": "User not found",
  "error_code": "USER_NOT_FOUND"
}

A standardized error structure makes debugging easier and allows frontend developers to handle errors consistently across the application.

7. Skipping Documentation

As a junior developer, I often assumed that my API endpoints were self-explanatory. They weren't. Even I sometimes forgot how certain endpoints worked after a few weeks.

What I Learned is this:

Good documentation saves time for both API consumers(Frontend developers and others) and future maintainers.

Document:

Endpoint URLs
Request methods
Request parameters
Authentication requirements
Response examples
Error responses

Clear documentation reduces misunderstandings and speeds up integration efforts.

Conclusion

Building APIs that simply work is relatively easy. Building APIs that are maintainable, scalable, and pleasant for other developers to consume requires more thought and experience.

Looking back, these mistakes taught me valuable lessons about API design. Today, whenever I create a new REST API, I focus on versioning early, keeping responses consistent, using proper HTTP methods, avoiding database leakage, and designing endpoints with long-term maintainability in mind.

The best API designs are often the simplest ones: predictable, well-documented, and easy for other developers to understand. Thanks for going through my article. Please leave a like and comment. Thanks.

The Bilingual Developer: Python and Go Primitive Data Types

Ezeana Micheal — Fri, 29 May 2026 15:50:56 +0000

As discussed in the previous article on the variables about the need of programming languages to store information. This article will be about how the different data is stored. Let’s slow it down a bit and really think about it. If storage is where data lives… then data types are basically how that data is shaped inside memory. And depending on the language you’re using, that “shape” changes a lot. Primitive data types are the most basic building blocks used to represent values inside a program.

When learning both Python and Go, understanding their primitive data types is one of the fastest ways to understand the design philosophy behind each language.

Understanding Primitive Data Types

Primitive data types are the simplest forms of data a programming language can handle directly. They represent single values such as:

Text
Numbers
Boolean values (true or false)
Fixed constant values

Text and Characters

Strings in Python

In Python, text is represented using the str data type. A string, simply put, is a sequence of characters enclosed in quotation marks.

name = "Michael"  
message = 'Hello World'

Python treats strings as Unicode by default, meaning they can store characters from different languages and symbols.

emoji = "😊"  
language = "Python"

One of Python’s strengths is how simple string manipulation feels.

first_word = "Go"  
last_word = "Python"

full_word = first_word + " " + last_word

print(full_word)

Output:

Go Python

Python does not have a separate character (char) data type. A single character is simply considered a string of length one.

letter = "A"
print(type(letter))

Output:

<class 'str'>

This design keeps the language simpler because developers only need to think about one text type instead of multiple character-based types.

Strings and Runes in Go

Go also uses strings for textual data.

package main

import "fmt"

func main() {  
    name := "Michael"  
    fmt.Println(name)  
}

But Go handles characters differently from Python.

In Go:

A string represents a sequence of bytes.
A rune represents a single Unicode character.

A rune is actually an alias for int32.

var letter rune = 'A'

Notice something important:

Strings use double quotes " "
Runes use single quotes ' '

This distinction is very important in Go.

package main
import "fmt"

func main() {  
    var character rune = 'G'

    fmt.Println(character)  
}

Output:

The output is numeric because Go stores runes internally using Unicode code points.

To print the actual character:

fmt.Printf("%cn", character)

Output:

Go’s approach gives developers more control over memory and encoding behavior, especially for systems programming and high-performance applications.

Numbers

Numbers are another core primitive data type.

Both Python and Go support:

Integers
Floating-point numbers

Integers and Floats in Python

Python makes numeric programming simple.

age = 25  
price = 19.99

Python automatically determines the type.

print(type(age))  
print(type(price))

Output:

<class 'int'>  
<class 'float'>

One important feature of Python is that integers can grow very large automatically.

big_number = 999999999999999999999999999999

Python dynamically allocates memory for large integers behind the scenes.

This flexibility is convenient because developers rarely worry about integer overflow or memory size during basic programming.

Integers and Floats in Go

Go is stricter and more explicit.

var age int = 25

var price float64 = 19.99

Go supports multiple integer sizes:

int8
int16
int32
int64

And floating-point types:

float32
float64

Example:

var smallNumber int8 = 100  
var largeNumber int64 = 9000000000

This explicit sizing is important because each type uses a specific amount of memory.

Type	Size
int8	8 bits
int16	16 bits
int32	32 bits
int64	64 bits

Go forces developers to think more carefully about memory usage and performance.

For example:

var x int32 = 10  
var y int64 = 20

// This causes an error  
// fmt.Println(x + y)

Go does not automatically mix different integer sizes. Developers must explicitly convert types.

fmt.Println(int64(x) + y)

This strictness reduces accidental bugs and improves predictability in large systems.

Booleans

Booleans represent logical truth values.

They are heavily used in:

Conditions
Comparisons
Decision-making statements

Booleans in Python

Python uses:

True and False

Notice the capitalization.

is_logged_in = True  
is_admin = False

Example:

age = 20  
if age >= 18:  
    print(True)

Output:

True

Python’s boolean system is highly flexible because many values can behave as truthy or falsy.

Examples of falsy values:

0

None

""

[]

False

Everything else is generally considered truthy.

Booleans in Go

Go also supports boolean values, but with stricter rules(as usual).

var isLoggedIn bool = true  
var isAdmin bool = false

Notice the lowercase keywords:

true and false

Go does not allow non-boolean values in conditional statements.

This is invalid:

var number int = 1

if number {  
    fmt.Println("Hello")  
}

Python allows similar truthy checks, but Go requires an actual boolean expression.

Correct Go example:

if number == 1 {  
    fmt.Println("Hello")  
}

This design improves clarity and reduces ambiguity.

Constants

Constants are values that should never change during program execution.

Constants in Python

Python does not have a true constant keyword. Instead, developers follow a naming convention using uppercase variable names.

PI = 3.14159  
MAX_USERS = 100

However, Python does not enforce immutability.

PI = 10

This still works. The uppercase naming style simply communicates intent to other developers. Python relies heavily on developer discipline and readability conventions.

Constants in Go

Go provides an actual const keyword.

const Pi = 3.14159  
const MaxUsers = 100

Once declared, constants cannot be modified.

const Age = 20

// Error  
// Age = 30

This enforcement makes programs safer and more predictable. Go constants can also exist without explicitly specifying a type.

const Name = "GoLang"

The compiler determines the appropriate type automatically.

Conclusion

In Python, primitive types are designed to feel natural and easy to use. Developers can move quickly without worrying much about memory sizes or strict typing rules.

In Go, primitive types are more structured and explicit. Developers are expected to think carefully about memory, type safety, and predictability.

Comment , Share and Like, thanks for reading.

The N+1 Query That Killed Our Database, And How I Fixed It

Ezeana Micheal — Mon, 25 May 2026 17:39:38 +0000

Everything Worked…But Not Well

APIs are affected by the way data is retrieved from the database, and that's something that affected a recent teammate and me during development. In our regular development process, during review and maintenance, the APIs worked, responses came back well, no visible errors. But during this process, we noticed that things started to slow down. Endpoints that used to respond fast suddenly began taking longer, CPU usage on the database increased, and retrieval speed became terrible under load.

At first, we thought:

Maybe the server wasn't powerful enough
Maybe network latency was the issue
Maybe too many requests were hitting the API

But the real issue was hiding inside our database queries.

What Actually Is The N+1 Query Problem?

The N+1 query problem is one of the most common performance issues in backend development, especially when working with relational databases and ORMs(as I, a fan of Django, do). I’m gonna explain this more in SQL terms using retrieval speed and database load.

The problem happens when your application performs:

1 query to retrieve parent records
Then N extra queries to retrieve related child records

So instead of making one optimized query, the application keeps asking the database more questions repeatedly. This increases the query count, read time, database load, and the API response time. 1 issue, several systems affected.

A Simple Example

Let's say we have 2 tables:

Users
Orders

We first retrieve all users.

SELECT * FROM users;

Now imagine there are 100 users. Then, for every user retrieved, another query runs to fetch their orders.

SELECT * FROM orders WHERE user_id = 1;  
SELECT * FROM orders WHERE user_id = 2;  
SELECT * FROM orders WHERE user_id = 3;

And it keeps going. So instead of 1 query, you now have 101 queries. That extra load destroys retrieval speed.

Why This Problem Is Dangerous

The dangerous part is that during development, you might not even notice it. If your database only has just about 5 users and 10 orders, Everything still feels fast.

But once production data grows:

Hundreds of users
Thousands of records
More API requests

The database starts struggling badly. This is why some APIs feel fast during testing but start to slow down after deployment.

The Mistake We Made

The issue wasnt obvious at first because the code itself looked completely normal. We had an endpoint that needed to return users alongside their related orders.

Something like:

User information
Their recent orders
Order counts
Related details

The endpoint worked perfectly during development. But internally, Django was fetching related records separately for every user being serialized. Which meant the API kept hitting the database repeatedly behind the scenes.

The code looked clean.

users = User.objects.all()

serializer = UserSerializer(users, many=True)

But in the serializer, related order data was being accessed for every single user.

class UserSerializer(serializers.ModelSerializer):

    orders = OrderSerializer(many=True)

    class Meta:

        model = User

        fields = ['id', 'name', 'orders']

This is where the real problem started. When Django tried to serialize the response, it kept querying orders separately per user. So if there were 500 users, the system would do:

1 query to retrieve users
Hundreds of additional queries to retrieve orders

That is the N+1 query problem. The scary part is that nothing looked wrong from the surface. The endpoint returned the correct data and no errors, just slow performance. And as traffic increased, the database load became worse. It was slow because the application kept repeatedly asking for related data instead of retrieving it efficiently.

The fix was adding query optimization directly to the queryset.

users = User.objects.prefetch_related('orders')

serializer = UserSerializer(users, many=True)

That single optimization drastically reduced the number of database hits. Instead of querying orders repeatedly for every user, Django retrieved them efficiently in bulk. Same endpoint and response, much better performance.

Understanding `select_related()`

One major fix for this problem in Django is:

select_related()

select_related() is used for relationships like:

ForeignKey
OneToOneField

What it basically does is perform a SQL JOIN and retrieve related data in a single query. Instead of this:

users = User.objects.all()

for user in users:  
    print(user.profile.phone)

Which may generate multiple queries…

You do this:

users = User.objects.select_related('profile')  
for user in users:  
    print(user.profile.phone)

Now Django joins the tables together and retrieves everything at once.

So instead of:

1 query for users
Multiple queries for profiles

You now get:

1 optimized query

Much faster and cleaner.

Understanding `prefetch_related()`

Another optimization is:

prefetch_related()

This is used mostly for:

ManyToMany relationships
Reverse ForeignKey relationships

Unlike select_related(), this does not use SQL JOINs directly. Instead, Django performs separate queries but combines the results efficiently in memory.

For example:

users = User.objects.prefetch_related('orders')

Django may run:

SELECT * FROM users;  
SELECT * FROM orders WHERE user_id IN (1,2,3,4...);

Instead of:

SELECT * FROM orders WHERE user_id = 1;  
SELECT * FROM orders WHERE user_id = 2;  
SELECT * FROM orders WHERE user_id = 3;

Which is far more efficient. So rather than hundreds of queries, you may only have two.

The Difference Between `select_related()` And `prefetch_related()`

`select_related()`

Uses SQL JOINs
Best for ForeignKey and OneToOne relationships
Retrieves related data in a single query

`prefetch_related()`

Uses multiple optimized queries
Combines data in Python memory
Best for ManyToMany and reverse relationships

Both solve the same problem differently.

The Result

After fixing the queries:

Response times dropped massively
Database load reduced
API became stable again
Retrieval speed improved significantly

The funny thing is that we didnt upgrade the server. We didnt increase RAM. We didnt change infrastructure. We simply reduced unnecessary queries.

What This Experience Taught Me

One thing this experience taught me is that backend performance is not always about server power. Sometimes your database is suffering simply because of how you are querying it. A badly written retrieval pattern can quietly destroy performance even when your infrastructure is good. Now whenever I build endpoints, I dont just ask “Does this work?” I also ask “How many queries is this generating behind the scenes?” Because sometimes the biggest backend problem is not the logic. Its the retrieval pattern hiding underneath it. Let me know what you think, thanks for reading, like, share, comment and follow for more.

How I Cut API Response Time from 2s to <100ms with Redis Caching

Ezeana Micheal — Fri, 22 May 2026 15:09:42 +0000

Early in my software development years, I had the opportunity to work with a company where I learned backend development. I worked on a system where I was responsible for building the APIs without senior guidance, just documentation, experimentation, and a lot of self-learning.

When learning to design DB models and RESTful APIs. That was it for me, connect everything and let it out via the get request, let it in via the post request, patch things up with the patch request, and delete via the delete request.

Basic crud operations, and I was fine with that, back then. Eventually, I decided to explore the site myself, and damn, it was slow.

Every interaction came with a noticeable delay. So I stopped assuming things were fine and tested the APIs properly. Using Postman, I measured response times. Most endpoints were taking over 5 seconds.

The Problem

Every request was hitting the database directly, even when requesting the same data repeatedly.

The system wasn’t slow because the database was bad.

It was slow because it was doing the same work over and over again.

What Changed?

I did some research, investigations, and found something powerful. Caching, and utilizing redis for it.

What is Caching?

Caching stores frequently accessed data in memory (Redis uses RAM), allowing much faster retrieval compared to querying a database repeatedly. It reduces database load, instead of hitting the database every time it hits the cache instead and returns the result.

Types of Caching (and Why Redis Fits Here)

Not all caching works the same way. In my case, I implemented application-level caching with Redis, but it helps to understand where it sits in the bigger picture.

1. Application-Level Caching

This is what I used. The application stores frequently accessed data in a fast in-memory store like Redis.

Instead of always asking the database:

API → Database → Response

We first check:

API → Redis → Database (only if needed)

This is the most common approach in backend systems because it gives full control over what gets cached and when it gets updated.

2. Database Caching

Some databases internally cache query results or use external layers to store repeated query outputs.

This reduces repeated expensive queries, but it is less flexible compared to Redis-based caching where you control the logic directly inside your API.

3. Distributed Caching

This is when caching is shared across multiple servers using systems like Redis Cluster or Memcached.

It becomes important when your application is no longer running on a single server, but across multiple services or microservices.

Therefore,

Before:

Client → API → DB (every request)

After:

Client → API → Redis → DB (only on cache miss)

Instead of querying the database every time, the API now checks Redis first. If the data exists, it returns immediately. If not, it fetches from the database, stores the result in Redis, and returns it.

Here was my initial API response time without caching,

Here was my API response time afterwards.

I implemented 2 main strategies.

Key-value Caching.
Cache invalidation via Write.

In my API I implemented key value caching for every get request i.e (get /books/ and get /books/:id)

Eliminating First-Request Slowness (Cache Warm-Up)

One downside of caching is the initial delay when the cache is empty.

How did I solve that? a script.

I added a cache warm-up script that runs on deployment and preloads frequently accessed data into Redis. That way, the system starts “warm,” and users don’t experience the initial latency.

At that point, the only time the system feels slow is immediately after cache invalidation.

But having a cache isn't all good if not invalidated well, because write data comes in too, through post , patch, put. So a cache invalidation strategy was needed.

I chose cache invalidation via Write for 2 reasons:

Data will be refreshed once a put, patch, post or delete request comes in, and
Data is not often changed regularly, the data stays for a while because of the type of application we’re dealing with so giving it a time to live and time to die feels too much.

Trade-offs

Every system has tradeoffs as there is no perfect system. The following were the tradeoffs of my decision.

First request after invalidation is slower
Cache keys must be managed carefully
Slight increase in system complexity

But the system is now significantly faster and more efficient.

PS: There are several optimization techniques in backend development, this article is just about caching.

Thanks for reading, what do you think about the approach? Read, like and comment.

The Bilingual Developer: Python and Go Variables

Ezeana Micheal — Fri, 22 May 2026 14:59:35 +0000

At the heart of programming is a simple idea:

Input -> Processing -> Output

But between input and processing lies something more important, storage.

Before a computer can do anything useful with data, it must first store it somewhere. That “somewhere” is memory. And in programming, the way we interact with memory starts with one core concept:

Variables

Programming is just a way of communicating with a computer, telling it what to store, how to transform it, and what to return.

In this article, we’ll explore how two very different languages, Python and Go, handle the same idea: variables.

Variables: The First Mental Model

A variable is simply a named storage location in memory.

For example (What it does is):

“store the number 10”
“label it as x”
“retrieve it later when needed”

Simple concept, but different languages implement it very differently.

And that’s where Python and Go start to diverge.

Python vs Go: Two Different Philosophies

Python and Go both allow you to store data in variables, but they were designed with different priorities:

Python: flexibility and speed of writing code
Go: structure, safety, and predictability

This difference shows up immediately in how variables are declared.

Dynamic vs Static Typing

Python (Dynamic Typing)

In Python, you don’t explicitly declare the type of a variable:

x=10

Python automatically figures out the datatype at runtime.

This is called dynamic typing.

It gives you flexibility:

You can reuse variables freely
You don’t need to define types upfront
It speeds up development

But the trade-off is that errors may only show up when the program runs.

Go (Static Typing)

In Go, you must define the type explicitly:

var x int = 10

Once declared, the type cannot change.

So this is invalid:

x = "hello" // error

This is called static typing.

It forces structure:

Types are known before execution
Errors are caught early (at compile time)
Code is more predictable in large systems

Two Ways of Declaring Variables

Python keeps it simple:

x = 10

That’s it. One way, one rule.

Go gives you two main approaches:

Explicit Declaration

var x int = 10

### Short Declaration (Walrus-style feel)

x := 10

The := operator tells Go:

“Infer the type automatically, but still lock it in permanently.”

So Go gives you convenience — but never sacrifices structure.

The Concept of “Nothing”

Another major difference is how both languages handle empty or uninitialized values.

Python: `None`

In Python, “no value” is represented explicitly:

x = None

This means:

“This variable exists, but it currently holds nothing.”

It is very explicit and readable.

Go: Zero Values

Go does something different.

If you declare a variable but don’t assign a value, Go automatically gives it a default:

var x int
fmt.Println(x) // 0

So instead of null or None, Go uses zero values:

int → 0
string → ""
bool → false

This design avoids uninitialized variables entirely.

While python thinks: “Let me give you freedom and decide later.” Go thinks: “Let me force clarity so you don’t make mistakes later.”

Even something as simple as variables reveals deep design philosophies:

Python prioritizes developer speed and flexibility
Go prioritizes safety and predictability

Both are correct, just optimized for different worlds:

Python → scripting, AI, automation, rapid development
Go → backend systems, scalability, performance-critical services.

Thanks for reading, what do you think about this? Read, like and comment.

The Bilingual Developer: Learning Python & Go Side-by-Side

Ezeana Micheal — Fri, 15 May 2026 16:50:43 +0000

There are several programming languages and specialized fields today. Navigating the mountain of guides out there can be tricky; some lead you straight into "tutorial hell," while others actually help you gain a solid footing. Python and Go are two of the most popular choices in modern development, different in their own ways, each have their strengths.

I, you, and many others have gone through a tutorial to learn a language one at a time, so I thought of trying something different: Dual-Language Learning. The advantage here is that it gives you two sides of a concept, forcing you to actually understand the underlying mechanisms rather than just memorizing syntax.

Why Python and Go?

Python is a dynamically typed language, which means you can write code, iterate, and test ideas without getting held down in some boilerplate or strict type declarations. It is used for LLM engineering, machine learning, and rapid backend development. Its real power isn't in raw execution speed (it can be slow compared to others), but developer writing speed gives it an edge; it's simpler to write than some other languages. Python serves as the ultimate "glue" language; you write clean, readable code, while the heavy computational lifting is delegated to blazing-fast C++ and Rust kernels under the hood. With industry-standard libraries like PyTorch, Hugging Face, and FastAPI, Python provides the fastest possible path from a raw AI idea to a deployed prototype.

Go (or Golang), developed by Google, is a statically typed language, and the one word I'll use to describe it is speed. It is the industry standard for backend infrastructure, cloud-native tooling (like Docker and Kubernetes), and high-performance microservices, making it a powerhouse for things like high-throughput fintech platforms. While Python historically utilized a Global Interpreter Lock (GIL) that prevented it from running operations concurrently at maximum efficiency, Go handles massive concurrency natively. Through "goroutines," it is blazingly fast at computing simultaneous tasks, allowing it to scale effortlessly across multiple cores.

The 2026 Landscape

Python 3.14: This release officially supports free-threaded Python (allowing you to disable the GIL for true multithreading) and introduces an experimental JIT (Just-In-Time) compiler. It also makes deferred evaluation of type annotations the default, which significantly speeds up startup times.
Go 1.26: The latest release makes the highly efficient Green Tea garbage collector the default (reducing runtime overhead by up to about 40%) and introduces syntax quality-of-life updates, like allowing expressions directly inside the new() function for cleaner pointer creation.

Core Differences

Before learning both languages, you first need to understand how they “think” differently:

How They Run

Python runs your code line by line while the program is executing. This makes it flexible, easy to test quickly, and great for fast development.

Go converts your code into a standalone executable file before it runs. Because of this, Go programs are usually much faster and more efficient.

How Programs Start

In Python, you can usually just write code from top to bottom and run the file.

In Go, every runnable program must follow a fixed structure. You need:

a package main
and a func main() function

That main() function is where the program officially starts running.

Code Style and Formatting

Python gives developers more freedom in how they write and organize code. There are style guides and formatting tools people commonly use, but they are mostly optional.

Go is much stricter. It comes with its own formatting tool called gofmt, and almost every Go developer uses it. This means most Go code looks very similar, making projects easier to read and maintain across teams.

Over the next few weeks, I’ll be writing about Python and Go concepts, sharing code, and seeing what we can learn by comparing them side-by-side. I’d appreciate the support, so let me know what you feel or think about it.

Let's Go Python!

Auth in 2026: What Actually Matters Now

Ezeana Micheal — Mon, 11 May 2026 15:14:47 +0000

With the speed at which Generative AI is being used to build applications, knowing how to code isn't the complete way anymore; understanding what to code is. What is needed? Why is it needed? and more. I’ve decided to take some level of these concepts and explain them to the best of my abilities. Starting with backend development. First, let's understand authentication and authorization concepts.

Authentication is the process of confirming a user’s identity. Basically, it answers “Who is your user?”

Authorization is the process of confirming what a user can do. Basically, it answers “What can your user do?”

In this article, I’ll write about different authentication and authorization methods, what instances they’re used in, and how they work.

But first, we can’t talk about auths without mentioning passwords. Passwords are the most basic authentication method. But it is important to note, NEVER store passwords in plain text. It's the worst mistake any backend developer would make. The idea is to hash the passwords and verify the hash. There are many ways to hash a passwords, but here are 2 to avoid.

MD5
SHA-256

Why avoid them?

These general-purpose hash functions are designed to be fast, and an attacker with a modern GPU can compute millions of SHA-256 per second, making attacks computationally cheap, so when selecting hashing algorithms for passwords, they have to be deliberately expensive or slow. The 2 widely used are Bcrypt and Argon2. Both are designed to be slow and computationally expensive, making it harder for attackers to decipher them through brute-force attacks.

Bcrypt was designed in 1999; it is based on the Blowfish cipher and uses a salt to protect against rainbow table attacks. It also incorporates a cost factor that quantifies the hash's computational cost. The cost doubles with each increment, i.e., cost 10 is twice as expensive or hard as cost 9 was.

Argon2 was introduced in 2015 as the winner of the Password Hashing Competition. The edge it has over bcrypt is that it has resistance to side-channel attacks. You can read more on it later.

We will consider the following authentication methods:

JWT Authentication
Session-Based Authentication
OpenID Connect Authentication
MFA (Multi-Factor Authentication)
SSO (Single Sign-On)
Passkeys / WebAuthn (FIDO2)
API keys

And the following authorization methods:

OAuth 2.0
RBAC(Role-Based Access Control)
ABAC(Attribute-Based Access Control)

Starting with authentication,

JWT Authentication

Json Web Token(JWT) is a compact, URL-safe token that encodes a set of claims (key-value pairs) and is cryptographically signed. A unique feature is that JWTs enable stateless authentication; the signature is verifiable without a database lookup. The server can validate the token with just the secret key.

A JWT has 3 Base64URL-encoded parts separated by dots: Header, Payload, and Signature.

a. Header contains the algorithm and the type e.g

{ "alg": "HS256", "typ": "JWT" }

b. Payload contains the encoded claims, e.g

{

"sub": "user_id_123",

 "email": "mike@synoloop.com",

 "role": "admin",

 "iat": 1716000000,    // issued at (Unix timestamp)

 "exp": 1716003600     // expires at (1 hour later)

}

c. The signature is the encrypted base64url header and payload with the secret.

In real-world authentication systems, JWTs are most commonly used in two forms: Access tokens and refresh tokens.

Access tokens are short-lived, between 5 and 15 minutes. Refresh tokens, on the other hand, are long-lived from days to even weeks and are used to obtain new access tokens without reauthenticating (depending on the developer).

But what happens if a token is stolen or a user logs out of the system? Since JWTs are stateless and valid until they expire, we need a way to invalidate them before their natural expiration. This is where token blacklisting comes in.

This is solved by maintaining a server-side denylist. Once any of the above events happen, the JWTID is added to the blacklist.

So on logout or password change or compromise, it's best to revoke or blacklist all existing refresh tokens. This logs out the user on all sessions. On each request, the server looks up the session ID, retrieves the session data, and authenticates the user.

Session-Based Authentication

Session-based authentication stores the auth state on the server, so when a user logs in, it creates a session record and stores it. What makes Sessions different from JWTs is that Sessions are easier to revoke immediately, but require server-side storage. JWTs are stateless but harder to invalidate before expiry.

In sessions, it's best to always regenerate the session ID after login to prevent session fixation attacks.

OpenID Connect (OIDC) Authentication

OIDC is an identity layer built on top of OAuth 2.0(Will be discussed in authorization). OIDC answers who this user is. It adds a standardized ID token(a JWT) containing identity claims.

Think of this as when you use any web application that has a “continue with Google”; this sends your name, email, phone (and other details if requested) from Google to the web application authorized, answering who you are.

It gives the addition of what an OAuth 2.0 gives.

ID Token: a JWT containing user identity (sub, email, name, picture, etc.)
UserInfo Endpoint: returns additional claims about the authenticated user
Discovery Document: /.well-known/openid-configuration for automatic configuration
Standard Claims: sub (subject/user ID), email, email_verified, name, picture

MFA( Multi-Factor Authentication)

Multi-factor authentication requires users to have two or more verification factors present: something they know (password), something they have (phone/hardware key), and something they are (biometric).

Multi-factor authentication includes methods like TOTP and Backup Codes.

TOTP(Time-Based One-Time Passwords), generates a 6-digit code that changes every 30 seconds based on a shared secret and the current time. It works with apps like Google Authenticator, Microsoft Authenticator, and such.
Backup Codes: These are a list of 8 to 10 single-use random codes that can be used to retrieve the account or authenticate.

SSO(Single Sign-On)

Single Sign-On allows users to authenticate once and gain access to multiple systems. This is mostly used in enterprise environments or applications; the 2 main protocols are SAML 2.0 (XML-based, older) and OIDC-based SSO (modern, JSON/JWT-based).

SAML is the standard in enterprise environments (corporate identity providers like Okta and Azure). It uses XML assertions to tell the identity. The identity provider (IdP) authenticates the user and sends a signed XML assertion to the service provider (SP).

Service Provider (SP) is your application
Identity Provider (IdP) is Okta, Azure, Google Workspace, etc.
An assertion is a signed XML document asserting identity and attributes.

Passkeys / WebAuthn (FIDO2)

Passkeys are an advanced form of authentication: passwordless, phishing-resistant, and cryptographically strong. Based on the WebAuthn standard (W3C) and FIDO2 protocol, they use public-key cryptography with biometrics or device PINs.

Passkeys have become popular since their release in 2018. They work in 2 major steps:

Registration: The browser or the device generates a public/private key pair. Private key stays on the device. The public key is sent to your server.
Authentication: Server sends a challenge. The device signs the challenge with the private key. The server verifies with the stored public key.

No Password is ever transmitted or stored, and attackers can’t do anything with just the public key.

API keys

I chose to keep API keys under authentication, but underneath, they do both authentication and authorization; I’ll explain.

API keys are Opaque tokens issued for programmatic access to services, scripts or public-facing APIs.They should be scoped, rotatable, and auditable.

API keys act like a username and password pair, but simplified. They identify the calling application or developer. For example, A weather API requires an API key to ensure only registered apps can access data.

While some APIs use keys with scoped permissions (e.g., read-only or read and write).

Example: A developer can generate API keys in a payment app and may allow one key to process transactions but another only to view reports.

Some design principles of API keys include:

Including a prefix for easy identification (e.g., sk_live_, sk_test_, syno_)
Generate with cryptographically secure randomness (at least 128 bits)
Store only the hash in your database, treat keys like passwords
Support scopes/permissions per key
Log all usage with timestamps for auditing
Support rotation: allow multiple active keys per user, then invalidate old ones

Now, let's consider the authorization concepts:

OAuth 2.0

This is an authorization framework that allows a third-party application to obtain limited access to a service on a user's behalf without exposing credentials. You can think of this as “connect to GitHub” or authorizing Google Drive access via a “connect to Google.” It's about what you can access, not about who you are.

RBAC(Role-Based Access Control)

RBAC Controls access by assigning permissions to roles, and roles to users. This is most common in authorization models for web applications. User has a role, and the role has permissions. For example, in an e-commerce application. There are key roles like Admin, Vendor, and User. Each of these roles has different permissions. Admin can read all users and vendors, edit or verify, or ban a vendor. The vendor can upload products, the user can read and purchase products.

ABAC(Attribute-Based Access Control)

ABAC is another authorization method. It evaluates attributes of the user, the resource, the action, and the environment to make an authorization decision. For example, consider that a manager can edit a document only if they are in the same department as the document's owner, during business hours. We can see that many conditions affect the action that can be carried out by the manager.

When to Use ABAC vs RBAC

Use RBAC when access rules map cleanly to roles and don't depend on resource data
Use ABAC when you need fine-grained rules like row-level security, ownership checks, or time-based restrictions
Many systems use both: RBAC as a coarse gate, ABAC for fine-grained resource access

This is the conclusion of my article. We’ve considered various authentication and authorization concepts.

Please show your appreciation by giving this a like, leaving a comment with something encouraging, or sharing something you just learned, or something I may have gotten wrong. Thanks for reading.