DEV Community: Ayas Hussein

Beyond Function Calling: Why MCP is the "USB-C" of AI Integrations

Ayas Hussein — Fri, 05 Jun 2026 10:59:47 +0000

If you’ve been building with Large Language Models (LLMs) lately, you’ve undoubtedly wrestled with connecting them to your data. For the past couple of years, the go-to solution has been "Tools" (or Function Calling). But recently, a new paradigm has emerged: the Model Context Protocol (MCP).

If you’re wondering, "Isn't MCP just another way to do tools?" You’re not alone. Let’s break down what MCP is, how it fundamentally differs from traditional tool use, and why it might just be the missing link in your AI architecture.

The Old Way: Traditional AI "Tools" (Function Calling)

To understand MCP, we first need to look at how we’ve been connecting LLMs to the outside world.
Traditional "tools" rely on Function Calling. As a developer, you define a function (e.g., get_weather(location: string)), provide a JSON schema describing it, and pass it to the LLM. If the model decides it needs the weather, it outputs a structured request, your code intercepts it, runs the function, and passes the result back to the model.

The Pain Points:

Vendor Lock-in & Fragmentation: You often have to write custom tool definitions and handlers for each AI provider (OpenAI, Anthropic, Google, etc.) because their schemas and implementation details differ slightly.
Siloed Development: If you build a great tool for your internal chatbot, you can’t easily plug it into a different AI app without rewriting the integration.
Context Blindness: Tools are great for actions (e.g., "send an email"), but they are clunky for providing rich, dynamic context (e.g., "read the last 50 lines of this specific log file and understand the database schema").

The New Way: What is MCP?

Enter the Model Context Protocol (MCP). Introduced as an open standard, MCP is designed to be the universal language for connecting AI systems to data sources.
Think of MCP as the USB-C port for AI. Just as USB-C standardized how devices connect to power and data regardless of the brand, MCP standardizes how AI assistants discover, read, and interact with external systems (databases, file systems, APIs, SaaS platforms).
Instead of building bespoke tool integrations for every AI app, you build an MCP Server once. Any MCP-compatible AI client (like Claude Desktop, custom enterprise apps, or open-source agents) can connect to it and instantly understand what resources and actions are available.

Let’s Look at the Code
The best way to understand the difference is to see them side-by-side. Let’s build a simple feature: fetching a user profile by ID.

The Traditional Tool Approach such (OpenAI/Anthropic) Notice how much boilerplate is required, and how the schema is completely disconnected from the actual Python function.

get_user_tool = {
    "name": "get_user_profile",
    "description": "Get the profile of a user by their ID",
    "parameters": {
        "type": "object",
        "properties": {
            "user_id": {
                "type": "string", 
                "description": "The unique ID of the user"
            }
        },
        "required": ["user_id"]
    }
}

2. The Actual Implementation (Disconnected from the schema above)

def get_user_profile(user_id: str) -> str:
# If you change the parameter name here, you MUST remember to
# update the JSON schema above, or the LLM will break.
return database.query(f"SELECT name, email FROM users WHERE id = '{user_id}'")

