DEV Community: Toluwanimi

Designing REST API Requests and Responses That Scale Without Breaking Clients

Toluwanimi — Tue, 20 Jan 2026 09:00:00 +0000

It’s funny how most API problems show up in the space between requests and responses.

Most endpoints look fine on paper, but as soon as payloads grow too large, responses become inconsistent, and clients start making extra calls just to get basic data. And that’s how performance slowly drops.

How then do you design REST API requests and responses that stay fast, predictable, and easily evolve?

In ths guide, I’ll walk you through how to structure request payloads, shape JSON responses, handle errors cleanly, and make version changes without you breaking consumers.

By getting this layer right, your API becomes easier to use, easier to scale, and far less likely to cause surprises in production.

This article is for you if you:

Design or maintain REST APIs
Work on backend or platform teams
Want APIs that scale without constant refactors

Structuring REST API Requests for Performance and Clarity

A well-structured REST API request does two things at once: it tells the server exactly what you want, and it does that with the least possible overhead. When a request is vague, bloated, or inconsistent, performance tends to suffer long before traffic becomes “large.”

So to avoid that, start with clear, resource-focused URLs. Making sure each request links to a single resource or a well-defined collection. Avoid endpoints that try to do too much, such as /getUserAndOrdersAndStats. If a client needs multiple resources, you’ll have to design separate endpoints or use query parameters to shape the response instead of overloading the request.

Make use of HTTP methods intentionally. GET Requests should never change state and should be safe to cache. POST creates, PUT replaces, PATCH updates partially, and DELETE removes. When your method usage is consistent, then servers can optimize behavior and clients can reason about performance more easily.

Also, make sure to keep request payloads small and purposeful by only sending fields the server actually needs. Large JSON bodies increase parsing time and memory usage, most especially under high concurrency. If an operation only needs an ID and a status flag, don’t send the entire object.

Query parameters are also your best tool for read-heavy endpoints. Use them for filtering, pagination, sorting, and field selection. For example, ?page=2&limit=20&status=active is easier to cache, debug, and optimize than embedding the same logic in a request body.

Make sure you're explicit about data formats by always defining and documenting required and optional fields. Also, make use of consistent naming conventions across all your requests by sticking to one style, which is usually snake_case or camelCase and apply it everywhere. Making sure you’re mixing styles increases client complexity and leads to unnecessary transformation logic.

Validate requests early and fail fast. Reject malformed or incomplete requests before they reach deeper layers of your system. This protects downstream services and keeps your API responsive under load.

When designing, design requests with observability in mind by including request IDs or correlation headers so you can trace performance issues without inspecting payloads. A clear and well-structured requests make scaling your REST API significantly easier without changing your infrastructure.

Standard REST API Response Formats (With Examples)

A scalable REST API lives or dies by its response format, and if responses are inconsistent, clients get stressed, and performance tuning turns into guesswork. To avoid that, standardizing your response structure helps you to solve this early.

Most production-ready REST APIs return a JSON object, not raw values or arrays, and this gives you room to evolve without breaking clients.

A common and scalable pattern looks like this:

{
  "data": {},
  "meta": {},
  "error": null
}

Clients always know exactly where to look. Parsing becomes trivial and backward compatibility tend to improve.

To get successful responses, place the actual resource inside data. and avoid wrapping fields directly at the root level.

Example: fetching a user resource.

{
  "data": {
    "id": "u_123",
    "email": "user@example.com",
    "status": "active",
    "created_at": "2025-01-10T14:22:00Z"
  },
  "meta": {
    "request_id": "req_9f82a"
  },
  "error": null
}

This format works because you can add metadata, pagination info, rate-limit data, or request tracing without touching the resource itself.

For list endpoints, return arrays inside data, not at the top level

{
  "data": [
    {
      "id": "u_123",
      "email": "user@example.com"
    },
    {
      "id": "u_124",
      "email": "admin@example.com"
    }
  ],
  "meta": {
    "page": 1,
    "limit": 20,
    "total": 245
  },
  "error": null
}

Pagination metadata is not optional at scale. Clients need it to avoid over-fetching and to build efficient UIs.

Error responses should follow the same structure. Never return a completely different JSON shape just because something failed.

Example: validation error.

{
  "data": null,
  "meta": {
    "request_id": "req_9f82a"
  },
  "error": {
    "code": "INVALID_EMAIL",
    "message": "Email address is not valid",
    "details": {
      "field": "email"
    }
  }
}

This approach keeps error handling consistent across clients, whether they’re web apps, mobile apps, or other services.

Make sure you always pair response bodies with the correct HTTP status codes. 200 for success, 201 for creation, 400 for client errors, 401 or 403 for auth issues, and 500 for server failures. The status code tells the high-level story, and the response body provides detail.

Keeping field names stable and renaming response fields is one of the fastest ways to break consumers. If a change is unavoidable, version the API or introduce new fields alongside the old ones.

Keep your responses clean, intentional, and boring in the best way, as standard REST API response formats make your API easier to consume, easier to debug, and far more resilient as traffic and complexity grow.

Handling Errors Consistently Using HTTP Status Codes

Error handling is where a lot of REST APIs quietly fall apart. Having inconsistent status codes forces clients to guess what went wrong, retry unnecessary things, or fail in unpredictable ways. At that point, guesswork becomes expensive.

To avoid all that, start by treating HTTP status codes as the first layer of error communication. The status code answers the what, while the response body explains the why.

Use 400 Bad Request invalid input. This includes missing required fields, invalid data types, or failed validation rules. If the client can fix the request, 400 is usually the right choice.

Use 401 Unauthorized When authentication is missing or invalid. This signals that credentials are required or incorrect, and do not use 401 for permission issues after authentication.

Use 403 Forbidden When authentication succeeds but access is denied. The client is known, but the action is not allowed. Therefore mixing 401 and 403 often creates confusion and breaks authorization logic on the client side.

Use 404 Not Found when a requested resource does not exist. Avoid using 404 for validation errors or authorization failures. Clients rely on 404 to decide whether to retry, redirect, or stop.

Use 409 Conflict for state-related issues. This applies when a request is valid but cannot be completed due to a resource conflict, might be a duplicate records or version mismatches.

Use 422 Unprocessable Entity When the request is well-formed but incorrect. This is useful for complex validation errors where 400 is too generic.

Reserve 500 Internal Server Error for unexpected failures. If the server caused the problem and the client cannot fix it, this is the correct signal. Try to avoid leaking internal details in these responses and always return a response body that matches your standard error format.

Example: validation error.

{
  "data": null,
  "meta": {
    "request_id": "req_3a91c"
  },
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "One or more fields are invalid",
    "details": {
      "email": "Email format is incorrect"
    }
  }
}

Pairing this with a 400 or 422 status code allows clients to react correctly without inspecting the message text.

Keep error codes stable and machine-readable. Human-readable messages can change, but error codes should not. This makes client-side handling reliable across versions.

An API that rejects bad requests early using clear HTTP status codes protects downstream systems and stays predictable under load. That predictability is what keeps your API from breaking in production.

Versioning Your API Without Breaking Existing Clients

Breaking changes is one of the fastest ways to lose trust in an API. Once clients depend on your endpoints, even slight change can cause production failures which is why versioning exists to give you room to evolve without forcing everyone to upgrade at once.

One of the safest approach is explicit versioning, as clients should always know which version they would be calling.

The most common and practical method is URL-based versioning.

/api/v1/users
/api/v2/users

This is easy to understand, easy to route, and easy to remove. Caches, logs, and monitoring tools also work better when the version is visible in the path.

Header-based versioning is another option, usually via a custom header.

Accept: application/vnd.example.v1+json

This keeps URLs clean but also increases client complexity and makes debugging harder. If your audience includes beginners or third-party consumers, URL versioning is usually the safer choice.

Avoid versioning by query parameters. Patterns like ?version=1 are easy to misuse and often get ignored by caches and proxies. Also not every changes requires a new version. Additive changes such as adding new optional fields to responses are usually safe, removing fields, renaming fields, or changing response formats are breaking changes and should trigger a new version.

When introducing a new version, make sure to keep the old one running long enough for clients to migrate. And try as much as possible to communicate deprecations clearly through documentation, response headers, or both.

A common pattern is to include a deprecation warning in responses:

Deprecation: true
Sunset: 2025-12-31

This gives clients a timeline without forcing immediate action.

Keep versions stable and boring, version numbers should reflect breaking changes not feature releases. And avoid jumping versions unnecessarily or maintaining too many versions at once.

Lastly, make sure you test multiple versions in parallel. Your API infrastructure should allow v1 and v2 to coexist cleanly, with shared logic where possible. This helps to reduce operational risk and keeps evolution predictable.

Versioning done right lets your REST API grow without breaking existing clients and without creating long-term maintenance pain.

See you next time. Ciaaaaoooo

AI Ops for Small Engineering Teams: A Simple Guide Without the Enterprise Jargon

Toluwanimi — Wed, 10 Dec 2025 14:00:00 +0000

Most machine learning models fail silently before anyone notices.

That quote came from an ML engineer at a startup, and it stuck with me. Not because it was shocking, but because I feel it’s actually true. And the fact that most people don’t realize that most ML failures aren’t really caused by bad models, but by everything around the model. Monitoring, drift. Versioning, deployment, all these small things are what spiral into big fires.

Which is why I wrote this article about fixing that without enterprise jargon, without Fortune-500 budgets, and without a 10-person AI Ops team. Perhaps you’re a solo founder, indie developer, or part of a tiny engineering team; this is for you.

Why ML Breaks in Production for Small Teams

Imagine you’ve built a model that helps to predict customer churn. It’s clean, it’s fast, and it works beautifully on your laptop. But two weeks after you've deployed it, customers start complaining about the predictions looking “strange.” You then went to check the logs, and everything seems to be fine. No errors, no alerts, no warnings. All that's there are just wrong outputs.

Congratulations, you’ve just successfully experienced the classic silent failure of ML, and small teams tend to struggle because of this; they struggle because:

They don’t have full-time ML Ops engineers
They can’t afford heavy infrastructure
They rely on quick patches instead of full systems
They monitor logs, but not model behavior
They assume a “working” model will keep working

Which is where most failures begin, because maintenance is exactly what most small teams tend to skip; they don’t know what exactly to maintain.

What are The Real Problems?

Monitoring: A model output can drift far from reality while your infrastructure may look perfect. You monitor servers, you monitor endpoints. But do you monitor what the model predicts?
Data Drift: Your model might've been trained on yesterday’s world, but users change, markets change, and behavior changes. If at all, your input distribution shifts just a little bit, the performance drops silently.
Versioning: If you can’t reproduce your experiments, you can’t fix failing ones because ML models aren’t code, they’re snapshots of data, experiments, and hyperparameters.

According to research, at least these three issues cause 80% of production ML failures for small teams. But on the bright side, they’re all fixable without heavy systems like Kubernetes, Databricks, Airflow, or enterprise-grade ML.

Lightweight Tools That Actually Work for Small Teams

Here are some tools designed for startups and solo engineers:

BentoML: For packaging & serving models, it's simple, clean, Docker-friendly, and lets you turn any model into a reliable API.
Phoenix (Arize): For monitoring and drift, it's perfect for anomaly detection, embeddings, drift tracking, and root-cause analysis.
Neptune: For experiment tracking, keeping records of model versions, parameters, and results. No more “which notebook did I use?”
Weights & Biases: For lifecycle tracking, it has powerful but simple dashboards, and it's great for runs, artifacts, and team visibility.

None of these tools requires heavy infrastructure or a large team. Most of them have free tiers, and all are friendly for small operations.

A Simple Pipeline Any Small Team Can Use

Train your model locally by tracking experiments with Neptune or W&B.
Build a Docker image easily by packaging it with BentoML to create a model server with a single command.
Deploy your cheapest option, it could be Fly.io, Render, Railway, or a small VM
Use Phoenix for monitoring by sending predictions and input data to Phoenix to automatically track drift and anomalies.
Add auto-alerts just in case confidence drops or drift spikes, send yourself a Slack/email alert.

By doing all these, you'll get a clean, functional ML Ops setup. No Kubernetes cluster, no massive infrastructure.

How to Detect Failure Early (Without Fancy Tools)

Detecting or catching failure doesn't come easy, but one of the FASTEST ways to catch ML failures early is to:

Monitor confidence scores. If your model suddenly becomes “less sure,” then something is wrong.
Compare recent predictions with historical ones. If the shape changes, that means you have a drift.
Log inputs and outputs (even in CSV at first); it's impossible to fix what you don’t record.
Add a “canary model”, try running a tiny baseline model in the background to compare predictions.
Ask users. Small teams often forget the simplest monitoring tool, which is feedback. Even a one-line “Was this prediction helpful?” button can save you a lot of stress

How Small Teams Can Keep Their AI Systems Running Smoothly

Before Deployment, make sure you:

Track experiments
Save model versions
Package model cleanly
Add input validation

During Deployment, make sure you:

Log inputs and predictions
Store metadata (timestamps, versions)
Monitor performance metrics

After Deployment, make sure you:

Track drift (data & concept)
Compare outputs to benchmarks
Add alerts
Re-train periodically
Test with a small batch before full release

Following these steps helps you to handle ML Ops better than having 50-person teams.

Conclusion

In essence, the main message of this article is quite simple: as a small team, you can run ML in production reliably with lightweight tools and simple habits. AI ops doesn't have to be scary, it doesn’t have to be expensive, and you definitely don’t need enterprise jargon to make your models behave.

If you treat your model like a living system instead of a one-time project, it will surely reward you with stability, accuracy, and fewer late-night moments of wondering “why is it broken?”

