M.T.Ramkrushna

Posted on May 19

From Rails to Python: Why Python Classes Feel Simpler in Real Backend Projects

#ai #programming #python #fastapi

If you’re coming from Ruby or Rails, Python classes can feel surprisingly lightweight.
You still get object-oriented programming, encapsulation, reusable code, and clean architecture — but with less “magic”.

In this article, we’ll build a small real-world backend example using:

Python classes
Type hints
Decorators
Generators

And we’ll model something most developers understand instantly: an order processing system.

Real-Life Scenario

Imagine you are building a backend for:

an ecommerce store,
Food delivery system,
SaaS billing engine,
or warehouse management app.

You’ll likely have:

Orders
Customers
Inventory
Event logs

This is where Python classes become extremely practical.

Basic Python Class Example

class Order:
    def __init__(self, order_id: int, customer: str):
        self.order_id = order_id
        self.customer = customer
        self.status = "pending"

    def complete_order(self):
        self.status = "completed"

order = Order(101, "Ali")

print(order.customer)
print(order.status)

order.complete_order()

print(order.status)

Output:

Ali
pending
completed

Why This Feels Cleaner Than Many OOP Systems

Python removes unnecessary ceremony.

You don’t need:

getters/setters everywhere,
verbose constructors,
interfaces for everything,
complex inheritance chains.

Most backend systems only need:

simple models,
service classes,
utility layers.

Python excels here.

Add Type Hints for Production Readability

Now let’s make this production-friendly.

class Order:
    def __init__(self, order_id: int, customer: str):
        self.order_id: int = order_id
        self.customer: str = customer
        self.status: str = "pending"

    def complete_order(self) -> None:
        self.status = "completed"

Why type hints matter

In large teams:

they improve autocomplete,
reduce bugs,
help onboarding,
make APIs self-documenting.

Especially useful when building:

FastAPI apps,
AI systems,
async services,
internal SDKs.

Using Decorators for Logging

Real systems need observability.

Suppose you want to log every important action.

def log_action(func):
    def wrapper(*args, **kwargs):
        print(f"Running: {func.__name__}")
        return func(*args, **kwargs)
    return wrapper

Use it inside the class:

class Order:
    def __init__(self, order_id: int):
        self.order_id = order_id

    @log_action
    def ship(self):
        print("Order shipped")

Output:

Running: ship
Order shipped

Real Backend Use Cases of Decorators

Decorators are heavily used in:

authentication,
rate limiting,
retries,
caching,
logging,
monitoring,
API routing.

Example:

@app.get("/orders")

That FastAPI route itself is a decorator.

Generators: Secret Weapon for Large Data

Suppose your warehouse has 10 million orders.

Returning all data at once is memory-heavy.

Generators solve this elegantly.

def order_ids():
    for i in range(1, 1000000):
        yield i

Usage:

for order_id in order_ids():
    print(order_id)

The values are generated lazily.

Real-Life Generator Use Cases

Generators are perfect for:

CSV processing,
log streaming,
AI dataset pipelines,
Kafka consumers,
ETL jobs,
background workers.

Instead of loading everything into RAM, Python streams data efficiently.

Final Thoughts

Python classes are practical because they focus on:

readability,
maintainability,
developer speed.

When combined with:

decorators,
generators,
type hints,

you can build production-grade systems that remain surprisingly simple.

That’s one reason Python dominates:

AI engineering,
backend systems,
automation,
data infrastructure.

DEV Community