3. You must manually pass 'get_user_tool' in the API call to the LLM provider.`

2. The MCP Approach
With MCP (using the official Python SDK), the schema is generated automatically from your code’s type hints and docstrings. It’s DRY (Don't Repeat Yourself), clean, and universal.

Do You Still Need Traditional Tools?
Yes, but their role is evolving.

MCP is incredibly powerful for context retrieval and standardizing common integrations (Slack, GitHub, PostgreSQL, local file systems). However, traditional function calling is still highly relevant for:
Highly specialized, one-off actions that don’t warrant spinning up a full MCP server.
Strictly controlled environments where you don’t want the overhead of an external protocol.
Legacy systems where building an MCP wrapper isn’t feasible yet.
In the near future, the best architectures will likely use MCP for broad data access and context, supplemented by custom tools for highly specific, proprietary business logic.

The Bottom Line
The AI industry is moving from a "wild west" of custom, fragmented integrations to a mature, interoperable ecosystem. MCP is leading this charge. By decoupling the data source from the AI client, it saves developers countless hours of boilerplate and gives AI models the rich, dynamic context they need to be truly useful.
If you haven’t explored MCP yet, now is the time. Check out the official Model Context Protocol documentation and try building your first MCP server.

From Naive to Agentic: A Developer's Guide to RAG Architectures

Ayas Hussein — Sat, 28 Mar 2026 17:56:42 +0000

If you've built even one LLM application, you've likely encountered the hallucination problem. Your model sounds confident but makes things up. Or worse, it knows nothing about your company's private data because its training cutoff was two years ago.

Enter RAG (Retrieval-Augmented Generation).

RAG is the standard pattern for connecting LLMs to external knowledge. But here's the catch: Not all RAG pipelines are created equal. A simple "retrieve-and-read" setup might work for a demo, but it will fail in production.

In this article, we'll break down the 4 main types of RAG architectures, what specific problems they solve, and how to choose the right one for your use case.

🧱 1. Naive RAG (The "Hello World")

This is the baseline implementation you see in most tutorials.

The Flow:

User Query → Vector Search → Top K Chunks → LLM → Answer

The Problem It Solves (and Creates)

Solves: Basic knowledge grounding. It stops the model from relying solely on parametric memory.
Creates: Low precision and recall. You often retrieve irrelevant chunks or miss critical info due to poor chunking. It struggles with ambiguous queries.

🛠️ When to Use

Prototyping MVPs.
Simple Q&A over clean, well-structured documents.
Low-stakes internal tools.

🚀 2. Advanced RAG (The Production Standard)

Advanced RAG takes the naive pipeline and optimizes every stage: Pre-retrieval, Retrieval, and Post-retrieval.

The Flow:

Query → [Rewriting/Expansion] → Hybrid Search → [Re-Ranking] → LLM → Answer

The Problem It Solves

Noise Reduction: Naive RAG sends irrelevant context to the LLM, confusing it. Advanced RAG uses re-ranking models (like Cross-Encoders) to sort results by relevance before generation.
Semantic Gap: Users ask questions differently than documents are written. Advanced RAG uses query transformation (HyDE, step-back prompting) to bridge this gap.
Chunking Issues: Solves the "lost in the middle" phenomenon by optimizing chunk sizes and using parent-document retrievers.

🛠️ When to Use

Customer-facing support bots.
Enterprise search where accuracy is critical.
When you notice the LLM ignoring relevant context or hallucinating despite retrieval.

🧩 3. Modular RAG (The Composable Architecture)

Modular RAG treats retrieval as a set of interchangeable functions rather than a linear pipeline. You can mix and match modules like search, memory, fusion, and routing.

The Flow:

Query → [Router] → [Search Module OR Memory Module OR API] → [Fusion] → LLM

The Problem It Solves

One-Size-Fits-All Failure: Some queries need SQL, others need vector search, others need keyword search. Modular RAG uses a router to pick the right tool.
Complex Context: It enables patterns like Recursive Retrieval (fetching small chunks, then their parent documents) or Iterative Retrieval (searching multiple times based on previous findings).

🛠️ When to Use

Systems with multiple data sources (SQL + PDFs + APIs).
Complex domains where queries vary wildly in intent.
When you need fine-grained control over the retrieval logic.

🤖 4. Agentic RAG (The Autonomous Workflow)

This is the bleeding edge. Here, the LLM isn't just a generator; it's an agent that plans, executes, and reflects.

The Flow:

Agent Plans → Tool Use (Search/Calc) → Self-Correction → Final Answer

The Problem It Solves

Multi-Hop Reasoning: Naive RAG fails when the answer requires combining info from Document A and Document B. Agentic RAG can retrieve A, realize it needs B, retrieve B, then synthesize.
Dynamic Verification: The agent can critique its own retrieved context. If the info looks outdated or conflicting, it can self-correct and search again.
Tool Selection: It decides dynamically whether to search the vector DB, query a SQL database, or call a web search API.

🛠️ When to Use

Complex research assistants.
Financial or legal analysis requiring multi-step verification.
Workflows where latency is less critical than accuracy and reasoning depth.

📊 Quick Comparison Table

Architecture	Complexity	Latency	Accuracy	Best For
Naive	Low	Low	Medium	MVPs, Demos
Advanced	Medium	Medium	High	Production Apps
Modular	High	Medium	High	Multi-source Data
Agentic	Very High	High	Very High	Complex Reasoning

🧭 How to Choose? (A Decision Framework)

Don't start with Agentic RAG. You'll overengineer it. Follow this ladder:

Start with Naive: Build a basic pipeline with LangChain or LlamaIndex. Evaluate it.
Move to Advanced: If accuracy is <80%, add Hybrid Search and a Re-Ranker. Optimize your chunking strategy.
Go Modular: If you have diverse data types (tables + text), implement a Router to direct queries to the right retriever.
Evolve to Agentic: Only if users need multi-step reasoning (e.g., "Compare Q1 sales to Q2 marketing spend") should you introduce agent loops.

💡 Key Takeaway

RAG isn't a single technique; it's a spectrum of architectures.

Naive proves connectivity.
Advanced ensures reliability.
Modular ensures flexibility.
Agentic ensures reasoning.

Most production systems today thrive with Advanced RAG. Save the complexity of Agentic workflows for problems that truly require reasoning, not just retrieval.

Building a REST API in Rust with Rocket (Part 2)

Ayas Hussein — Wed, 25 Feb 2026 06:22:09 +0000

Welcome back! In Part 1, we installed Rust, explored the basics of ownership, and set up our development environment. Now, it's time to build something real.

Today, we are building a REST API.

While there are several web frameworks in Rust (like Axum or Actix), we are choosing Rocket for this tutorial. Why? Because Rocket prioritizes developer ergonomics. It uses macros to make routing and data handling feel magical, allowing you to focus on logic rather than boilerplate.

By the end of this post, you will have a working API that can create and retrieve tasks.

Prerequisites

Ensure you have completed Part 1:

[ ] Rust installed (rustc and cargo).
[ ] VS Code with rust-analyzer.
[ ] A tool to test APIs (like Postman, Insomnia, or just curl in your terminal).

Step 1: Project Setup

Let's create a new project specifically for our API.

cargo new task_api
cd task_api

Adding Dependencies

Open Cargo.toml. We need to add Rocket for the web server and Serde for handling JSON data.

[dependencies]
rocket = "0.5"
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"

Note: We are using Rocket 0.5, which supports Stable Rust. You do not need to install the nightly toolchain.

Step 2: Defining Data Models

In a REST API, we usually send and receive JSON. In Rust, we represent JSON objects as Structs. We use the serde library to automatically convert (serialize/deserialize) between Rust structs and JSON.

Open src/main.rs and add the following:

#[macro_use] extern crate rocket;

use rocket::serde::json::Json;
use serde::{Deserialize, Serialize};

// 1. Define what a Task looks like
#[derive(Debug, Serialize, Deserialize)]
pub struct Task {
    pub id: u32,
    pub title: String,
}

// 2. Define what data the client sends to create a task
// (We don't need an ID, the server will generate that)
#[derive(Debug, Deserialize)]
pub struct NewTask {
    pub title: String,
}

Key Concepts:

#[derive(Serialize)]: Allows Rust to turn this struct into JSON.
#[derive(Deserialize)]: Allows Rust to turn incoming JSON into this struct.
pub: Makes the fields accessible outside the module.

Step 3: Managing State (In-Memory)

A real API needs a database. However, setting up SQL adds a lot of complexity for a first tutorial. To keep things focused on Rocket, we will store tasks in memory using a Vec wrapped in a Mutex.

Vec: A growable list.
Mutex: Allows safe access to data across multiple threads (important for web servers).

Add this below your structs:

use std::sync::Mutex;

// Our application state
pub struct AppState {
    tasks: Mutex<Vec<Task>>,
}

Step 4: Creating Routes (Endpoints)

Rocket uses macros to define routes. This makes the code very readable.

1. Get All Tasks

This endpoint will handle GET /tasks.

#[get("/tasks")]
fn get_tasks(state: &rocket::State<AppState>) -> Json<Vec<Task>> {
    // Lock the mutex to read the data
    let tasks = state.tasks.lock().unwrap();
    // Return the list as JSON
    Json(tasks.clone())
}

2. Create a Task

This endpoint will handle POST /tasks. It accepts JSON in the body.

#[post("/tasks", format = "json", data = "<new_task>")]
fn create_task(
    state: &rocket::State<AppState>, 
    new_task: Json<NewTask>
) -> Json<Task> {
    // Lock the mutex to write data
    let mut tasks = state.tasks.lock().unwrap();

    // Generate a new ID (simple increment for demo)
    let new_id = if tasks.is_empty() { 1 } else { tasks.last().unwrap().id + 1 };

    // Create the full Task
    let task = Task {
        id: new_id,
        title: new_task.title.clone(),
    };

    // Save it
    tasks.push(task.clone());

    // Return the created task
    Json(task)
}

Key Concepts:

&rocket::State<AppState>: This is how Rocket injects our shared state into the function.
Json<T>: Rocket automatically parses incoming JSON into T and serializes outgoing T into JSON.
lock().unwrap(): We must lock the Mutex to safely modify the vector.

Step 5: Putting It All Together (Main)

Finally, we need to tell Rocket to launch, register our routes, and manage our state.

Update your main function:

#[launch]
fn rocket() -> _ {
    // Initialize state with some dummy data
    let state = AppState {
        tasks: Mutex::new(vec![
            Task { id: 1, title: String::from("Learn Rust") },
            Task { id: 2, title: String::from("Build API") },
        ]),
    };

    rocket::build()
        .manage(state) // Register the state
        .mount("/", routes![get_tasks, create_task]) // Register routes
}

Step 6: Run and Test

1. Run the Server

In your terminal:

cargo run

You should see output indicating the server is running on http://127.0.0.1:8000.

2. Test GET Request

Open your browser or terminal:

curl http://localhost:8000/tasks

Response:

[{"id":1,"title":"Learn Rust"},{"id":2,"title":"Build API"}]

3. Test POST Request

Use curl to send JSON data:

curl -X POST http://localhost:8000/tasks \
  -H "Content-Type: application/json" \
  -d "{\"title\":\"Deploy to Production\"}"

Response:

{"id":3,"title":"Deploy to Production"}

If you run the GET request again, you will see the new task in the list!

Summary of What We Built

Dependencies: We added Rocket and Serde via Cargo.toml.
Models: We created Rust structs that automatically map to JSON.
State: We used a Mutex to safely share data between requests.
Routes: We used #[get] and #[post] macros to define endpoints.
Launch: We mounted routes and launched the server.

Limitations & What's Next

This API is great for learning, but it has a major limitation: Data is stored in memory. If you restart the server, all tasks are lost.

In a production application, you need a database.

In Part 3, we will:

Integrate SQL database
Learn how to handle asynchronous database queries.
Implement DELETE and UPDATE endpoints.

You now have the foundation to build web services in Rust. Try adding a DELETE endpoint on your own before the next tutorial!

Getting Started with Rust: Why, How, and What's Next (Part 1)

Ayas Hussein — Wed, 25 Feb 2026 06:07:15 +0000

If you've been following tech trends, you've heard the buzz about Rust. It's been voted the "most loved programming language" on Stack Overflow for several years running. But what exactly is it? Is it worth the learning curve? And how do you actually get started?

In this tutorial, we'll cover the fundamentals of Rust, why you should consider adding it to your toolkit, how to install it, and how its ecosystem works.

Stay tuned for Part 2, where we'll use these basics to build a high-performance REST API.

Why Use Rust?

Rust isn't just another scripting language. It sits in a unique spot between low-level control (like C++) and high-level ergonomics (like Python). Here are the three main reasons developers are switching:

1. Memory Safety Without Garbage Collection

In languages like Java or Python, a "Garbage Collector" cleans up memory for you, which can cause unpredictable pauses. In C or C++, you manage memory manually, which often leads to crashes and security vulnerabilities.

Rust introduces a unique system called Ownership. It checks memory safety at compile time. If your code tries to access memory it shouldn't, the compiler refuses to build the program. This means no segfaults, no data races, and no garbage collector.

2. Blazing Performance

Because Rust doesn't have a runtime or garbage collector, it is incredibly fast. It is comparable to C++ in performance, making it perfect for systems programming, game engines, high-frequency trading, and web backends.

3. Modern Tooling

Rust comes with a built-in package manager and build tool called Cargo. It handles dependencies, builds, testing, and documentation out of the box. No more configuring webpack or pip environments manually.

Installation: Getting Up and Running

Installing Rust is straightforward thanks to a tool called rustup. It manages your Rust version and tools.

Step 1: Install Rustup

Open your terminal (Command Prompt, PowerShell, or Bash) and run the following command:

macOS / Linux:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Windows:
Download and run rustup-init.exe from the official website.

During installation, press Enter to confirm the default settings. This will install the compiler (rustc), the package manager (cargo), and standard libraries.

Step 2: Verify Installation

Close and reopen your terminal, then type:

rustc --version
cargo --version

You should see version numbers printed out. If so, you're ready!

Step 3: Editor Setup

Rust code can be complex, so you need an editor that understands it.

Download VS Code (recommended).
Install the rust-analyzer extension.
- Note: Do not install the old "Rust" extension. rust-analyzer is the official and most powerful tool.

Understanding the Ecosystem (Not "Frameworks")

A common question coming from languages like JavaScript (Node.js) or Python (Django) is: "What is the Rust framework?"

The answer is: There isn't just one.

Rust relies on an ecosystem of libraries called Crates. You pick and choose the crates you need to build your application. This gives you flexibility but requires you to make choices.

For Web Development and APIs (which we will cover in the next post), these are the top contenders:

Framework	Best For	Description
Axum	Ergonomics & Type Safety	Currently the most recommended. Built on Tokio, very modular.
Actix-web	Performance	Known for being incredibly fast, though slightly steeper learning curve.
Rocket	Ease of Use	Very expressive and easy to read, but historically had slower release cycles.

For our upcoming REST API tutorial, we will be using Axum, as it represents the modern standard for Rust web development.

The Basics: Your First Project

Let's create a project to understand how Rust code is structured.

1. Create a Project

Navigate to your coding folder and run:

cargo new hello_rust
cd hello_rust

2. Explore the Structure

Open the folder in VS Code. You'll see:

Cargo.toml: The configuration file (like package.json). This is where you add dependencies.
src/main.rs: The entry point of your application.

3. Write Some Code

Open src/main.rs. You'll see this:

fn main() {
    println!("Hello, world!");
}

Let's make it slightly more interesting to see Rust's basics in action:

fn main() {
    // Variables are immutable by default
    let name = "Developer"; 

    // Use 'mut' to make a variable mutable
    let mut message = String::from("Welcome to Rust"); 

    println!("Hello, {}! {}", name, message);

    // Update the mutable variable
    message = String::from("Let's build something fast");
    println!("{}", message);
}

4. Run It

Back in your terminal, run:

cargo run

Output:

Hello, Developer! Welcome to Rust
Let's build something fast

What's Next?

You now have Rust installed, you understand why it's powerful, and you've written your first program. But the real power of Rust shines when you build networked applications. In the next , I am going to create some endpoints using Rocket.

AI Agents Architecture

Ayas Hussein — Mon, 22 Dec 2025 20:32:26 +0000

“What Does a Real-World AI Agent Architecture Actually Look Like?”

Forget the hype. Let's talk about the minimal, modular architecture that’s simple enough to understand and robust enough to scale.

The 4-Layer Blueprint

Every effective AI agent is built on four distinct layers:

1. Interface Layer: “How the World Talks to the Agent”

This layer’s job is pure translation: normalize all input and render all output.

Input Handlers:
- Chat → Raw text
- Voice → Speech-to-text (e.g. Whisper)
- Future-proof for: UI actions, file uploads, sensor data
Output Renderers:
- Text replies
- Text-to-speech (for voice bots)
- Structured data (for APIs)

Rule of Thumb: Keep this layer stateless. Let the orchestration layer manage context and session.

2. Orchestration Layer: “The Agent’s Central Nervous System”

This is the command center. It manages the conversation flow, decides on actions, and maintains state.

State Management: Tracks the conversation history, user intent, and active goals.
Tool Routing: Decides when and how to act. Should the agent answer directly, search knowledge, or call an API?
Workflow Control: Handles conditional logic, multi-step processes, and error recovery.

3. Reasoning & Memory Layer: “The Brain with a Filing System”

Core Model: Your LLM of choice (hosted like GPT-4, or self-hosted like Llama 3).
Retrieval-Augmented Generation (RAG):
- Knowledge Base: Documents stored as embeddings in a vector database (I use Pinecone for cloud, Chroma for local).
- Process: Query (user input + context) fetches relevant chunks, which are injected into the LLM prompt for grounded responses.
Memory:
- Short-term: Conversation history (cached in Redis or memory).
- Long-term: User profiles, past interactions, preferences (stored in a traditional SQL/NoSQL DB or knowledge graph).

Core Principle: Never let the LLM “guess.” Always ground its reasoning in retrieved data or validated tool outputs.

4. Action & Integration Layer: “Getting Real Work Done”

This turns your agent from a conversationalist into an automation engine.

Tool Library: A curated set of typed, idempotent functions with built-in error handling and auth.
Examples:
- Call a REST API to check an order status.
- Update a record in Salesforce or HubSpot.
- Execute a query in your product database.
- Trigger a CI/CD pipeline or a Slack notification.

The Bottom Line

The best AI agent isn’t the one with the fanciest model. It’s the one with the most robust architecture,solving a real problem without breaking in production.

Start with a layer. Nail it. Then scale.

Golang Tutorial: Using Mutex with Goroutines

Ayas Hussein — Sat, 24 May 2025 21:24:58 +0000

When working with goroutines , you often need to share data between them. However, concurrent access to shared variables can lead to race conditions ,where multiple goroutines try to read/write the same variable at the same time, leading to unpredictable behavior.

To solve this, Go provides a synchronization mechanism called Mutex from the sync package.

What is a Mutex?
A mutex (short for mutual exclusion) allows only one goroutine to access a critical section of code at a time.
In Go, it's represented by the sync.Mutex type.
You call Lock() before accessing the shared resource and Unlock() after you're done.

Example with Mutex

package main

import (
    "fmt"
    "sync"
    "time"
)

func main() {
    counter := 0
    var mu sync.Mutex{} // Create a mutex

    var wg sync.WaitGroup // To wait for all goroutines

    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            mu.Lock()   // Lock the mutex before accessing counter
            counter++   // Critical section
            mu.Unlock() // Unlock after done
        }()
    }

    wg.Wait() // Wait until all goroutines complete
    fmt.Println("Final counter:", counter)
}

Output:

Final counter: 1000

🚀 Tips
Always use defer mu.Unlock() to ensure unlocking even if there’s a panic or early return.
Avoid holding locks for too long to prevent performance issues.
Use the -race flag when running your program to detect race conditions:

go run -race main.go

ai agents

Ayas Hussein — Thu, 08 May 2025 13:55:58 +0000

Build a Simple ToDo App with React and GraphQL

Ayas Hussein — Thu, 17 Apr 2025 19:45:13 +0000

Have you ever wondered how to build a full-stack app using GraphQL instead of REST? In this tutorial, we’ll walk through how to create a simple ToDo app using React and GraphQL with Apollo.

🎯 By the end, you’ll have a working app where you can view, add, and toggle tasks — powered by a GraphQL API.

Step 1: Set Up the GraphQL Server (Backend)

mkdir graphql-server
cd graphql-server
npm init -y
npm install apollo-server graphql

Create index.js for the backend

const { ApolloServer, gql } = require('apollo-server');

const typeDefs = gql`
  type Todo {
    id: ID!
    title: String!
    completed: Boolean!
  }

  type Query {
    todos: [Todo]
  }

  type Mutation {
    addTodo(title: String!): Todo
    toggleTodo(id: ID!): Todo
  }