See you next time. Ciaaaaaoooooooo

How Non-Developers Are Building Apps: Low-Code & No-Code Platforms

Toluwanimi — Tue, 18 Nov 2025 14:00:00 +0000

A few years ago, building an app felt more like you were climbing a mountain because you needed to know how to code, understand databases, set up servers, and even wrestle with deployment tools.

But things seem to have changed. Let's say you're a fashion store owner and you have an idea for an app that could let your customers browse outfits and place orders directly from their phones, and obviously, you don’t know how to code. In fact, you've never written a single line of JavaScript.

But still, you opened a Glide, a no-code platform, connected your Google Sheet, and within hours, your app was live. No complex syntax. No developer needed. A few years ago, that would’ve sounded impossible. But today, it’s now a movement.

What Are Low-Code and No-Code Platforms?

No-code platforms are platforms that let you build apps without writing a single code. While Low-code platforms allow you to build most parts visually, you can also add small bits of code for flexibility. Think of it like you're building with LEGO blocks. Instead of handcrafting each piece, you pick what you need, snap it into place, and see your app come alive. Some typical examples include:

No-code: Glide, Bubble, Adalo, Softr
Low-code: OutSystems, Mendix, PowerApps, AppSheet

Basically, they make use of drag-and-drop tools, templates, and logic builders so that people without technical backgrounds can create apps, websites, and workflows.

Why Does This Shift Matter

Here’s a surprising fact: according to Gartner, by 2026, 80% of software development will involve low-code or no-code tools.

Which means the next big app idea might not come from a developer at all; it might come from a teacher, a small business owner, or probably a student with a laptop and a dream.

Don't get me wrong, this isn’t about replacing developers. It’s about making the ability to build software and applications accessible to everyone, not just professional developers⁠

For decades, software was gatekept by complexity, and now, people can turn ideas into real, working tools that are fast, cheap, and with minimal technical knowledge.

Why Non-Developers Are Embracing It

Affordability: Hiring a development team at times might be too expensive. Especially for small businesses, that’s often a deal-breaker for **them. So, No-code platforms lower that barrier for them.
Speed: You don’t have to wait months for a development cycle. You can simply go from idea to prototype in hours. Startups tend to validate their ideas faster, and entrepreneurs can launch their MVPs (minimum viable products) without big budgets.
Empowerment: For the first time, people who’ve never coded can bring their ideas to life. It’s not just about saving money alone; it’s about having control. No more waiting on developers, no more long communication loops. Just creativity in action.

But Wait, Where Do Developers Fit In?

Some developers worry that low-code and no-code tools will replace them. Relax, that’s a myth. The reality is that most of these tools handle the simple, repetitive stuff like the internal dashboards, forms, or small apps. But when it comes to scalable systems, complex integrations, or security-critical software, no one is touching a developer; developers are irreplaceable. In fact, a lot of companies now use hybrid approaches whereby:

Developers handle backend logic, databases, and integrations.
Non-developers handle the front-end or workflows using no-code tools.

It’s basically teamwork, not replacement.

The Challenges of No-Code and Low-Code Platforms

Limited Customization: On the platform, you’re often limited to what you can do and what you're allowed to do. If you want something unique, like a custom algorithm or unusual UI, you won't be able to achieve that.
Vendor Lock-In: Let’s say you build an app on a no-code platform, and you plan to move it elsewhere later; it will be hard because some platforms don’t let you export your full codebase.
Scalability and Security: No-code apps work well for small use cases, but scaling them to enterprise levels can be a little bit tricky, as developers will often need to refactor or rebuild them later. But, for many small startups and creators, these downsides are worth the trade-off, especially in developing markets where resources are limited.

Developers Are Joining the Revolution

Interestingly, more developers are also using low-code tools themselves. Why? Because they speed up work, instead of you building an internal tool from scratch, as a developer might choose to use Retool or Budibase to drag and drop components. It saves hours, even days of coding.

Some call it “developer-assisted no-code,” whereby developers use these tools just to focus more on logic and less on setup.

As one developer once put it:

No-code doesn’t replace us; it just helps us to remove the boring parts.

The Future: Collaboration Between Coders and Creators

Just imagine a future where:

A marketer builds the front-end of a campaign app in Bubble.
A developer hooks it to an API for live data.
A product manager tweaks workflows in Zapier or Airtable.

Well, that's already happening. The line between technical and non-technical is blurring. The new world of app development isn’t just about code; it’s about creativity, logic, and collaboration.

Getting Started With No-Code / Low-Code

If you’re curious, here are a few tips on how to begin:

Start small. Build a personal project, maybe a to-do app or feedback form.

Choose a platform.

Want to build an app? Try Glide, Adalo, or Bubble.
Need automation? Try Zapier or n8n.
Want dashboards? Try Retool or Airtable.

Watch tutorials. Most of these platforms have communities full of free guides.
Think like a developer. Even if you’re not coding, understanding logic, data flow, and user experience still matters.

Conclusion

The low-code and no-code revolution is not about removing developers; it’s about bringing in more creators into the tech world.

It’s about helping small businesses launch their own e-commerce app. It’s about everyone becoming a builder. So, whether you’re a seasoned developer or someone who’s never written a single line of code, the message is still the same: you can build something today.

Because the future of software isn’t just about coding. It’s about creating

See you next time!!! Ciaooo

How Generative AI is Transforming Software Architecture in 2025

Toluwanimi — Tue, 11 Nov 2025 14:00:00 +0000

AI won’t replace developers. But developers who use AI will replace those who don’t.

It’s a quiet Monday morning, and you are sipping your coffee, staring at your screen because you've been given a new task to design a scalable system for a startup that handles thousands of data requests per second.

In the past, this would’ve meant weeks of you writing whiteboard diagrams, endless discussions, and getting architecture reviews. But this time around, instead of you doing all that, you open your AI assistant and type:

Design a microservices architecture for a high-traffic analytics platform.

Within seconds, the AI helps you generate a draft for an architecture diagram with services, database suggestions, caching layers, and communication protocols. You then tweak a few parts, add your company’s requirements, and deploy it for review.

What normally takes weeks for you to do now gets completed in hours.

Welcome to 2025, the year Generative AI isn’t only just writing code, but it’s reshaping how software itself is designed.

From Coding Partner to Architectural Collaborator

At first, Generative AI kind of started as a handy assistant for developers, while tools like GitHub, Copilot, and ChatGPT help to complete code automatically, generate unit tests, and even write documentation. But in 2025, AI’s role has expanded a lot; it has gone beyond just helping, it’s now collaborating. AI models now understand context better than ever. They can go as far as analyzing an entire codebase, spotting bottlenecks, and even suggesting some architectural improvements.

Imagine you ask your AI, “What’s the best way to migrate a monolith to microservices?” It won’t just reply you with an article; it will go as far as drawing out a migration roadmap, list possible risks, and even recommend some specific frameworks suited for your stack. It’s just like having a senior architect who has read every software design book that has ever been written, and it doesn’t get tired.

AI-Powered System Design

In 2025, I can say most developers no longer start architecture planning from scratch. They mostly begin with AI-generated blueprints.

Let's say you’re trying to build a real-time chat app. You can simply ask your AI:

Generate a scalable event-driven architecture for a chat system with 1 million users.

The AI then responds with a layout using WebSocket servers, Kafka for message queues, Redis for caching, and PostgreSQL for persistence, all visualized and annotated.

It’ll even go further to explain the reason why.

Kafka is chosen for its high-throughput event streaming capabilities.

This little combination of explanation and automation will make even a junior developer capable of understanding and building complex systems.

Smarter Decisions Through Simulation

Software architecture is not just about the structure. It’s about decisions and trade-offs, and AI tools in 2025 can now simulate performance outcomes. Even before choosing a database or load balancer, AI can project how each option will behave under different traffic conditions.

For instance, let's say you tell your AI to simulate how an AWS Lambda-based setup compares to a Kubernetes cluster under 1 million daily requests. It’ll go further by showing you costs, latency, and failure points before you even write a single line of code.

That’s like running your system in the future and learning from it today.

Real-World Use Cases

Netflix: Netflix has been experimenting with AI models that even help predict scaling needs and suggest service decompositions. A lot of its internal architecture reviews are semi-automated with AI-driven recommendations, which saves time and reduces human error.
Amazon: Amazon engineers also use AI to analyze system metrics and propose architectural redesigns. These tools automatically recommend database sharding strategies or API restructuring based on performance data.

Startups: Most startups now build their entire MVP architectures in a day. With generative AI platforms like Cogram and Builder.ai, they automatically generate backend blueprints, CI/CD pipelines, and cloud deployment configs

Challenges and Cautions

AI gives you a head start. But you still make the final call.

AI can help you suggest a good-looking design, but it doesn’t always understand the context. An AI might probably recommend a distributed system when a simple monolith would do. It might suggest scaling strategies that look great on paper but are overkill in practice. That’s why you as a developer, you are still in control. The best results happen when humans validate and refine AI’s suggestions.

What then is the role of a developer, you’d ask?

Well, as generative AI is shifting and changing what it means to be a developer. As a developer, you’re moving from writing every line of code to orchestrating how systems come together. As a developer, you now focus more on why and less on how.

Why does this design pattern fit the business goal?
Why scalability matters at this stage.
Why cost efficiency should guide your cloud setup.

AI will be in charge of the how of the blueprints, the code, the configs, while humans steer the why.

Conclusion

Generative AI isn’t here to take over software architecture. It’s just here to redefine how we think about building systems.

Whereby the tedious parts of drawing diagrams, documenting APIs, and evaluating scaling strategies are now being automated. Which means as a developer, you can spend more time solving real problems and less time doing repetitive work.

The future of software architecture is not just human or AI. It’s both working side by side.

How To Build APIs That Scale Without Burning Out

Toluwanimi — Tue, 04 Nov 2025 14:00:00 +0000

The best code is the one you can sleep peacefully knowing it works - Anonymous developer

Imagine, as a backend engineer who’s working for a fast-growing startup company, you slept and woke up to a dreaded Slack notification. The company's API, the same one powering thousands of user requests per minute, has just crashed. Servers were timing out, users were complaining, and the frontend team was panicking. What is going on? You know you've written a good code, or so you thought, but good code isn't always scalable code. What seems to work for 100 users was now collapsing under 50,000, and you're probably frustrated and exhausted.

This is the reality a lot of the developers out there face: you’re building APIs fast, trying to keep up with deadlines, but somewhere between your fixing bugs and pushing updates, you start to burn out. The truth is, scaling an API isn’t just about the performance; it's also about sustainability. You want systems that scale without your mental health taking a hit. Let's have a look at how to build an API that handles growth and how you can do that without losing sleep.

Start Simple

Scalable APIs don't start complex; they simply grow into complexity. A lot of developers try to over-engineer very early, adding load balancers, caching layers, and microservices before the product even has real traffic. The best approach is to start simple and design for change. Imagine building a small restaurant, you wouldn’t just start with ten ovens and twenty chefs, would you? You'd probably start with two or maybe four to test what customers like, then expand gradually. APIs are the same. You start with a single well-designed endpoint, make sure it’s stable, fast, and clear.

Example

from fastapi import FastAPI

app = FastAPI()

@app.get("/greet")
def greet_user(name: str = "Developer"):
    return {"message": f"Hello, {name}!"}

Simple, predictable, and easy to extend. Later on, when traffic grows, you can split routes or move logic into separate modules.

Caching is Your Silent Superpower

Caching saves lives a lot, and it also saves developers' sanity. Think of caching as your API's short-term memory. Instead of you fetching the same data repeatedly from your database, you keep copies ready to go. For example, if your API serves product details, and 80% of users keep asking for the same products, it really won't make sense to hit the database every time just to get them. The easiest way for you to do that is to just cache it, making use of tools like Redis or Memcached to store frequently accessed data helps you a lot, and a few seconds of cache can help cut server load drastically.

Example

import redis
from fastapi import FastAPI

app = FastAPI()
cache = redis.Redis(host='localhost', port=6379, db=0)

@app.get("/product/{id}")
def get_product(id: int):
    cached_product = cache.get(id)
    if cached_product:
        return {"source": "cache", "data": cached_product.decode("utf-8")}
    # simulate DB call
    product = f"Product {id} details"
    cache.setex(id, 60, product)  # cache for 60 seconds
    return {"source": "database", "data": product}

Caching doesn’t just make your API faster. It gives you breathing space when things get busy.

Use Rate Limiting

Rate limiting helps to protect your system from overload. Imagine 20,000 users hitting your API at the same time. Without limits, just one rogue client could consume all your resources and bring everything down. What rate limiting simply does is give your API structure; it’s not just about restricting users, it’s about keeping the system alive and stable.

You can think of it as saying ’’You can request 60 times per minute, but no more’’

Example

from fastapi import FastAPI
from slowapi import Limiter
from slowapi.util import get_remote_address

app = FastAPI()
limiter = Limiter(key_func=get_remote_address)

@app.get("/data")
@limiter.limit("5/minute")
def get_data():
    return {"message": "Here’s your data!"}

Automate Testing and Monitoring

There's no way for you to scale what you can’t see, but you can make things easier for yourself by using monitoring tools like Prometheus, Grafana, or Datadog, which can help you track latency, uptime, and performance in real time. With these tools, if a route slows down, you’ll know before users start tweeting about it.

While for testing, you can use frameworks like pytest or locust, as they help you simulate real-world traffic

Example

from fastapi.testclient import TestClient
from main import app

client = TestClient(app)

def test_greet():
    response = client.get("/greet?name=Toluwanimi")
    assert response.status_code == 200
    assert "Toluwanimi" in response.json()["message"]

This makes sure that every single update you push doesn’t break existing functionality

Design for Horizontal Scaling

Horizontal scaling simply means adding more servers and spreading the load across them. More like hiring enough workers instead of giving one person all the jobs to do.

Vertical scaling, on the other hand, means upgrading your existing server. Cloud providers like AWS, Google Cloud, or Azure make this very simple. You can use load balancers to distribute requests evenly. So when designing your API, make sure it can grow sideways and not just upward.

Prioritize Developer Experience

Just so you know, your API is only as good as how easy it is to use. Clear documentation, meaningful error messages, and consistent naming conventions save you from hundreds of support requests later on.

Simple things that help:

Clear, human documentation
Consistent naming (e.g /users , /users/{id} )
Helpful error messages

Example

{
  "error": {
    "message": "Invalid request. Missing 'user_id'.",
    "code": 400
  }
}

Good APIs are like good conversations; you don’t have to repeat yourself to be understood. If people understand your API easily, they’ll use it more.

Optimize Smartly, not Early

Every developer must’ve heard this quote from Donald Knuth:

Premature optimization is the root of all evil.

What does he mean by that? What he meant is simple: don’t waste your time fixing what isn’t broken.

Instead of you spending days rewriting your API to handle 10 million users, focus on writing clean, maintainable code for the 10,000 you actually have. Profile first, then fix what matters. Tools like cProfile in Python help identify bottlenecks. Sometimes, a single database index can make a bigger difference than rewriting an entire endpoint.

import cProfile

import re

def test_function():

    for i in range(10000):

        re.match("a", "a"*i)

cProfile.run('test_function()')

Don’t Forget the Human Side

When you’re under pressure to keep systems online, it’s very easy to slip into endless late nights and weekend deployments. But getting burned out doesn’t just hurt you; it hurts your code too.

Tired developers tend to make avoidable mistakes. A single missing comma or untested patch can take hours for you to fix. Which is why you should set healthy limits:

Automate deployments.
Rotate on-call schedules.
Take breaks between releases.

Your system should scale, but you shouldn’t collapse while it does.

Document Everything

Every scalable API always has one thing in common, which is great documentation. Not just for external users, but for your own team precisely.

To keep track of:

Endpoints and response formats
Authentication flow
Error codes
Change logs

Prepare for Failure

Just so you know, even the biggest APIs fail. But what matters the most is how you recover.

Adding graceful fallbacks. In case one microservice fails, others can continue running. Make use of circuit breakers (like Hystrix) to prevent cascading failures.

And in case things break down again, use the downtime to learn, not blame.

import requests

from requests.exceptions import RequestException

def fetch_data():

    try:

        response = requests.get("https://api.example.com/data", timeout=3)

        response.raise_for_status()

        return response.json()

    except RequestException:

        return {"error": "Service temporarily unavailable"}

Overview of how to go about building your API

Principle	Why It Matters	Quick Tips
Start simple	Prevent over-engineering	Focus on core endpoints
Add caching	Cuts down database load	Use Redis or Memcached
Rate limit	Protects from abuse	Tools like `slowapi`, kong
Automate testing	Prevents regression	Run pytest before deployment
Scale horizontally	Detects the problem early	Use Grafana, Datadog
Prioritize DX	Enables growth	Load balancers, kubernetes
Optimize smartly	Encourages adoption	Clear docs, good errors
Protect teams	Saves time	Profile before optimizing

Conclusion

Building APIs that scale isn’t just about you coding or handling traffic. It’s about designing for growth, maintaining your simplicity, and making sure you protect your well-being as a developer. No matter the number of requests your server can handle, if you end up getting burned out, the system loses its most important resource, which is you, the human behind it.

The goal isn’t just for you to build something that never crashes, but something that lets you thrive while it grows. Like my mentor once told me, scalable APIs are written by developers who have learned to balance precision with peace of mind. So when building your API, build it gently

See you next time!! Ciaoooo.

Must-Know Python Packages for Developers: Tools You Can't Miss

Toluwanimi — Mon, 13 Oct 2025 14:22:08 +0000

Any problem in computer science can be solved with another level of
indirection. - David Wheeler

Back in 2017, a developer, Kenneth Reitz, published a package called Requests with the goal of making HTTP requests in Python very easy, and he was able to accomplish it. Today, Requests is being downloaded billions of times because it powers countless apps, APIs, and projects around the world. And if, as a developer, you’ve fetched data from the web using Python, there are chances that you've used it, because that's the magic of Python packages. They don't just save time, they shape the way you build software, whether you’re scraping data, training a machine model, or you’re building a web app. Python packages are the difference between you having a week of frustration and a single elegant line of code.

But with the large number of packages we have on Python, you’re probably wondering which one you should focus on. Let's walk through the Python packages every developer must know, but first, why do these packages matter?

Why Packages Matter

Just imagine you’re building a house, Python is more like the foundation and the tools you'll need for it. Packages, on the other hand, are like the ready-made furniture, the wiring, the plumbing of the house, and instead of you carving your chair from wood, you just place an order for one. For developers, this means

Faster development
Fewer bugs
Focus on solving problems

With that being said, let's now walk through the must-know packages that you, as a beginner or expert, should keep in your toolkit.

1. Requests

Take, for example, you’re building a weather app, instead of you writing 50 lines of socket code to connect to a weather API, you can do this.

import requests

response = requests.get("https://api.weatherapi.com/v1/current.json?key=API_KEY&q=London")
print(response.json())

Just one line and you've got live weather data. Almost every app needs to talk to the web, and requests make it easy for companies like Spotify to use it, so developers can integrate the API quickly

2. NumPy

If Python were a car, Numpy would be the engine powering its data capabilities because it allows you to work with large datasets and also perform complex maths quickly. For example, you’re analyzing a list of numbers to add; instead of you looping through the list to add them, with NumPy, you can add millions of numbers in milliseconds, and you can handle thousands of rows of data without slowing down.

3. Pandas

Have you ever opened an Excel sheet with disorganized rows and columns? That's what real-world data looks like, and Panda helps to clean, organize, and analyze it.

import pandas as pd  

data = pd.read_csv("sales.csv")  
print(data.describe())

Within seconds, you'll be able to understand your data. Financial analyst uses pandas to process stock market data, detect trends, and make predictions

4. Flask & Django

Let's say you're a junior developer at a startup and the team needs a quick prototype of a booking system. With Flask, you can just create a functional demonstration or idea within a short time frame. Web apps run our world, and Python has two powerful frameworks:

Flask: great for small apps or APIs
Django: perfect for larger apps

5. TensorFlow & PyTorch

If you are planning to explore AI, these two are your best friends. TensorFlow by Google and PyTorch by Meta are the engines behind image recognition, chatbots, and even self-driving cars. Tesla’s AI team uses a deep learning framework built on PyTorch to train its models for autonomous driving.

6. SQLAlchemy

Databases can be very tricky, but SQL Alchemy makes working with them feel natural, and instead of writing raw SQL, you can use Python code. For example, if you're trying to build an app with SQL Alchemy, you can manage all your tasks in a database without drowning in SQL syntax.

from sqlalchemy import create_engine  

engine = create_engine("sqlite:///users.db")

Note

Every developer hates bugs, but making sure you catch them early saves you pain later. Companies like Dropbox and Mozilla rely on Pytest to ensure their code works across millions of users. Because Pytest makes writing tests simple and clean.

7. Virtualenv & Pipenv

Have you ever had a project you're working on break because another project needed a different library version? That's called dependency hell. Let’s say you’re working on two projects, one needs Django 3.2, the other needs Django 4.0. Without a virtual environment, they will clash, and for you to avoid that, that's where virtualenv and pipenv come in. They help you keep your project isolated, so they don't step on each other's toes.

Comparison Table

Package/Framework	Best For	Why It Matters
Request	HTTP request	Makes web APIs simple
Numpy	Maths & arrays	Fast, efficient data handling
Pandas	Data analysis	Excel-like power in Python
Flask & Django	Web apps	From small APIs to big sites
TensorFlow & PyTorch	Machine learning	AI, deep learning, ML
SQLAlchemy	Databases	Clean, pythonic database work
Pytest	Testing	Write cleaner, simpler test
Virtualenv & Pipenv	Dependencies	Avoids dependency hell

Quick Tips for Using Python Packages

Python packages are more than just tools; they’re building blocks for ideas. They let you go from “I wish I could” to “I just did” faster than you can ever think.

You don’t need to master them all at once; you can:

Start small by picking one package that solves your current problem.
Read their docs as they’re often full of examples.
Try a lot of experiments, build side projects.
Also, make sure you stay updated. Libraries evolve quickly; make sure you’re on stable versions.

Conclusion

Every great developer's story is written one package at a time, and mind you, the next great Python package might not be on this list. It might actually be the one you create, so don’t just consume packages; make sure you use them, build with them, and when you’re ready, contribute back.

See you next time.

What are some good websites on which programmers can write articles?

Toluwanimi — Wed, 01 Oct 2025 14:14:23 +0000

Writing is thinking. To write well is to think clearly. That’s why
it’s so hard.– David McCullough.

Surprising, isn’t it? A lot of programmers assume, or rather, they think writing is only for journalists or bloggers. But the truth is, most respected developers built their reputation by sharing what they know in writing. Think of Dan Abramov, co-author of Redux, who started his career by writing blog posts that later became a go-to resource for developers all around the world.

Which reminds me of a friend of mine when he started learning how to code. He thought he needed to keep all his notes private; he didn’t want anyone to access them. All his notion page was packed with half-written tutorials and bugfixes. He told me about it, and I told him to try publishing some of the things he kept to himself. Fortunately, he was able to publish one short article about how he solved a database error, and something surprising happened.

A junior backend developer from India left a comment saying ’’Thank you, I was stuck on this for four days’’

That’s when he realized that programmers don’t just write code, they write for people, and sharing what you know can help someone on the other side of the world. Also, writing as a programmer is not just for helping others; it makes you more visible in the tech space.

The best way to learn is to teach – Frank Oppenheimer

Which then begs the question. Where should you publish your work? We all know how crowded the internet is; most platforms give you good visibility by helping you put your work out there for people to see, while others feel like you’re just shouting into a void. But fear not, let’s go through some of the best platforms I feel you can and should be using to publish your work.

How to choose a good platform

Before walking you through the platforms you can be using to publish your work. How do you know the platform that works best for you? To pick a platform suitable and perfect for your work, you need to consider and think about what you want:

Do you want a large audience?
Do you want to be able to connect with other developers?
Do you want to have control over your work?
Do you want to earn money?

If you’ve considered all this and you’ve made your decision, let’s then have a look at the best websites you can choose to work with.