`;

let todos = [
  { id: "1", title: "Learn GraphQL", completed: false },
  { id: "2", title: "Build a ToDo App", completed: false },
];

const resolvers = {
  Query: {
    todos: () => todos,
  },
  Mutation: {
    addTodo: (_, { title }) => {
      const newTodo = { id: Date.now().toString(), title, completed: false };
      todos.push(newTodo);
      return newTodo;
    },
    toggleTodo: (_, { id }) => {
      const todo = todos.find(t => t.id === id);
      todo.completed = !todo.completed;
      return todo;
    },
  },
};

const server = new ApolloServer({ typeDefs, resolvers });
server.listen().then(({ url }) => {
  console.log(`🚀 Server ready at ${url}`);
});

Step 2: Set Up the React App (Frontend)

npx create-react-app graphql-todo
cd graphql-todo
npm install @apollo/client graphql

in src/index.js

import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';
import { ApolloClient, InMemoryCache, ApolloProvider } from '@apollo/client';

const client = new ApolloClient({
  uri: 'http://localhost:4000',
  cache: new InMemoryCache(),
});

ReactDOM.render(
  <ApolloProvider client={client}>
    <App />
  </ApolloProvider>,
  document.getElementById('root')
);

in src/App.js

import React, { useState } from 'react';
import { useQuery, useMutation, gql } from '@apollo/client';

const GET_TODOS = gql`
  query {
    todos {
      id
      title
      completed
    }
  }