1. [Dev. to

Dev. to](http://dev.to) is more like a coffee shop for programmers. It’s a place where most developers love to hang out. A lot of developers post their tutorials, personal experience, and lessons on a project they’re working on or a failed project so others can see and learn from it. Take, for example, you posted a project on your latest debugging tricks, and within an hour, another developer saw your post and commented. ’’Hey, I came across this a week ago. Your solution worked. That’s the kind of vibe you’d get on Dev.to. It’s developer-focused and also a friendly community for developers.

2. Medium

Medium is more like a library for the internet because articles on Medium tend to reach a wider audience and not just programmers. You come across a lot of stories from developers, tech founders, and engineers sharing their knowledge. If you are leaning towards the part of wanting your work to reach a lot of people, Medium is the one for you, and on the other hand, you can also earn a little money through Medium's partner program. Imagine you wrote about a project, and some recruiters or start-up founders come across it; that’s a life-changing opportunity. Quincy Larson, the founder of freecodecamp, also started publishing his works on Medium, and it went viral. That exposure was what helped build one of the biggest coding communities today, so who says you can’t do that, also?

3. Daily Dev

Daily Dev is more like a newsfeed for developers. It’s designed for developers who want quick or easy-to-understand tech content. You can write, publish your work, and your work gets noticed by other programmers scrolling through the feed. Daily dev is gaining more attention from programmers, even though it's less formal than Medium; it's one of the best platforms to use for quick exposure, if you want your work to reach developers who often check for updates daily.

4. Hashnode

Hashnode is also one of the best platforms out there. It's just like you having your own personal blog; you can use your domain, and with that, it makes it look professional. Most programmers who want to grow their personal brand tend to use Hashnode because it gives them control and reach over their work at the same time. If, as a programmer, you are probably looking for a space to share your journey as a programmer, Hashnode is the one for you. Most people even land jobs as a result of them sharing their journey posts and projects because recruiters tend to see their consistent posts.

5. GitHub pages/GitHub Gists

You are probably wondering, what about GitHub? Well, GitHub is a place where code lives, and a lot of programmers use GitHub pages to publish from their repositories. Repositories are more like a storage location on GitHub, a place where code and other files for projects are stored, and developers often use them to publish their blogs or share code snippets.

The same thing goes with Gists, which are perfect for small write-ups and explaining a function. If you are looking to document your code or tutorials, this works perfectly.

Tips to Get Started

You don't need to be an expert to start writing; you just need to share what you know because somewhere, a developer like you is probably searching Google at 2:00 a.m. for an error he/she is having, and your article might be what helps them move forward. So:

Write about what you’ve just learned
Share mistakes that you've made
Be consistent, even if it's one article a month

Conclusion

As a programmer, when you write, you don't just teach; you learn better. Explaining a work you did forces you to simplify it for others to understand, and the more you write, the more you build credibility and opportunities for yourself. Don't keep your knowledge locked in your head; rather, choose one of these platforms and write that article about the new framework you tested or the API you built using Rust. Someone somewhere is waiting to read it.

See you next time.

Django Tutorial:The Ultimate Guide (2023)

Toluwanimi — Thu, 14 Aug 2025 11:00:30 +0000

High scalability, versatility, security, rapid development, well-structured and detailed documentation are some features that make the Django framework one of the best and most consistent web frameworks in the industry.

With Django, there is only one way to do things, “The Django Way”.

Yes, Django is built to force you to follow industry-standard ways of developing web applications.

The advantage this has is that working with Django will make you a better developer.

The downside is that it doesn’t give room for some flexibility with the sister framework Flask.

To learn Django in detail, there is no better course to recommend personally than Full stack web development and AI with Python (Django). Check it out now for a discount.

Prerequisites

Before continuing with this guide, you will need to understand server-side web programming, frameworks, general Knowledge of Python, which will aid your understanding of the Django framework.

To learn Python and Django in detail, there is no better course to recommend personally than Python Django 2021 – Complete Course. Check it out now for a discount.

What is Django

Django is a high-level open-source Python MVT web framework that enables the rapid development of secure and maintainable web applications.

Django follows the popular MVC (Model View Controller) architecture with a bit of variation. While MVC stands for Model View Controller, Django’s MVT stands for Model View Template.

When it comes to using Django as a framework of choice, there is only one way to do things, “The Django Way.” It supports an industry standardized way of developing robust web applications.

Features of Django

Before making any framework your choice for a project, you must have studied it and be satisfied with its features. Django is a framework with vibrant and attractive features. Let’s explore them.

Django’s excellent interactive documentation makes it easy and exciting for any new developer to pick a project and finish it in record time.
Django is a framework built upon Python. Being about the most straightforward programming language with numerous packages and libraries, you can quickly build websites, web apps, data science, machine learning, and artificial intelligence projects using Django and other python packages.
Django is, by default, Search Engine Optimized.
It is Highly Scalable. The Instagram team that developed the popular Instagram using Django should quickly tell you what you can do with Django.
Django is Versatile
It is highly secured.
With over a decade of solid performance and consistency, it is no joke that Django is thoroughly tested.
Django provides rapid development.
It comes with a prebuilt admin area. This feature means you don’t necessarily need to build a new admin area to manage your web application.

Why you should learn Django

Django, as stated above, follows industry standard best practices for web application and software development. This standard forces you to write clean codes while you learn.

Django works best and easily with SQL databases. With Django, you don’t need to know how to query SQL to create your applications.

As stated earlier, Django is built on Python, which is the language of choice for any Data Science, Data Analytics, Artificial Intelligence, and Machine Learning project.

So, if your application requires ML, AI, Analytics, or Data Science functionalities, you should go with Django.

When learning any language, the importance of community cannot be overemphasized.

Luckily, Django boasts an active community that will help hold you by the hands and make you a professional software developer.

When you want to build complex web applications in less time with the industry’s best practices, Django is the Python framework of choice.

From the somewhat difficult Django 1.0 to today’s simple and elegant looking Django 3.0+, we have seen consistent growth in developing and maintaining the Django framework.

The key features and functionalities that make Django outstanding are:

Open Source.
It supports the Full Stack Framework.
Authentication.
URL Routing.
Templating Engine.
DRY (Don’t Repeat Yourself).
ORM Mappers.
It provides Database schema migrations for common databases like PostgreSQL, MySQL, SQLite, Oracle under the third-party drivers.
A Variation of MVC Architecture called MVT
Inbuilt Admin Panel
Excellent and Fast debugger interface
ASGI (Asynchronous Server Gateway Interface) and WSGI (Web Server Gateway Interface compliant in Django 3.0+

Wow! You now have a complete overview of what Django stands for and the things you can do with it.

You can pause a little, take a sip of your coffee and follow us as we discuss the Django Framework in more detail.

Chapter 2: The Django Framework

In this chapter, we will deep-dive into the Django framework. We will explore "The Django way" and learn the architectural patterns that governs Django

The chapter will set pace for the next chapter. Therefore, we recommend that you spend sometime understanding the patterns and philosophies of Django.

So far, the buzzword here has been “Framework.” But what does framework mean? There is no doubt that we could be using the word without understanding its meaning and why we should use it.

According to Isaac Newton, “If I have seen further, it is by standing on the shoulders of giants.”

This quote by Isaac Newton gives light to how far and powerful frameworks can be. Why reinvent the wheel when you can ride on it and add more functionalities?

Let us elucidate. You want to build a house and need all the necessary timber to start and finish it.

You are faced with two options:

Building from scratch, where you will need to cut down some timbers and shape them to your desired shape and sizes.
Building with already made frameworks of woods of different sizes and save yourself some precious time, energy, and sometimes money.

Django web framework was developed to force you to build industry-standard web applications by providing the framework of woods of different sizes to save you time, energy, and cost while developing your MVP.

In this section, we will discuss the three main parts of the framework. This is called the MVT, which stands for Model View Template.

Are you ready? Please fasten your seatbelt. We will be going for an exciting ride.

What is MVT?

MVT stands for Model View Template. It is a software and design pattern variation of MVC (Model View Controller).

MVC is a standard architectural pattern that many languages employ with slight variations such as Laravel, Ruby on rails, AdonisJS, etc.

The Django framework handles all the controller parts of the MVC by itself. This means Django has done a lot of the heavy lifting for you and helps reduce the code you will need for a minimum viable product (MVP).

This made Django introduce and implement templating as a pattern. Let us briefly discuss them separately.

Model

Models in Django are the single definitive source of information about your data. Generally, each model maps to a single database table. It helps provide the interface for the data stored in the databases.

For instance, assuming we have a Car class in our model, the class name will correspond to the table name in our database. This means we don’t have to create a table in our database manually, but we only run migrations to generate the tables.

View

Definitions for Django views are somewhat not simple to understand.

So we will try explaining it with what it does so that a non-technical person can easily understand it.

Think of this as the file where you write the functions that retrieve data from the database and display it on your website’s templates.

With this explanation of Django views, one can say that it supplies the dynamic content to HTML/CSS/Javascript files and its templating language.

At the same time, the Django template fully represents the static part. Next, let’s discuss the last part of the Django MVT architecture.

Template

As we discussed briefly in view, the Django template represents the static part of your desired output.

Again, to explain this for easy understanding, your template will contain the HTML, CSS, Javascript, and Django templating language.

So while the HTML provides the static structure of your website, the templating language is used to dynamically display data on the HTML file from the view file.

URL Routing: Request and Response Analogy

Chapter 3: Build a Todo Web App with Django

In this chapter, we will build a simple Todo application by implementing the knowledge we have gathered from previous chapters.

This is to help us get ready for real world project which might be a little bigger.

To build a Django application for this Django tutorial, you need to have python installed on your computer. We assume you have it.

It is good practice to develop your application in a virtual environment. We used Virtualenv. The code below will help you install it.

pip install virtualenv

Next is to create a virtual environment.

virtualenv virt

source virt/Scripts/activate   # this will activate the virtual environment.

The other packages are:

pip install django
pip install mysqlclient

Start a Django project using the following command.

django-admin startproject mytodo

Move into the created project with cd mytodo. This is the root directory of your application.

Create Task App

The above image is the structure of a Django project. Now let’s create an app.

python manage.py startapp task

After starting a new app, the new project structure will look this:

Add the app task into your settings.py file.

# Application definition

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'task'
]

Database set up

Still on this file, recall we installed mysqlclient earlier, we did because we will be using MySQL for our database.

Now, go to your PHPMyAdmin or any database client of your choice, create your database.

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'todoapplication',
        'USER': 'root',
        'PASSWORD': 'password',
        'HOST': 'localhost',
        'PORT': '3306',
    }
}

It is time to create our model. Let’s go to our task folder and open Models.py and paste the code below.

from django.db import models

# Create your models here.

class Task(models.Model):
    title = models.CharField(max_length=200)
    completed = models.BooleanField(default=False)
    created = models.DateTimeField(auto_now_add=True)

    def __str__(self):
        return self.title

This is a simple model with a class name “Task”. It has three attributes and a method.

The title of the todo task, a boolean field “completed” and created time.

The method is used to display the title in the admin panel of the app.

Everything is looking good. Let’s make the migration. This will help make successful connections to the database and create tables with the prebuilt Django models and our model.

Before we make the initial migration, it is important to see that the migration folder and the __init__.py is empty.

Run this command to create migrations for your database:

python manage.py makemigration

This will display all the files available for migrations where there are no changes, it will indicate so.

When you make migrations, Django prepares a migration file for you as above,

Run this command to migrate your database:

python manage.py migrate

Create Task Files

Go to the task folder and create the following folders “templates”, inside the templates folder create “task”. Then create the following HTML files.

Open the views.py file in the task folder and paste this code below:

#views.py

from django.shortcuts import render, redirect
from django.http import HttpResponse

from .models import *
from .forms import *

# Create your views here.

def index(request):
    tasks = Task.objects.all()

    form = TaskForm()

    if request.method == 'POST':
        form = TaskForm(request.POST)
        if form.is_valid():
            form.save()
        return redirect('/')

    context = {'tasks': tasks, 'form': form}
    return render(request, 'task/list.html', context)


def updatingTask(request, pk):
    task = Task.objects.get(id=pk)

    form = TaskForm(instance=task)

    if request.method == 'POST':
        form = TaskForm(request.POST, instance=task)
        if form.is_valid():
            form.save()
            return redirect('/')

    context = {'form': form}

    return render(request, 'task/update.html', context)

def deleteTask(request, pk):
    item = Task.objects.get(id=pk)

    if request.method == 'POST':
        item.delete()
        return redirect('/')

    context = {'item': item}

    return render(request, 'task/delete.html', context)

Next is the urls.py, but the app doesn’t come with a urls.py, this is because we can do all our routing in the project’s urls.py or we can create a new one for the task folder. Let’s create it:

# task.urls.py

from django.urls import path
from . import views

urlpatterns = [
    path('', views.index, name='list'),
    path('update/<str:pk>/', views.updatingTask, name='update'),
    path('delete/<str:pk>/', views.deleteTask, name='delete'),
]

For the Django project to see it, it will need to be routed to the project’s URLs. Let’s do that:

# urls.py

from django.contrib import admin
from django.urls import path
from django.urls.conf import include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('', include('task.urls'))
]

Here, we just imported the module name include to help us include the app URLs.

Next, Let us create form.py:

from django import forms
from django.forms import ModelForm

from .models import *


class TaskForm(forms.ModelForm):

    class Meta:
        model = Task
        fields = '__all__'

from django.contrib import admin
from .models import Task

# Register your models here.


admin.site.register(Task)

The last path is our HTML files:

List.html

# list.html

<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/semantic-ui/2.4.1/semantic.min.css" />

<style>
    body {
        width: fit-content;
        margin: 20px auto;
    }
</style>

<div>
    <h3>Todos</h3>

    <form method="POST" action="/" class="ui form">
        <div class="ui field action input" style="width: 525px;">
            {% csrf_token %} {{form.title}}
            {% if form.title %}
            <input type="submit" name="Create Task" class="ui primary button" />
            {% else %}
            <input type="submit" name="Update Task" class="ui primary basic button" />
            {{ form.complete }}
            {% endif %}
        </div>
    </form>


    {% for task in tasks %}
    <div class="ui segment" style="width: 600px;">
        {% if task.complete == True %}
        <strike>{{ task }}</strike>
        {% else %}
        <p>{{task}}</p>
        {% endif %}
        <div class="right-align">
            <a href="{% url 'update' task.id %}" class="ui secondary basic button ">Update</a>
            <a href="{% url 'delete' task.id %}" class="ui negative basic button right hide-on-med-and-down">Delete</a>
        </div>
    </div>
</div>

{% endfor %}
</div>

Update.html

Next, let’s update the update.html by pasting the following code:

# update.html

<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/semantic-ui/2.4.1/semantic.min.css" />

<style>
    body {
        width: fit-content;
        margin: 20px auto;
    }

    form {
        margin: 0 5px;
    }
</style>

<h3>Update Task</h3>

<form method="POST" action="" class="ui form">
    <div class=" ui field action input">
        {% csrf_token %}

        {{ form }}

        <input type="submit" name="Update Task" class="ui primary basic button" />

    </div>
</form>

Delete.html

Lastly, let’s update the detele.html by pasting the following code:

<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/semantic-ui/2.4.1/semantic.min.css" />

<style>
    body {
        width: fit-content;
        margin: 50px auto;
    }

    form {
        float: right;
    }
</style>

<p class=" container">Are you sure you want to delete " {{item}}"?</p>

<div>
    <a href="{% url 'list' %}" class="ui secondary basic button">Cancel</a>

    <form method="POST" action="">
        {% csrf_token %}

        <input type="submit" name="Confirm" class="ui negative basic button" />
    </form>
</div>

Everything is fine, let’s run our migration:

python manage.py migrate

Testing the app

And also start the development server with this command:

python manage.py runserver

Your app should be running on http://127.0.0.1:8000/. If you visit the URL, you should be presented with the webpage below, if you set up everything correctly.

Conclusion: Django

This Django tutorial explains the fundamentals of creating an application with Django using Django function-based views, MySQL database, and deployed to Heroku.

This is just the basics of Django. There are so many, and no better place to go than Django’s official documentation.

*To learn Django in detail, there is no better course to recommend personally than Full stack web development and AI with Python (Django). Check it out now for a discount.*

Let us know in the comment if you have any challenges, and we will fix them together.

Thank you

Author: Solomon Eseme

Thank you for being a part of the community

Before you go:

Whenever you’re ready

There are 4 ways we can help you become a great backend engineer:

The MB Platform: Join thousands of backend engineers learning backend engineering. Build real-world backend projects, learn from expert-vetted courses and roadmaps, track your learnings and set schedules, and solve backend engineering tasks, exercises, and challenges.
The MB Academy: The “MB Academy” is a 6-month intensive Advanced Backend Engineering BootCamp to produce great backend engineers.
Join Backend Weekly: If you like posts like this, you will absolutely enjoy our exclusive weekly newsletter, sharing exclusive backend engineering resources to help you become a great Backend Engineer.
Get Backend Jobs: Find over 2,000+ Tailored International Remote Backend Jobs or Reach 50,000+ backend engineers on the #1 Backend Engineering Job Board.

Top 5 backend frameworks

Toluwanimi — Tue, 12 Aug 2025 11:00:30 +0000

Hey guys, so am super excited today to share with you my top 5 “backend frameworks” as a backend developer you can start learning now or even in the future to come.

As you also know, I discuss and write articles mainly about backend developments, so in this article am going to show my top 5 “backend frameworks” based on my personal research and experiences.

Laravel
Express
Spring
Django
ASP.net Core

Am going to explain the “backend frameworks” from the bottom-top approach.

ASP .NET CORE:

ASP .NET Core is a lean and composable framework for building web and cloud applications. ASP .NET Core is fully open-source and available on GitHub it includes the latest features and innovations in MVC.

Its also a significant redesign of ASP .NET, This framework is very popular amount enterprises and companies who use the C# and windows products.

So learning ASP .NET Core now is very relevant and definitely worth the time.

DJANGO:

Django is a high — level python web framework that encourages rapid development and clean, pragmatic design, built by experienced developers, it takes care of much of the hassle of web development, so you can focus on writing your application without needing to reinvent the wheel.

Python which happens to be the easiest programming language to learn has been getting lots of traction, becoming the most popular and in-demand language after JavaScript in some cases recently, therefore, making Django a good sort after skills in the web industry.

SPRING FRAMEWORK:

The spring framework is an application framework and inversion of control container for the java platform.

The framework’s core features can be used by any java application. Although the framework does not impose any specific programming model, it has become popular in the Java community.

Because of the popularity of Java as a programming language and the number of devices that run it, it makes Spring framework very popular among the Java Enterprises community.

So if you are a Java developer learning the Spring framework is a plus to your career.

EXPRESS:

Express is a web application framework for NodeJS. It is designed for building web applications and APIs.

Because of the current rise of JavaScript and the trending nature of NodeJS (a JavaScript run-time environment).

Express has become a very popular and high demand skill as a backend developer.

LARAVEL:

Laravel is a PHP framework for web artisans. It’s a free, open-source PHP framework intended for the development of web applications following the MVC pattern and based on Symfony.

We all know that PHP powers about 78.9% of all websites on the web, so the PHP programming language is vastly used for both enterprise and start-up web apps.

By the way, if you’re just STARTING out with Laravel, I have created a Complete Laravel Guide just for you.

It’s also the most preferred language for startups, these statistics make Laravel even more popular and eventually the best backend framework to learn as a backend developer in my opinion.

WRAPPING UP

Thanks for reading my top 5 backend frameworks that you can learn now or in the future.

Everything I have listed above is from my personal experience.

So those are my top 5 backend frameworks. This list is not complete until you add or remove from it. So let me hear your thought in the comment section below.

If you enjoy this post make sure you share it with your friends.

If you are interested in backend development (or you’re internet enthusiast) both (Mobile | Web | Desktop) subscribe to my Youtube channel, we will be posting a collection of help full tutorials and guides like this one for artisans.

Author: Solomon Eseme

Thank you for being a part of the community

Before you go:

Whenever you’re ready

There are 4 ways we can help you become a great backend engineer:

The MB Platform: Join thousands of backend engineers learning backend engineering. Build real-world backend projects, learn from expert-vetted courses and roadmaps, track your learnings and set schedules, and solve backend engineering tasks, exercises, and challenges.
The MB Academy: The “MB Academy” is a 6-month intensive Advanced Backend Engineering BootCamp to produce great backend engineers.
Join Backend Weekly: If you like posts like this, you will absolutely enjoy our exclusive weekly newsletter, sharing exclusive backend engineering resources to help you become a great Backend Engineer.
Get Backend Jobs: Find over 2,000+ Tailored International Remote Backend Jobs or Reach 50,000+ backend engineers on the #1 Backend Engineering Job Board.

Rust Programming: The Ultimate Guide (2023)

Toluwanimi — Mon, 11 Aug 2025 11:00:30 +0000

Rust programming language brings to the table, new and opinionated ways of doing things.

Concepts such as the Borrow Checker sound new to most developers coming from Garbage-Collected languages such as Go, Javascript, and Python.

In place of Garbage-Collection, Rust programming language allows the developer to make the choices of memory management with concepts such as Ownership and Borrowing.

The Borrow Checker, which most Rust developers would fight every now and then, ensures memory safety, a foreign concept to core C and C++.

Chapter 2: Advanced Rust Concepts

Next, we’d want to call the function that handles user input in accordance with the previously initialized variables.

We’ll momentarily leave the main function and head to the handle_input function:

Before we do that, let’s take a look at the concept of Ownership and Borrowing in Rust

Ownership

Take a look at this short snippet:

fn main() { //for brevity sake, we won’t specify this main function in subsequent snippets
    let hello = “hello”;
} // at this point, hello no longer exists.

By default, variables are block-scoped. Hello is an example of what we call a string literal: hardcoded string values.

let hello = String::from(“hello”);
let bye = hello;
println!(“{}”, hello); //the remaining arguments to the println macro are variables that would replace ‘{}’ in the string.

Running this code would throw an error(called panicking in Rust):

error[E0382]: borrow of moved value: `hello`
 --> main.rs:4:20
  |
2 |     let hello = String::from("hello");
  |         ----- move occurs because `hello` has type `std::string::String`, which does not implement the `Copy` trait
3 |     let bye = hello;
  |               ----- value moved here
4 |     println!("{}", hello);
  |                    ^^^^^ value borrowed here after move

error: aborting due to previous error

For more information about this error, try rustc --explain E0382.

This signifies a concept called Moving.

This means in Rust, an attempt to free unused memory, since both hello and bye are pointing to the same memory address, will invalidate the variable hello.

Any attempt to call the variable would result in an error. As a systems programming language with a focus on memory safety, this is a useful feature that prevents access to a memory address after it is no longer needed.

Rust performs a form of copying, known as shallow copying. This way, both variables reference the same thing.

In another example shown below:

let hello = String::from(“hello”);
let bye = “ and bye”;
let greeting = hello + bye;
println!(“{}. Again, {}? {}”, greeting, hello, bye);

Again, as expected, this code won’t compile. bye ceases to exist the moment it is used somewhere else.

The new variable takes ownership of bye and bye ceases to exist. hello on the other hand, has no problems with this. This is because, due to the use of String::new(), the size of hello is known at compile-time, therefore, there’s no deep or shallow copying here.

Using the code above, we can solve this problem by performing explicit deep copying like so:

let hello = String::from(“hello”);
let bye = hello.copy();
println!(“{}”, hello);

This time we’d have no errors since the underlying data is copied to bye and ownership of bye isn’t performed.

Borrowing

How about functions?

How do we pass arguments into functions and still reuse the variables? Rust has some sort of pointer-like magic called Borrowing.

With it, we can pass to functions, references to variables and access underlying data, and even mutate it (as we’ll see in the handle_input function).

Let’s go on to create the handle_input function and learn Borrowing from it:

fn handle_input(var: &mut String) → i32 {
    io::stdin()
        .read_line(var)
        .expect("Failed to read line");

    var.chars()
        .count()
        .try_into()
        .expect("Length of name is too large!")
}

The function accepts a funny argument type, &mut String. You’ll probably recognize it as expecting a mutable String as an argument, but it goes farther than that:

The & sign indicates that the function is expecting a reference to that data type since we’d like to mutate its value rather than take ownership of it as Rust would normally expect.

This concept is called Borrowing.

At the end of the function’s execution, control of the memory address is returned back to the initial variable.

So, we call the stdin method of the io module for input-related functionalities, read_line does the magic of passing the user input into the variable specified.

The expect method is used for error propagation:

There are cases where we’d want our function to return an error type to the calling code to handle if an error occurs while performing an operation.

The expect function (similar to unwrap ) allows us to specify a custom message for the panic (as exceptions are called in Rust).

While unwrap would instead return the error to the calling code without a custom message.

Return value (data types)

The handle_input function has a return type of i32, which is a signed 32-bit integer.

Other integer data types include i8, i16, i64, i128 for signed integers of 8, 16, 64 and 128 respectively.

Unsigned integer types are of the u prefix with variants such as u8, u16, u32, u64, and u128 with their obvious precision levels.

For floating-point values, only two types are available: f32 and f64 for 32 and 64-bit precision respectively.

Taking a look at the return value snippet:

var.chars()
        .count()
        .try_into()
        .expect("Length of name is too large!")

The chars method first breaks the text given by the user into an array of individual characters, count gives its count with a type of usize, an integer type for the size of data in Rust.

The try_into function on the other hand attempts to convert usize type into i32.

You would notice that try_into automatically knows the type we need due to the function’s return type – another Rust magic.

Finally, we wrap it all with an expect for possible errors that might occur.

Back to the main function

At this point, we can then attempt to call the function and initialized our variables like so:

println!(“Enter first person name: “);
let name1_count = get_input(&mut name1);

println!(“Enter second person name: “);
let name2_count = get_input(&mut name2);

Matches

Next, we’ll need a function to compute the compatibility:

fn calculate_compatibility(name1_count: i32, name2_count: i32) → f32 {
    match name1_count.cmp(&name2_count) {
        Ordering::Less => {
            ((name1_count as f32 / name2_count as f32) as f32 * 100.0) as f32
        },
        Ordering::Greater => {
            ((name2_count as f32 / name1_count as f32) as f32 * 100.0) as f32
        },
        Ordering::Equal => {
            50.0
        }
    }
}

Since we’ll be doing a bit of arithmetic, the function should be returning a float type.

Next, we compare both values to see which is higher. To do that, instead of the if statement with a syntax of:

if <condition> {
    block of code
} else if <condition> {
    block of code
} else {
    block of code
}

We’ll be making use of match, since the comparison of two number in Rust yields a data type rather than a boolean:

match name1_count.cmp(&name2_count) {
    Ordering::Less => {
    },
    Ordering::Greater => {
    },
    Ordering::Equal => {
    }
}

A match statement is made up of match followed by a type, or an operation that returns a type. In the block of code following, it is arms with pathways of code to run depending on what type is expected.

With this functionality of types returned for comparison, we have to bring into scope, the types expected to be returned with the statement:

use std::cmp::Ordering;

We’re done! We’ll compile and run our program with cargo run in the code directory.

Alas! We have an error:

error[E0599]: no method named `try_into` found for type `usize` in the current scope
  --> src/main.rs:10:25
   |
10 |     var.chars().count().try_into().expect("Length of name is too large!")
   |                         ^^^^^^^^ method not found in `usize`
   |
   = help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a `use` for it:
   |
1  | use std::convert::TryInto;
   |

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
error: could not compile `love_calculator`.

Something about traits.

A not very useful example

So, what are traits? Well, traits are a way Rust says: Inheritance.

As codebase increases, we notice that some structs seem to have similar characteristics, and it is important that future structs with such characteristics should be able to perform actions these structs can do.

An example, as culled from the Rust documentation will be used. Let’s say we’re implementing Tweets like so:

struct Tweet {
    username: String,
    content: String,
    location: String,
    retweet: bool,
}

We might want to implement a summarize method that displays a short form of the tweet:

impl Tweet {
   fn summarize(&self) → String {
    if self.retweet {
        format!(“{} retweeted: {} while in {}”, self.username, self.content, self.location)
    else {
        format!(“{} tweeted: {} while in {}”, self.username, self.content, self.location)
        }
    }
}

Consider another code where we implemented a news article like so:

struct Article {
    title: String,
    author: String,
    content: String,
}

and need to implement a summarize method. While we could as well implement it as a separate method:

impl Article {
    fn summarize(&self) → String {
        format!(“{} posted an article title: {}”, self.author, self.title)
    }
}

we could standardize our code by creating a trait both structs could implement. This way, we can ensure consistency when working with different structs with similar functionality.

So our trait is implemented like so:

trait Summary {
    fn summarize(&self) → String
}

Next, we attach the trait to our structs and implement the methods since it would be enforced anyway:

// for Tweet
impl Summary for Tweet {
    fn summarize(&self) → String {
        if self.retweet {
            format!(“{} retweeted: {} while in {}”, self.username, self.content, self.location)
        else {
            format!(“{} tweeted: {} while in {}”, self.username, self.content, self.location)
        }
    }
}

// for Article

impl Summary for Article {
    fn summarize(&self) → String {
        format!(“{} posted an article title: {}”, self.author, self.title)
    }
}

Then we can call our methods:

fn main() {
    let tweet = Tweet {
        String::from(“Lord_Sarcastic”),
        String::from(“Hello, world! Bye, world!”),
        String::from(“Lagos”),
        false
    }

    let article = Article {
        String::from(“Python and Rust?”),
        String::from(“Lord_Sarcastic”),
        String::from(“Python and Rust make a good match”)
    }

    println!(“Tweet summary: ‘{}’”, tweet.summarize());
    println!(“Article summary: ‘{}’”, article.summarize());
}

A very useful example

With traits, we could also have a default implementation for methods. As an example, if we wanted a display method that made use of the summarize method under the hood, we could have a trait like so:

trait Summary {
    fn summarize(&self) → String;