`;

const ADD_TODO = gql`
  mutation($title: String!) {
    addTodo(title: $title) {
      id
      title
      completed
    }
  }
`;

const TOGGLE_TODO = gql`
  mutation($id: ID!) {
    toggleTodo(id: $id) {
      id
      completed
    }
  }
`;

function App() {
  const { data, loading } = useQuery(GET_TODOS);
  const [addTodo] = useMutation(ADD_TODO, {
    refetchQueries: [{ query: GET_TODOS }],
  });
  const [toggleTodo] = useMutation(TOGGLE_TODO);
  const [input, setInput] = useState('');

  if (loading) return <p>Loading...</p>;

  const handleAdd = () => {
    if (input.trim()) {
      addTodo({ variables: { title: input } });
      setInput('');
    }
  };

  return (
    <div style={{ padding: '2rem' }}>
      <h2>📝 GraphQL ToDo List</h2>
      <input value={input} onChange={e => setInput(e.target.value)} placeholder="New task" />
      <button onClick={handleAdd}>Add</button>
      <ul>
        {data.todos.map(todo => (
          <li key={todo.id} onClick={() => toggleTodo({ variables: { id: todo.id } })}>
            <span style={{ textDecoration: todo.completed ? 'line-through' : 'none' }}>
              {todo.title}
            </span>
          </li>
        ))}
      </ul>
    </div>
  );
}

export default App;

Step 3 : Start the app
in backend

node index.js

in frontend

npm start

🚀 You Did It!
You now have a working React app powered by GraphQL. You can:

View todos
Add a new task
Toggle them done/undone

What's Next?

Add delete functionality
Store data in MongoDB or PostgreSQL
Deploy to Vercel or Netlify

Creating a GoLang API that allows uploading files to an Amazon S3 bucket

Ayas Hussein — Mon, 23 Dec 2024 19:41:37 +0000

Step 1: Setup AWS S3

Log in to your AWS Management Console.
Navigate to S3 and create a bucket or you can use any that has been already created. Step 2: Initialize Your Go Project Create a folder / dir and run below commands

go mod init s3-upload-api
go get github.com/aws/aws-sdk-go-v2 github.com/aws/aws-sdk-go-v2/config github.com/aws/aws-sdk-go-v2/service/s3
go get github.com/gorilla/mux

Step 3: Create the API

package main

import (
    "context"
    "fmt"
    "log"
    "mime/multipart"
    "net/http"
    "os"

    "github.com/aws/aws-sdk-go-v2/config"
    "github.com/aws/aws-sdk-go-v2/service/s3"
    "github.com/gorilla/mux"
)

var (
    s3Client   *s3.Client
    bucketName = "your-bucket-name" // Replace with your S3 bucket name
    region     = "your-region"     // Replace with your S3 bucket region
)

// initializeS3Client initializes the S3 client
func initializeS3Client() {
    cfg, err := config.LoadDefaultConfig(context.TODO(), config.WithRegion(region))
    if err != nil {
        log.Fatalf("unable to load SDK config, %v", err)
    }
    s3Client = s3.NewFromConfig(cfg)
}

// uploadToS3 uploads a file to S3
func uploadToS3(file multipart.File, fileName string) error {
    _, err := s3Client.PutObject(context.TODO(), &s3.PutObjectInput{
        Bucket: &bucketName,
        Key:    &fileName,
        Body:   file,
    })
    return err
}

// uploadHandler handles file uploads
func uploadHandler(w http.ResponseWriter, r *http.Request) {
    // Parse the incoming request
    err := r.ParseMultipartForm(10 << 20) // Limit upload size to 10MB
    if err != nil {
        http.Error(w, "Unable to parse form", http.StatusBadRequest)
        return
    }

    file, handler, err := r.FormFile("file")
    if err != nil {
        http.Error(w, "Unable to retrieve file", http.StatusBadRequest)
        return
    }
    defer file.Close()

    // Upload file to S3
    err = uploadToS3(file, handler.Filename)
    if err != nil {
        http.Error(w, fmt.Sprintf("Failed to upload file: %v", err), http.StatusInternalServerError)
        return
    }

    w.WriteHeader(http.StatusOK)
    fmt.Fprintf(w, "File uploaded successfully: %s", handler.Filename)
}

func main() {
    initializeS3Client()

    r := mux.NewRouter()
    r.HandleFunc("/upload", uploadHandler).Methods("POST")

    port := "8080"
    log.Printf("Starting server on port %s...", port)
    log.Fatal(http.ListenAndServe(":"+port, r))
}

Step 4: Test the API

go run main.go

Now you are able to send a POST request to http://localhost:8080/upload
with a file name. Try this in postman or your frontend app.

What is a Data Pipeline?

Ayas Hussein — Fri, 20 Dec 2024 20:46:53 +0000

A data pipeline is a set of processes or tools that systematically transfer data from one system to another, often involving transformation, enrichment, validation, and loading into a target system. It automates the flow of data between different systems, applications, or storage locations while ensuring the data's quality, consistency, and usability.

Data pipelines are critical in modern data-driven applications, enabling efficient and reliable data handling for analytics, machine learning, real-time decision-making, and reporting.

Types of Data Pipelines
Data pipelines can be classified based on their architecture, data movement patterns, or the kind of data they process. Here's an overview of the most common types:

Batch Data Pipelines
Definition: These pipelines process and move data in batches at scheduled intervals. All the data is collected, transformed, and processed together at a specific time.
Use Cases:
Processing historical data for analytics
Generating periodic reports
Data warehousing
Examples:
Extract, Transform, Load (ETL) processes
Hadoop MapReduce jobs
Tools: Apache Hadoop
Real-Time (Streaming) Data Pipelines
Definition: These pipelines process and transfer data as it is generated, enabling near-instantaneous data processing.
Use Cases:
Monitoring sensor data in IoT devices
Fraud detection in financial transactions
Real-time analytics for dashboards
Examples:
Streaming stock prices
Processing clickstream data from a website
Tools: Apache Kafka, Apache Flink, Google Dataflow, AWS Kinesis
Cloud-Native Data Pipelines
Definition: Designed to work seamlessly in cloud environments, these pipelines leverage cloud services for scalability, reliability, and integration.
Use Cases:
Cloud-to-cloud data transfers
Migrating data from on-premises to cloud systems
Examples:
Data replication across cloud regions
Tools: AWS Data Pipeline, Google Cloud Dataflow, Azure Data Factory
Event-Driven Data Pipelines
Definition: These pipelines are triggered by specific events or conditions, enabling immediate data flow in response to certain actions.
Use Cases:
Updating a database when a file is uploaded to a server
Triggering workflows upon receiving API calls
Examples:
Sending notifications when a user signs up
Processing logs when an application crashes
Tools: Apache Airflow, AWS Lambda
Hybrid Data Pipelines
Definition: These pipelines combine batch and real-time processing, allowing organizations to handle both large-scale historical data and continuous data streams.
Use Cases:
Real-time dashboard updates with daily batch summaries
Online stores processing both live orders and historical trends
Examples:
E-commerce platforms combining clickstream analysis and sales trends
Tools: Apache Beam, Snowflake

Steps in a Data Pipeline Workflow

Data Ingestion: Collect data from various sources (databases, APIs, IoT devices, etc.).
Data Transformation: Process, clean, and transform the data into a usable format.
Data Validation: Ensure the data meets quality standards (e.g., no duplicates, correct types).
Data Storage: Store the processed data in a target system (e.g., data warehouse, cloud storage).
Data Visualization or Analysis: Make the data available for analytics, dashboards, or machine learning models.

Conclusion
Data pipelines are the backbone of any data-driven organization, enabling efficient data processing and movement. By understanding the types of pipelines and their use cases, you can choose the right tools and architecture to meet your business needs. Whether processing large historical datasets or real-time data streams, a well-designed data pipeline ensures data quality, reliability, and usability.

Unleashing the Power of SQL in Machine Learning

Ayas Hussein — Sat, 30 Nov 2024 17:17:52 +0000

Unleashing the Power of SQL in Machine Learning

🚀 Machine Learning is not just about fancy algorithms and frameworks; it's also about how you prepare, manipulate, and query your data. Enter SQL—a timeless tool for data wrangling that's as relevant in ML as it is in traditional data analysis.

Here’s why SQL is a must-have skill for machine learning practitioners:

🔑 Why SQL Matters in ML

Data Preparation: Cleaning and transforming raw data into a structured format.
Feature Engineering: Creating new features directly in your database using SQL queries.
Scalable Querying: Processing large datasets efficiently with SQL's powerful functions.
Integration with ML Pipelines: Seamless compatibility with Python, R, and ML frameworks.

💡 Common Use Cases

Exploratory Data Analysis (EDA):

   SELECT AVG(salary), COUNT(*) 
   FROM employees 
   WHERE department = 'IT';

Get insights directly from your database!

Feature Engineering:

   SELECT 
       user_id, 
       SUM(amount_spent) AS total_spent, 
       COUNT(order_id) AS order_count 
   FROM orders 
   GROUP BY user_id;

Aggregate data for feature creation.

Data Labeling:

   SELECT 
       user_id, 
       CASE 
           WHEN total_spent > 500 THEN 'High Spender' 
           ELSE 'Low Spender' 
       END AS spender_category 
   FROM user_data;

Joining Tables for Model Inputs:

   SELECT 
       a.user_id, 
       a.purchase_history, 
       b.clicks 
   FROM purchases a 
   JOIN web_activity b 
   ON a.user_id = b.user_id;

Combine multiple data sources.

⚙️ SQL and Machine Learning Pipelines

Tools like BigQuery ML and Snowflake now integrate SQL directly into ML pipelines! You can:

Train models directly in SQL:

   CREATE MODEL my_model
   OPTIONS(model_type='logistic_regression') AS
   SELECT * FROM training_data;

Query predictions:

   SELECT predicted_label FROM ML.PREDICT(MODEL my_model, SELECT * FROM test_data);

🎯 SQL for ML Success

Start Small: Practice with common SQL queries on datasets like Titanic or Iris.
Scale Gradually: Explore tools like BigQuery or Snowflake for larger datasets.
Integrate: Use libraries like pandasql in Python to mix SQL with your ML workflows.

Choosing the Right Relational Database

Ayas Hussein — Fri, 29 Nov 2024 20:48:54 +0000

Relational databases are the backbone of countless applications, from small startups to enterprise-level solutions. But with options like MySQL, Oracle, PostgreSQL, and SQL Server, how do you decide which is the right fit for your project?

From my experience working on diverse applications across industries such as travel, HR, e-commerce, mobile money, and the metaverse, I’ve seen how the choice of database can profoundly impact a project’s scalability, performance, and cost-efficiency. Here's what I've learned:

1. MySQL: The Lightweight Powerhouse
Best for web and mobile applications with moderate complexity and high read-heavy workloads.

Strengths: Simplicity, open-source, great community support, and easy integration with popular frameworks like Laravel and Django.
Use Case: I’ve used MySQL for learning management systems and smaller e-commerce platforms where fast development cycles were crucial.
2. Oracle: The Enterprise
Best for mission-critical, high-volume transactional systems with advanced analytics and data security needs.

Strengths: Robust performance, scalability, and unmatched reliability for large-scale enterprise applications.
Use Case: In one of my projects involving enterprise-grade insurance solutions, Oracle's advanced features like partitioning and parallel query execution were game-changers.

3. PostgreSQL
Best for complex data modeling, geospatial data, and advanced analytics.

Strengths: Feature-rich (e.g., JSONB support, window functions), highly extensible, and great for hybrid workloads combining OLTP and OLAP.
Use Case: I relied on PostgreSQL for a health data platform that required handling both relational data and complex queries for analytics.

4. SQL Server
Best for enterprise applications in the Microsoft ecosystem where seamless integration is key.

Strengths: Tight integration with tools like Power BI, Azure, and SSIS, along with excellent support for stored procedures and triggers.
Use Case: I’ve implemented SQL Server in corporate HR systems where the integration with Microsoft Active Directory streamlined user authentication.

Why It Matters
Each relational database shines in specific scenarios, and choosing the wrong one can lead to challenges like:

Scalability issues: A growing user base may overwhelm the system.
Cost inefficiency: Licensing and operational costs can spiral if not planned.
Limited flexibility: Some databases may not support future requirements ( NoSQL-style queries or advanced analytics).
Key Takeaways.

When selecting a database:

Understand your application's data structure and volume.
Define your scalability and performance requirements.
Consider your team’s skill set and ecosystem compatibility.
Factor in long-term cost implications (open-source vs. licensed).