    fn display(&self) → String {
        format!(“Summary: {}”, self.summarize())
    }
}

At this point, both structs can call display without having implemented methods for it, but summarize must be implemented for it to work.

Lest we go offtrack…

Why this? The thing is for us to use functionalities that involve traits, the trait has to be in scope.

We can see that the Rust compiler insists that we bring a trait into scope before it would allow type conversion. That can be fixed with a simple line:

use std::convert:TryInto;

At this point, you’ll see that there are two ways we call methods:

type.method(): This is for instance methods – methods bound to a specific instance of the type.
type::method(): This is for static methods – methods that are bound to the type itself and do not need self(the instance reference) as a parameter.

As mentioned earlier, Rust uses Structs and Enums for data abstractions. A struct is represented syntactically like so:

struct User {
    username: String,
    first_name: String,
}

And then methods for this struct is done with the impl keyword:

impl User {
  fn new(username: String, first_name: String) → User {
   User {
    username,
    first_name
    }
}

 fn say_name(&self) → {
   println!(“{} name is {}”, self.username, self.first_name);
 }
}

As you can guess, new is a static method, while say_name is an instance method.

Enums on the other hand are used to group similar structs under an abstraction.

For example, if we wanted to extend the User struct to contain a gender field, we could implement a gender structs like so:

struct Male {
    symbol: u8,
}

struct Female {
    symbol: u8,
}

and then group them under a gender enum like so:

enum Gender {
    Female,
    Male,
}

Our User struct can then make use of this abstraction like so:

struct User {
    username: String,
    first_name: String,
    gender: Gender,
}

Accessing structs associated with an enum is done with the :: operator.

Going back to the Ordering Code above, we can see that Ordering is an enum with struct types: Less, Greater, and Equal.

When the comparison is done with the cmp method, the method yields one of these types, we can then take advantage of the graceful match syntax to perform our calculations based on these types:

Ordering::Less => {
    ((name1_count as f32 / name2_count as f32) as f32 * 100.0) as f32
},
Ordering::Greater => {
    ((name2_count as f32 / name1_count as f32) as f32 * 100.0) as f32
},
Ordering::Equal => {
    50.0
}

Since we’ll be working with fractions here, it’s important to switch data types to floating values in order to maintain precision.

This is done using the as keyword. We have to cast all values into the f32 type before our code works successfully.

For the Equal arm, we also have to make 50 as a floating-point value to match the return type. It’s easy to miss.

Return value(match)

Since we have one-liner operations as a resolved value, we do not need the return keyword. The values would be returned implicitly due to the lack of a semicolon as a delimiter.

Back to main(the end?)

We can head back to the main function and call the calculate_compatibility function and display the results:

let compat_value = calculate_compatibility(name1_count, name2_count).floor();

println!("Love compatibility between {} and {} is {}%", name1.trim(), name2.trim(), compat_value);

The trim method removes whitespace characters at the beginning and end of the string.

Chapter 3: Building with Rust

Installing Rust is quite easy. Head to the official website https://www.rust-lang.org/tools/install and follow the steps.

From your CLI, confirm your installation with rustc –-version and cargo –-version

The former is the standard Rust tool for compiling and executing your code.

The latter is an abstraction that provides common tools needed by developers to organize their code and other external libraries.

You also get a linter: clippy, and a nice way to run tests for your code.

We all had our own shares of love plays while young. Perhaps you remember the popular “flames” method.

Here we’ll be using a basic formula to derive compatibility percentages:

(length_of_shorter_name/length_of_longer_name) × 100

Pseudocode:

Rust way of doing things diverges from the other languages, hence the need for pseudocode to outline steps in our code.

This program calculates the love compatibility of a male and a female with their names as input:

function handle_input(arg: memory_address_to_store_input) {
    * accepts `memory address` *
    * returns nothing *

    request input from user
    trim whitespace from user input
    store cleaned input into `arg`

    returns the length of the input
}

function calculate_compatibility(name1: String, name2: String) {
    * accepts Strings for both input *
    * returns number as percentage *
    if length of name1 > length of name2:
        percentage = (length of name2 ⁄ length of name1) x 100
    else if length of name2 > length of name1:
        percentage = (length of name1 ⁄ length of name2) x 100
    else: * lengths are equal *
        percentage = 50
}

function main() {
    initialize `name1` as string
    initialize `name2` as string

    name1_count = handle_input(memory address of name1)
    name2_count = handle_input(memory address of name2)

    compatibility =  calculate_compatibility(name1_count, name2_count)

    print compatibility
}

Code

First, we’ll use cargo to initialize our project. Cargo will help manage compilation and other nitty-gritty things involved in running out of code.

To initialize, head to the terminal and type:

cargo new love_calculator

The main function

use std::io;

fn main() {
    let mut name1 = String::new();
    let mut name2 = String::new();
}

The first line of our program would involve bringing functionality from the standard library into scope.

The io module as explained in its documentation “… contains a number of common things you’ll need when doing input and output”.

As with many C-like languages, the entry point of any Rust program is the main function. Declaring a function uses the keyword fn and the name of the function.

It has a syntax like so:

fn function_name(arg1: type, arg2: type, ...argn: type) → return_type {
    function body; //statements end in a semicolon
    return value    //return values do not require a semicolon or the ‘return’ keyword. If you need a semicolon, perhaps as part of a logic, you can then use the return keyword
}

In the absence of a return type, Rust implicitly returns what is called the Unit Type, written as Ok().

The concept of Null does not exist in Rust, instead, Rust represents it with a type called None as showing the absence of a value. Its counterpart is Some which could be used to wrap any data type.

In the main function, we declare two variables, name1 and name2 using the let keyword as:

Being mutable, with the mut keyword;
As a String: There are two types of strings you’ll encounter in Rust, the other is a string literal.

As with many other languages, the new method is used to initialize an instance of an object or Struct in this case.

Rust makes use of Structs and Enums as opposed to objects and classes for abstracting data.

We’ll be taking a closer look at these two concepts later on.

Right now, let’s get the our actual Love Calculator Code out of the way.

Below is the code that will produce our love calculator in Rust based on the name input of the user.

use std::cmp::Ordering;
use std::convert::TryInto;
use std::io;


fn get_input(var: &mut String) -> i32 {
    io::stdin()
        .read_line(var)
        .expect("Failed to read line");

    var.chars()
        .count()
        .try_into()
        .expect("Length of name is too large!")
}

fn calculate_compatibility(name1_count: i32, name2_count: i32) -> f32 {
    match name1_count.cmp(&name2_count) {
        Ordering::Less => {
            ((name1_count as f32 / name2_count as f32) as f32 * 100.0) as f32
        },
        Ordering::Greater => {
            ((name2_count as f32 / name1_count as f32) as f32 * 100.0) as f32
        },
        Ordering::Equal => {
            50.0
        }
    }
}


fn main() {
    let mut name1 = String::new();
    let mut name2 = String::new();

    println!("Enter first person name: ");
    let name1_count = get_input(&mut name1);

    println!("Enter second person name: ");
    let name2_count = get_input(&mut name2);

    let compat_value = calculate_compatibility(name1_count, name2_count).floor();

    println!("Love compatibility between {} and {} is {}%", name1.trim(), name2.trim(), compat_value);
}

Now, let’s move down to explaining each of the concepts used in the code below to get a clearer understanding of how Rust handles certain programming concepts.

The final code listing looks like this:

use std::cmp::Ordering;
use std::convert::TryInto;
use std::io;


fn get_input(var: &mut String) -> i32 {
    io::stdin()
        .read_line(var)
        .expect("Failed to read line");

    var.chars()
        .count()
        .try_into()
        .expect("Length of name is too large!")
}

fn calculate_compatibility(name1_count: i32, name2_count: i32) -> f32 {
    match name1_count.cmp(&name2_count) {
        Ordering::Less => {
            ((name1_count as f32 / name2_count as f32) as f32 * 100.0) as f32
        },
        Ordering::Greater => {
            ((name2_count as f32 / name1_count as f32) as f32 * 100.0) as f32
        },
        Ordering::Equal => {
            50.0
        }
    }
}


fn main() {
    let mut name1 = String::new();
    let mut name2 = String::new();

    println!("Enter first person name: ");
    let name1_count = get_input(&mut name1);

    println!("Enter second person name: ");
    let name2_count = get_input(&mut name2);

    let compat_value = calculate_compatibility(name1_count, name2_count).floor();

    println!("Love compatibility between {} and {} is {}%", name1.trim(), name2.trim(), compat_value);
}

The final code can be gotten here, a repo of mine dedicated to learning Rust and its paradigms.

More Resources

Official Documentation
Introduction to Rust
RUST Beginners Tips & Tricks Guide 2020
Learing Rust
Ultimate Rust Crash Course is among the best courses for Rust programming language. The instructor explaining complex terms with ease and aid the understanding of the language.
Learn Rust by Building Real Applications takes you to build real-life applications using the Rust programming language. If you’re looking at getting your hands duty with projects, this course is definitely for you.

Conclusion:Rust

Despite its fame as a systems language, we’ve succeeded in using Rust for trivial tasks such as building a Calculator.

Rust programming language is used in other domains besides love calculators, such as servers, compilers, web application back-end, WASM(web assembly), and anything you’d write with a programming language.

If you want to dive into Rust programming language, as we didn’t touch many important concepts, you’d want to check out the official documentation.

Author: Solomon Eseme

Thank you for being a part of the community

Before you go:

Whenever you’re ready

There are 4 ways we can help you become a great backend engineer:

The MB Platform: Join thousands of backend engineers learning backend engineering. Build real-world backend projects, learn from expert-vetted courses and roadmaps, track your learnings and set schedules, and solve backend engineering tasks, exercises, and challenges.
The MB Academy: The “MB Academy” is a 6-month intensive Advanced Backend Engineering BootCamp to produce great backend engineers.
Join Backend Weekly: If you like posts like this, you will absolutely enjoy our exclusive weekly newsletter, sharing exclusive backend engineering resources to help you become a great Backend Engineer.
Get Backend Jobs: Find over 2,000+ Tailored International Remote Backend Jobs or Reach 50,000+ backend engineers on the #1 Backend Engineering Job Board.

Top 5 Python Backend Projects to Boost Your Skills in 2025

Toluwanimi — Tue, 05 Aug 2025 11:00:30 +0000

Python is an incredible programming language that is easy to pick up for both beginner and experienced Programmers alike. It boasts of a relatively straightforward syntax, powerful libraries and extensive community support. Unfortunately however, Python when mentioned in today’s developer circles generally has backend developers not

particularly enthusiastic especially when compared to languages like Go, Rust, or Node.js, due to its relatively slow performance and has been dismissed by some as the “data science language”. This however, overlooks one key truth: Python excels in backend development especially when paired with the right tools. In this article, we’ll explore five powerful backend projects you can build using Python to sharpen your skills, improve your portfolio, and learn core backend concepts like asynchronous programming, API design, and job queues.

Project 1: Real-Time Chat App with WebSockets

In a world smitten by connection and interaction, a real-time chat app is a wonderful opportunity to showcase backend prowess and innovation as it deals with concepts that are cornerstones of the backend process such as user authentication, message history, real-time data and data manipulation, persistence and websockets handling. This project when done correctly exposes one to healthy bouts of asynchronous programming in live communication which is deeply relevant today. Popular tool choices may be FastAPI, Django and Redis for persistence. You could try

making your chat app standout with suitable concepts that reflect your

personality such as a chat app for introverts which is bound to scale since introverts would rather chat than call anyway.

Project 2: Machine Learning Serving Backend

It is no secret that Python is a popular choice when it comes to machine learning tasks and projects. Backend infrastructure and development is also important in such projects for actions such as uploading files, logging requests, handling timeouts and

receiving predictions. This makes the backend useful in introducing machine

learning inference APIs and for data handling. Good tools that prove invaluable here are Pydantic, Docker and FastAPI.

Project 3: Notification System and Job Queue

Any notification system is an interesting undertaking with Python. Here we are faced with scalable architecture and message-based workflows as well as queued tasks, job workers and retry logic - definitely in the arena of backend development. Python makes

this a worthwhile venture with tools like Flask and FastAPI in conjunction with Celery, Redis and SMTP.

Project 4: Podcast Platform Backend

If you’ve ever been impressed by your favorite podcast platforms so much that you have tried to understand their inner workings from the perspective of the backend, you could accomplish that using Python. This project may be considered a bit complex because it is a capsule of a number of features that include streaming audio, managing media uploads, user subscriptions and comment systems. You’ll also get to explore concepts like rate limiting and RSS feed generation. If you want to show off your file handling and scalable API skills it is a great project to build. Tools that may come in handy here are FastAPI, PostgreSQL, AWS S3 and Json Web Tokens (JWT).

Project 5: Blogging Platform

This blogging platform project constitutes a platform with very real world scenarios and consequences. Features could include authentication and authorization, admin roles, image upload, markdown support, multiple user handling and more. It is a safe haven of backend development made possible by Python tools such as Django and PostgreSQL. The good thing about this is that backend complexity grows with scale. You could add caching, tag filtering and permissions. It is favored by backend developers for personal projects because it is flexible enough to allow varying complexities for any skill level.

Conclusion

These five projects represent just a small glimpse of what you can build with Python on the backend. While there’s no absolute ranking of the “top” backend projects, each one featured here was selected because it challenges you to apply real-world backend development concepts, such as asynchronous communication, API design, job queues, and authentication. What makes a project truly valuable isn’t popularity, it’s how much it aligns with your learning goals and career path.

So if you're building your portfolio, preparing for job interviews, or just curious about backend architecture, keep experimenting. Python’s flexibility and powerful ecosystem make it one of the best languages to explore and master backend development.

Ready to go further? Explore more Python backend project ideas, contribute to open-source, or scale these five to production level.

Author: Amanda Adoyi

Thank you for being a part of the community

Before you go:

Whenever you’re ready

There are 4 ways we can help you become a great backend engineer:

The MB Platform: Join thousands of backend engineers learning backend engineering. Build real-world backend projects, learn from expert-vetted courses and roadmaps, track your learnings and set schedules, and solve backend engineering tasks, exercises, and challenges.
The MB Academy: The “MB Academy” is a 6-month intensive Advanced Backend Engineering BootCamp to produce great backend engineers.
Join Backend Weekly: If you like posts like this, you will absolutely enjoy our exclusive weekly newsletter, sharing exclusive backend engineering resources to help you become a great Backend Engineer.
Get Backend Jobs: Find over 2,000+ Tailored International Remote Backend Jobs or Reach 50,000+ backend engineers on the #1 Backend Engineering Job Board.

Laravel Tutorial:The Ultimate Guide (2023)

Toluwanimi — Mon, 04 Aug 2025 11:00:30 +0000

Introduction

In this laravel tutorial, you will learn how to use the most popular PHP framework Laravel.

This tutorial will teach you Laravel from scratch to an advanced level, you will learn how to install Laravel, how to set up database connectivity, how to create a full-blown application, and deploy it to HEROKU.

Before we delve in, if you’re a backend developer or looking at delving into this career path, join other developers to receive daily articles on backend development that will boost your productivity.

Start Learning Backend Dev. Now

Stop waiting and start learning! Get my 10 tips on teaching yourself backend development.

Get the tips!

Don't worry. I'll never, ever spam you!

What is Laravel?

Laravel Framework is an open-source PHP MVC framework for building simple to complex web applications. Laravel strictly follows the MVC (Model-View-Controller) architectural pattern. it is known for its beautiful and elegant syntax as a web framework.

Features of Laravel

Laravel has many great features of web development built in such as:

One of the best routing system in PHP.
It has the Service Container for easy dependency Injection.
Built-in authentication mechanism with Logic, Registration, etc processes built-in.
One of the best ORM called Eloquent for handling database connection, migration, and queries easily.
Easy to use a templating engine called Blade and also integrations with popular Frontend frameworks like Vue, React out of the box.
Building real-time applications with Laravel is made very easy with real-time event broadcasting.

Why you should learn Laravel?

There are many reasons why you should learn the Laravel framework, in this tutorial, we will just only point out a few:

Laravel follows strictly web/software development best practices and industry standards forcing you to master them while you work with the framework.

As mentioned above, PHP is used in up to 79.1% across the internet making Laravel a top choice for developers.

With Laravel, you can build simple to complex projects faster using the Rapid Application Development practices and approach.

Laravel has one of the most beautiful and elegant syntax making the codebase easy to understand.

It also very easy to spin a microservice with Laravel API and maybe Vue ad the frontend framework.

Vuejs and Laravel are well integrated together making them a perfect couple for faster or rapid application development.

That’s obviously enough reason why you should learn Laravel, let’s try to compare Laravel with other PHP frameworks. You know you’re not making a mistake choosing to learn Laravel.

Laravel Framework vs Other Framework

Comparing Laravel with other PHP frameworks shows that Laravel is one of the top PHP frameworks with a total of 52.8% priority, Phalcon 16.7%, Symfony has 10.6%, etc. You can read more here.

What makes Laravel to have these high priorities, well, Laravel supports the following out of the box.

Advanced Authentication and Authorisation techniques
The Artisan CLI of Laravel is one of the magic and a great tool of the framework.
Advanced and strictly support the MVC architectural pattern.
The complexity of Database migration and management is made very simple with Eloquent ORM
Following the OWASP security model out of the box.

Now you have a complete overview of Laravel Framework, Let’s dive right into the framework itself.

When it comes to learning Laravel, I will personally and highly recommend _these 3 courses. With it, I was able to learn and start building projects within a week._

Laravel 8 Beginner to Advance with Complete News Portal

PHP with Laravel for beginners – Become a Master in Laravel

Laravel 2019, the complete guide with real world projects

Chapter 2:Laravel The Framework

In this chapter, the tutorial will explore a little about the Laravel framework.

We will discuss the structure of the framework and how the MVC pattern is used to structure the Laravel framework in this tutorial.

This tutorial will discuss the 3 important elements/components of MVC and how Laravel utilizes them.

Finally, we will discuss the Models, Views, and Controllers.

If you’re excited as I am, let’s dive right in.

This tutorial will discuss the 3 important elements/components of MVC and how Laravel utilizes them.

Finally, we will discuss the Models, Views, and Controllers.

If you’re excited as I am, let’s dive right in.

As you may have noticed already, Laravel strongly follows the MVC architectural pattern.

What is MVC?

MVC (Model-Views-Controller) is a design pattern in software development that divides the logic of the program into 3 interconnected elements.

These 3 elements are called, you guess Model, Views, Controllers

The internal structuring of Laravel follows this design pattern.

Let’s explore how?

Models:

This is the central component of the pattern, or in Laravel, the model class contains all the methods and attributes needed to interact with the database schema specified for it.

For example, assuming we have a User table in our database, in Laravel, the corresponding Model will be called User where you will be able to operate on the database table (users) as if the schema is just a plain PHP object.

Views:

Views represent how the Information is displayed, it is used for all the UI logic of the software. You are right if you say that the View represents the Frontend of your web page.

This is how users interact with your application, sends inputs to the Model, and receive output from the Model too.

In Laravel, the View part is very customizable and lots of the job has been done out of the box to give you a good look and feel when working with Laravel.

Laravel uses the Blade template to present the View of your application and you can easily customize Laravel to work with other Frontend libraries like Vue, React, and even Angular.

Controllers:

Controllers act as a middleman between Models and Views, it processes all the inputs sent by the user from the View.

It processes all the business logic and incoming requests, manipulates data using the Model component, and interacts with the Views to render the final output.

In Laravel, Controllers are like the chief executors because everything you do revolves around them, from handling incoming requests, handling validating to manipulating data in the database using the Model component to sending the output to the Views component to render the final output.

Now that we have a clear understanding of the structure of Laravel, I will add that every other thing you might notice in Laravel like Request, Response, Queues, Cache, etc revolves around these three components.

Let’s take a look at this diagram for a clearer picture:

From the diagram above, you can spot that the controller does all the job and calls out to the individual components (Model) needed to achieve a particular task before sending the output to the View.

Now that we understand the inner workings of the Laravel Framework, let’s start building our first project following the structure from this tutorial:

When it comes to learning Laravel with courses, I will personally and highly recommend these 3 courses. With it, I was able to learn and start building projects within a week.

Laravel 8 Beginner to Advance with Complete News Portal

PHP with Laravel for beginners – Become a Master in Laravel

Laravel 2019, the complete guide with real world projects

Take a break and subscribe to get access to our free Laravel tips that will improve your productivity.

Chapter 3:Building an App with Laravel

Now that we understand the nitty-gritty of Laravel theoretically, let’s dive into the practicals by creating a real project.

If you’re just starting out creating applications with your computer, you need to install any of these packages and set them up properly (Wamp, Lamp, Mamp).

You can read through how to install and set them up properly here.

In this tutorial, we are going to demonstrate how to use Laravel to create a simple Todo application, with this we are going to explore how to set up Laravel, we will explore Laravel Requests and Responses, we will discuss the Controller component and how it interacts with Models and Views.

Setting up Laravel

A lot has changed in setting up Laravel since the release of the current version 8, you can get full details on how to install and set up Laravel here.

We are going to use the conventional way assuming you have composer installed already. We will create a todo-app with our Laravel installation, just run the following command:

composer create-project laravel/laravel todo-app

Next, change your directory to the current created directory:

cd todo-app

Open your project with any code editor of your choice, I will be using Visual Studio Code.

Lastly, run the following command to serve your webpage.

php artisan serve

Visit http://127.0.0.1:8000 in your browser to test your newly created Laravel project.

Cheers 🙂

Setting up Database

After installing Laravel, you almost do not need any additional set up except if you want to change timezones or other specific configurations, then you can review the config/app file to see the different configurations available.

But if you’re good with the defaults, let’s look at how to configure our database:

First, create a new database using any Database Client of your choice and note the login credentials.

Next, open the .env file (or create a new one if not exists), update the following information.

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=DB NAME HERE
DB_USERNAME=DB USERNAME HERE
DB_PASSWORD=DB PASSWORD HERE

In our case, we will stick with mysql database.

Setting up the Schema

The next step is to set up your database migrations and configure your database Eloquent Relationships.

Run the following command in the same terminal, to create a database schema file for our Todo table.

php artisan make:migration create_todos_table --create=todos

That command will create a new migration file inside database/migrations/xxx_create_todos_table.php, open it and paste in the following codes.


<?php
use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class CreateTodosTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('todos', function (Blueprint $table) {
            $table->id();
            $table->string('title');
            $table->text('desc')->nullable();
            $table->integer('status')->default(0);
            $table->integer('user_id');
            $table->timestamps();
        });
    }
    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('todos');
    }
}

Lastly, before you migrate the database, note that you can set up Database Seeders to generate fake data for your database, or clone my repository since I have configured database seeders already.

Now, run the migration:

php artisan migrate

Set up User Authentication with Laravel Breeze

Initially, setting up authentication without the use of packages can be tedious because you will have to code everything from Registration, Login to Forgot Password logic.

But with the use of Laravel Breeze, the authentication process is made very easy and less time-consuming.

Let’s install and set up our authentication process with minutes:

composer require laravel/breeze --dev

php artisan breeze:install

npm install

npm run dev

With these few commands, your authentication process is set, navigate to http://127.0.0.1:8000/register or http://127.0.0.1:8000/login, if you see the following screenshots then everything is properly set up.

All Laravel Breeze configuration can be found at config/auth.php, then all the Authentication logic is found in app/Http/Controllers/Auth, and all the UI interface files can be found at resources/views/auth.

You can start studying the authentication process from there.

Creating Models

If you look at the App folder, you might see a Models folder if Laravel 8 and a User.php file inside it or you might see User.php file inside the App folder.

That is exactly what a Model is:

Just a file that contains methods and properties to interact with our Database Schema, inside the User.php, you will notice that it extends (inherit) the Model parent class that is where all the methods and properties to interact with our Database Schema is coming from.

We can use the pre-defined User model to retrieve or create a new user in our application by providing the data needed in the User schema at database/migrations/xxxx_create_users_xxxx.php file.

Let’s take a look:

To retrieve all the users in our database, we will simply do:

$users = User::all();

foreach($users as $user){
  echo $user->name
}

To retrieve a particular user based on ID:

$user = User::find(1) // ID of 1

echo $user->name;

Create a new User (No need for SQL insert statement)

$user = new User;
$user->name = "Solomon Eseme";
$user->email = "test@example.com";
$user->password = "strongpassword";
$user->save();

By calling the save() method of the model instance, Laravel will either create a new User or update the existing User.

To delete a User from your Database, simply run:

$deletedUser = User::find(1)->delete();

Deleting a User is simply done by calling the delete method of the Model.

To retrieve Users with certain conditions, you can user the where method the Laravel Models

$users = User::where('email', '!=', '')->get();

foreach($users as $user){
  echo $user->name
}

Again, that will retrieve all the users that have email addresses added.

Now that we have a glimpse of what Laravel Models are, let’s create our own Todo Model to interact with the Todo schema we create above.

Open your project terminal and run the following command.

php artisan make:model Todo

The command will generate a new Todo Model inside app folder or app/Models folder (Laravel 8).

Open the file and go through it to see if the content is familiar from the User’s model we explored earlier.

You don’t need to do anything, for now, let’s move on to creating controllers.

Creating Controllers

Again, controllers are like the middleman between requests (views) and models.

When a user sends a request to your backend either by clicking a button or submitting a form, the request passes through the routes to the controller and the controller calls out to your model to serve the request and returns a response back to the user (View).

With this flow in mind, let’s create our first controller to handle any request for the Todos:

Run the following command in your project terminal to create a new controller.

php artisan make:controller TodosController

There are naming conventions in the official documentation, but any name will do.

The command above will create a controller file inside app/Https/Controllers, open the TodosController file and look at the generated content.

CRUD Controller

Next, we are going to create a CRUD operation to interact with our Model and serve the users of our application (Views).

Add the following codes to the newly created controller:

<?php
namespace App\Http\Controllers;
use Illuminate\Http\Request;
class TodosController extends Controller
{
    //
    public function index(Request $request)
    {
        # code...
    }
    public function show(Request $request, $id)
    {
        # code...
    }
    public function edit(Request $request)
    {
        # code...
    }
    public function update(Request $request)
    {
        # code...
    }
    public function create(Request $request)
    {
        # code...
    }
    public function store(Request $request)
    {
        # code...
    }
    public function delete(Request $request)
    {
        # code...
    }
}

This is just a skeleton of how the controller will look like. Now, let’s fill in the content of each method.

A complete code for our controller will look like this:

<?php

namespace App\Http\Controllers;

use App\Models\Todo;
use Illuminate\Http\Request;
use App\Http\Controllers\Controller;
use Illuminate\Support\Facades\Auth;

class TodosController extends Controller
{
    //

    public function index(Request $request)
    {
        # code...

        $todos = Todo::all();
        return view('dashboard')->with(['todos' => $todos]);
    }

    public function byUserId(Request $request)
    {
        # code...

        $todos = Todo::where('user_id', Auth::user()->id)->get();
        return view('dashboard')->with(['todos' => $todos]);
    }

    public function show(Request $request, $id)
    {
        # code...
        $todo = Todo::find($id);
        return view('show')->with(['todo' => $todo]);
    }

    public function edit(Request $request, $id)
    {
        # code...
        $todo = Todo::find($id);
        return view('edit', ['todo' => $todo]);
    }

    public function update(Request $request, $id)
    {
        # Validations before updating
        $todo = Todo::where('user_id', Auth::user()->id)->where('id', $id)->first();

        if ($todo) {
            $todo->title = $request->title;
            $todo->desc = $request->desc;
            $todo->status = $request->status == 'on' ? 1 : 0;
            if ($todo->save()) {
                return view('show', ['todo' => $todo]);
            }
            return; // 422
        }

        return; // 401
    }

    public function create(Request $request)
    {
        # code...
        return view('add');
    }

    public function store(Request $request)
    {
        # Validations before updating
        $todo = new Todo;
        $todo->title = $request->title;
        $todo->desc = $request->desc;
        $todo->user_id = Auth::user()->id;
        if ($todo->save()) {
            return view('show', ['todo' => $todo]);
        }

        return; // 422
    }

    public function delete(Request $request, $id)
    {
        # code...
        $todo = Todo::where('user_id', Auth::user()->id)->where('id', $id)->first();
        if ($todo) {
            $todo->delete();
            return view('index');
        }
        return; // 404
    }
}

As this is a beginner’s guide, there are lots we did not bother checking, like validations, clean code, errors, and others.

From the code above, you can see how we interact with our Todo model and serve the User’s request by calling the view method and passing on the HTML page we want the user to see.

For example, if a user clicks on our edit button, the request is sent to the edit method of the TodosController, then, the controller will find the particular Todo by ID (using the Todo model methods) and return back an Edit Form (HTML) filled with that particular Todo data to the user.

The Request object contains lots of Information about the current request the user is sending to our application but for now, we only used it to retrieve the data we need to create or update our Todo model.

To learn more about Requests, check here.

Creating Routes

Next, we are going to look at creating routes that map user’s requests to individual methods in any controller based on the user’s request.

When a user clicks on a button or submits a form, how does Laravel know which method to call or which controller to send the request to?

Well, everything is defined and mapped using a Routing System.

Laravel has an elegant routing system build in already:

Now, open the web.php file inside the routes folder and add the following codes:

Route::get('/login', function () {
    return view('welcome');
});

Route::get('/todos/mine', [TodosController::class, 'byUserId'])->middleware(['auth'])->name('mine');
Route::get('/todos/{id}/edit', [TodosController::class, 'edit'])->middleware(['auth'])->name('edit-form');
Route::get('/todos/create', [TodosController::class, 'create'])->middleware(['auth'])->name('create-form');
Route::post('/todos/{id}/update', [TodosController::class, 'update'])->middleware(['auth'])->name('update');
Route::post('/todos/add', [TodosController::class, 'store'])->middleware(['auth'])->name('add');
Route::get('/todos/{id}', [TodosController::class, 'show'])->middleware(['auth'])->name('show');
Route::delete('/todos/:id', [TodosController::class, 'delete'])->middleware(['auth'])->name('delete');

Route::get('/dashboard', [TodosController::class, 'index'])->middleware(['auth'])->name('dashboard');

require __DIR__ . '/auth.php';

You can see that each method in our TodosController is mapped onto a specific URL (route) in the webpage.

You can get more information about Laravel Routing System.

Creating Views

Dashboard view

The Dashboard view is the dashboard when a user successfully registers and login, it will present a list of all the Todos in our application and can also be sorted by individual todos.

Create a new blade file inside resources/views/dashboard.blade.php and paste in the following codes.

<x-app-layout>
    <x-slot name="header">
        <h2 class="font-semibold text-xl text-gray-800 leading-tight">
            {{ __('Dashboard') }}
        </h2>
    </x-slot>

    <div class="py-12">
        <div class="max-w-7xl mx-auto sm:px-6 lg:px-8">
            <div class="bg-white overflow-hidden shadow-sm sm:rounded-lg">
                <div class="p-6 bg-white border-b border-gray-200">
                    <x-button-link href="{{ route('create-form') }}">Add new todo</x-button-link>
                </div>
            </div>
        </div>
    </div>


    <div class="py-12">
        <div class="max-w-7xl mx-auto sm:px-6 lg:px-8">
            <div class="bg-white overflow-hidden shadow-sm sm:rounded-lg">
                <div class="p-6 bg-white border-b border-gray-200">
                    <div class="panel-bod">
                        <table class="table">

                            <!-- Table Headings -->
                            <thead>
                                <th>All Todos</th>
                                <th>&nbsp;</th>
                                <th>
                                    <x-button-link href="{{ route('mine') }}">Show mine</x-button-link>
                                </th>
                            </thead>

                            <!-- Table Body -->
                            <tbody class="max-w-full">
                                @foreach($todos as $todo)
                                <tr class="max-w-full">
                                    <!-- Task Name -->
                                    <td class="pt-5 pb-5 pr-5">
                                        <!-- <div class=""> -->
                                        <h1 class="sm:font-bold">{{ $todo->title }}</h1>
                                        <p>{{ $todo->desc }}</p>
                                        <p class="pt-2 text-gray-500"> Added By: {{ $todo->user->id == auth()->user()->id? 'You':$todo->user->name }}</p>
                                        <!-- </div> -->

                                    </td>

                                    <td>
                                        <!-- TODO: Delete Button -->
                                        <div>
                                            <x-button-link href="/todos/{{$todo->id}}" class="bg-green-500">View</x-button-link>
                                            @if($todo->user_id == auth()->user()->id)
                                            <x-button-link href="{{ route('edit-form', ['id'=>$todo->id]) }}" class="bg-yellow-500">Edit</x-button-link>
                                            <x-button-link href="/todos/{{$todo->id}}/delete" class="bg-red-500">Delete</x-button-link>
                                            @endif
                                        </div>
                                    </td>
                                </tr>
                                @endforeach
                            </tbody>
                        </table>
                    </div>
                </div>
            </div>
        </div>
    </div>
</x-app-layout>

Show view

The Show View displays only the information of a particular Todo when a user clicks to see more details.

Create a new blade file inside resources/views/show.blade.php and paste in the following codes.

<x-app-layout>
    <x-slot name="header">
        <h2 class="font-semibold text-xl text-gray-800 leading-tight">
            {{ __('Dashboard') }}
        </h2>
    </x-slot>

    <div class="py-12">
        <div class="max-w-7xl mx-auto sm:px-6 lg:px-8">
            <div class="bg-white overflow-hidden shadow-sm sm:rounded-lg">
                <div class="p-6 bg-white border-b border-gray-200">
                    You're logged in!
                </div>
            </div>
        </div>
    </div>

    <div class="py-12">
        <div class="max-w-7xl mx-auto sm:px-6 lg:px-8">
            <div class="bg-white overflow-hidden shadow-sm sm:rounded-lg">
                <div class="p-6 bg-white border-b border-gray-200">
                    <div class="panel-bod">
                        <table class="table">

                            <!-- Table Headings -->
                            <thead>
                                <th>Todo</th>
                                <th>&nbsp;</th>
                            </thead>

                            <!-- Table Body -->
                            <tbody class="max-w-full">
                                <tr class="max-w-full">
                                    <!-- Task Name -->
                                    <td class="pt-5 pb-5 pr-5">
                                        <!-- <div class=""> -->
                                        <h1 class="sm:font-bold">{{ $todo->title }}</h1>
                                        <p>{{ $todo->desc }}</p>
                                        <div class="flex content-between">
                                            <p class="pt-2 text-gray-500 pr-5"> Added By: {{ $todo->user->name }}</p>
                                            <p class="pt-2 text-gray-500"> Status: {{ $todo->status == 1? "Done": "Pending"}}</p>
                                        </div>

                                    </td>

                                    <td>
                                        <!-- TODO: Delete Button -->
                                        <div>
                                            <x-button-link href="/todos/{{$todo->id}}" class="bg-green-500">View</x-button-link>
                                            @if($todo->user_id == auth()->user()->id)
                                            <x-button-link href="{{ route('edit-form', ['id'=>$todo->id]) }}" class="bg-yellow-500">Edit</x-button-link>
                                            <x-button-link href="/todos/{{$todo->id}}/delete" class="bg-red-500">Delete</x-button-link>
                                            @endif
                                        </div>
                                    </td>
                                </tr>
                            </tbody>
                        </table>
                    </div>
                </div>
            </div>
        </div>
    </div>
</x-app-layout>

Edit view

The Edit View contains a form to update a particular Todo when the owner of the Todo clicks on the edit button.

Create a new blade file inside resources/views/edit.blade.php and paste in the following codes.

<x-app-layout>
    <x-slot name="header">
        <h2 class="font-semibold text-xl text-gray-800 leading-tight">
            {{ __('Dashboard') }}
        </h2>
    </x-slot>

    <div class="py-12">
        <div class="max-w-7xl mx-auto sm:px-6 lg:px-8">
            <div class="bg-white overflow-hidden shadow-sm sm:rounded-lg">
                <div class="p-6 bg-white border-b border-gray-200">
                    <form class="max-w-full" method="post" action="{{route('update', ['id'=>$todo->id])}}">
                        @csrf
                        <x-label class="pt-5 pb-5 pr-5">
                            Title
                            <x-input name="title" placeholder="Enter title" class="p-3 border-gray-900" value="{{$todo->title}}"></x-input>
                        </x-label>
                        <x-label class="pt-5 pb-5 pr-5">
                            Description
                            <textarea name="desc">{{ $todo->desc }}</textarea>
                        </x-label>
                        <x-label class="pt-5 pb-5 pr-5">
                            Status
                            <input name="status" type="checkbox" {{$todo->status==1 ? 'checked': ''}}>Done
                            </ input>
                        </x-label>
                        <x-button>Submit</x-button>
                    </form>
                </div>
            </div>
        </div>
    </div>
</x-app-layout>

Add view

The Add View contains a form to add/create a new particular Todo when a user clicks on the add button.

Create a new blade file inside resources/views/add.blade.php and paste in the following codes.

<x-app-layout>
    <x-slot name="header">
        <h2 class="font-semibold text-xl text-gray-800 leading-tight">
            {{ __('Dashboard') }}
        </h2>
    </x-slot>

    <div class="py-12">
        <div class="max-w-7xl mx-auto sm:px-6 lg:px-8">
            <div class="bg-white overflow-hidden shadow-sm sm:rounded-lg">
                <div class="p-6 bg-white border-b border-gray-200">
                    <form class="max-w-full" method="post" action="{{ route('add') }}">
                        @csrf
                        <x-label class="pt-5 pb-5 pr-5">
                            Title
                            <x-input required name="title" placeholder="Enter title" class="p-3 border-gray-900"></x-input>
                        </x-label>
                        <x-label class="pt-5 pb-5 pr-5">
                            Description
                            <textarea required name="desc"></textarea>
                        </x-label>
                        <x-button>Submit</x-button>
                    </form>
                </div>
            </div>
        </div>
    </div>
</x-app-layout>

Preview.

If you get everything correctly, you should be presented with a dashboard like this:

Congratulations on making it this far!

When it comes to learning Laravel, I will personally and highly recommend these 3 courses. With it, I was able to learn and start building projects within a week.

Laravel 8 Beginner to Advance with Complete News Portal

PHP with Laravel for beginners – Become a Master in Laravel

Laravel 2019, the complete guide with real world projects

Take a break and subscribe to get access to our free Laravel tips that will improve your productivity.

Chapter 4:Deploying Laravel Project

Now, deploying your Laravel project can be tedious especially if it is your first time, but in this chapter, we will look at deploying your first Laravel project easily and successfully.

Deploying Laravel to Heroku

To deploy Laravel to Heroku is a rather fun and straightforward process, it comes with great benefits and supports auto-deployment and auto testing that’s why I have prepared a work through an article on deploying Laravel to Heroku.

Deploying Laravel to Shared Hosting

Deploying Laravel to shared hosting might be the cheapest option available right now for testing purposes, that’s why I have prepared a work through article on deploying Laravel to Shared Hosting.

More Resources

Conclusion:Laravel

In this tutorial, we have looked at the nitty-gritty of Laravel and have created a Todo application to practically demonstrate the knowledge we have gained so far.

We have even looked at how to deploy the application to different hosting platforms.

Now, it’s your turn to practice everything you have learned until you master them by building real world projects. Let me know what you will be building, if none, just comment “Laravel is Great”, we may connect from there.

When it comes to learning Laravel with courses, I will personally and highly recommend these 3 courses. With it, I was able to learn and start building projects within a week.

Laravel 8 Beginner to Advance with Complete News Portal

PHP with Laravel for beginners – Become a Master in Laravel

Laravel 2019, the complete guide with real world projects

Author: Solomon Eseme

Thank you for being a part of the community

Before you go:

Whenever you’re ready

There are 4 ways we can help you become a great backend engineer:

The MB Platform: Join thousands of backend engineers learning backend engineering. Build real-world backend projects, learn from expert-vetted courses and roadmaps, track your learnings and set schedules, and solve backend engineering tasks, exercises, and challenges.
The MB Academy: The “MB Academy” is a 6-month intensive Advanced Backend Engineering BootCamp to produce great backend engineers.
Join Backend Weekly: If you like posts like this, you will absolutely enjoy our exclusive weekly newsletter, sharing exclusive backend engineering resources to help you become a great Backend Engineer.
Get Backend Jobs: Find over 2,000+ Tailored International Remote Backend Jobs or Reach 50,000+ backend engineers on the #1 Backend Engineering Job Board.