DEV Community: Humza Inam

Learning Azure Networking Through Code: My Spring Boot + Terraform Journey

Humza Inam — Mon, 20 Oct 2025 21:09:52 +0000

Building a production-style network from scratch to understand how the cloud really works

What I Built

I created a complete Azure network infrastructure with multiple virtual networks, security rules, load balancing, and a Spring Boot application to test it all. Think of it as building a miniature version of how companies actually structure their cloud networks, but small enough to learn from and cheap enough to run on Azure's student credits.

The Setup

Two separate virtual networks connected through VNet peering, with a Spring Boot REST API that provides real-time network diagnostics. An Application Gateway acts as the public entry point, routing traffic to a private VM that can only be accessed through specific security rules. There's also a bastion host for secure SSH access and private endpoints connecting to Azure Storage without touching the public internet.

The flow: Internet → Application Gateway → Private Spring Boot VM → Storage Account (via private endpoint)

Why This Stack?

The combination seems unusual at first: Terraform for infrastructure, Spring Boot for the application, and Azure networking concepts all mixed together. But that's exactly why I chose it. I wanted to learn Spring Boot (Java web development) while also understanding networking fundamentals. By building the network infrastructure myself and then deploying an app that could test and report on that infrastructure, I learned both topics simultaneously.

Getting Started with Azure Student Credits

This entire project runs on Azure's free student tier. No credit card needed, and you get $100 in credits renewed annually. The resources I used (small VMs, basic networking) cost pennies per hour, so you can run this for days while learning.

How to get started:

Go to azure.microsoft.com/free/students
Verify with your student email
Get instant access to enterprise-grade cloud tools

The key insight I learned: don't just rely on your university's resources. External companies like Microsoft, AWS, and Google actively want students learning their platforms. Take advantage of these programs.

The Architecture

Two Virtual Networks (VNets)

I created two separate networks:

Primary VNet (10.0.0.0/16): Contains the Spring Boot application, bastion host, and Application Gateway
Secondary VNet (10.1.0.0/16): A separate network for testing cross-network communication

These VNets are connected through VNet peering, which lets them communicate privately without going through the public internet.

Five Subnets for Segmentation

Primary VNet:

Public subnet (10.0.1.0/24) - Bastion host
Private subnet (10.0.2.0/24) - Spring Boot app and private endpoint
App Gateway subnet (10.0.3.0/24) - Load balancer

Secondary VNet:

Public subnet (10.1.1.0/24) - Reserved
Private subnet (10.1.2.0/24) - Test VM running Nginx

Subnets let you isolate different types of resources and apply different security rules to each.

Security Through Network Security Groups (NSGs)

Each subnet has an NSG acting as a firewall. For example, the private subnet only allows:

SSH from the public subnet (bastion host)
HTTP traffic on port 8080 from within the VNet
Traffic from the App Gateway subnet
Communication with the secondary VNet

Everything else is blocked by default. This is zero-trust networking - nothing is allowed unless explicitly permitted.

The Bastion Pattern

The bastion host is a VM with a public IP that acts as a secure jump box. You SSH into the bastion first, then from there you can access private VMs. This means your application servers never need public IPs, reducing attack surface.

ssh azureuser@bastion-ip
# Then from bastion:
ssh azureuser@private-vm-ip

Application Gateway for Public Access

The Application Gateway is Azure's Layer 7 load balancer. It has a public IP and routes incoming HTTP requests to the private Spring Boot VM on port 8080. It includes:

Health probes that check /health every 30 seconds
Automatic routing rules
Protection for the backend (the private VM stays private)

Private Endpoints for Secure Storage Access

The coolest part: the private VM connects to Azure Storage without using the public internet. A private endpoint creates a network interface in your VNet that maps to the storage account. When the VM resolves storageaccount.blob.core.windows.net, it gets a private IP (10.x.x.x) instead of a public one.

This is achieved through:

Private DNS zone for privatelink.blob.core.windows.net
Private endpoint in the private subnet
DNS resolution that returns private IPs

NAT Gateway for Outbound Internet

Private VMs need internet access for things like software updates. The NAT Gateway provides a single public IP that all private subnet resources share for outbound connections. This way, they can reach the internet but the internet can't reach them.

The Spring Boot Application

I built a REST API with several diagnostic endpoints to test the network:

GET /health - Basic health check for the Application Gateway probe

{
  "status": "UP",
  "timestamp": 1234567890,
  "message": "Hello from Azure Private VM!",
  "storage_account": "demostorageXXXX"
}

GET /api/vm-info - Reports the VM's network details

{
  "hostname": "vm-private-demo",
  "private_ip": "10.0.2.4",
  "vnet": "vnet-demo",
  "resource_group": "rg-demo-networking"
}

GET /api/network-test - Tests DNS resolution of the storage account

{
  "storage_fqdn": "demostorage.blob.core.windows.net",
  "resolved_ip": "10.0.2.5",
  "dns_resolution": "SUCCESS",
  "using_private_endpoint": true
}

GET /api/storage-test - Validates private endpoint connectivity

Why Spring Boot?

I wanted to learn Java web development while building this infrastructure project. Spring Boot makes it easy to create REST APIs with minimal boilerplate. The @RestController and @GetMapping annotations handle all the HTTP routing automatically.

The application runs as a systemd service on Ubuntu, managed through a bash setup script that:

Installs Java and Maven
Creates the Spring Boot project structure
Builds the JAR file with Maven
Configures a systemd service for automatic startup
Creates test scripts for network validation

Infrastructure as Code with Terraform

All 700+ lines of infrastructure are defined in code. This means I can destroy everything and rebuild it identically in minutes. Here's how Terraform structures the resources:

Resource Dependencies

Terraform automatically figures out what order to create resources based on dependencies. For example:

VNet must exist before subnets
Subnets must exist before VMs
NSGs must exist before NSG associations
Private DNS zone must be linked to VNet before private endpoint

Templating in Cloud-Init Scripts

The Spring Boot setup script uses Terraform's templatefile() function to inject variables:

custom_data = base64encode(templatefile("spring-boot-setup.sh", {
  storage_account_name = azurerm_storage_account.demo.name
  container_name       = azurerm_storage_container.demo.name
  vnet_name           = azurerm_virtual_network.main.name
}))

This lets the Java application know which storage account to test against without hardcoding values.

What I Learned

Networking Fundamentals

Before this project, concepts like subnets, CIDR notation, and routing tables were abstract. Now I understand:

Why subnets matter: They isolate resources and let you apply different security policies
How DNS resolution works: Especially with private DNS zones overriding public DNS
The difference between Layer 4 and Layer 7 load balancing: NAT Gateway vs Application Gateway
Network security groups vs firewalls: NSGs filter traffic at the subnet/NIC level

Spring Boot Development

I learned how to:

Structure a Spring Boot project with Maven
Create REST controllers with proper HTTP methods
Handle JSON serialization automatically
Deploy Java applications as Linux services
Build projects in CI/CD-style automation scripts

Azure Cloud Services

Working with Azure taught me:

How VNet peering enables private cross-network communication
Private endpoints eliminate public internet exposure for PaaS services
Application Gateway health probes and backend pools
Service endpoints vs private endpoints

Infrastructure as Code Best Practices

I learned to:

Use variables and outputs effectively
Structure Terraform for readability
Handle dependencies and resource ordering
Inject configuration into VMs via cloud-init
Manage SSH keys securely

Challenges I Faced

Maven Build Issues

The cloud-init script had to handle different Java versions and ensure the JAR file path was correctly detected. I added fallback logic to find any built JAR file instead of hardcoding the name.

Application Gateway Health Probes

Initially, the health probe kept failing because I forgot to configure the probe path to match the /health endpoint. The gateway needs explicit configuration for backend health checks.

Private DNS Resolution

Understanding when to use service endpoints vs private endpoints took time. Service endpoints secure the service but still use public IPs. Private endpoints actually inject a private IP into your VNet, which is more secure but requires private DNS zones.

Network Security Group Rules

Getting the NSG priorities and port ranges right required iteration. I learned to be explicit with source and destination address prefixes rather than using wildcards.

Final Thoughts

This project taught me that the best way to learn cloud networking is to build something real. Reading documentation helps, but nothing compares to troubleshooting why your private endpoint DNS isn't resolving or why the Application Gateway can't reach your backend.

Combining Spring Boot with networking infrastructure might seem unusual, but it forced me to understand both topics deeply. The application wasn't just sitting on top of the network - it was actively testing and reporting on network behavior.

Azure's student credits made this possible without any financial barrier. If you're a student interested in cloud infrastructure, networking, or backend development, I encourage you to build something similar. Start small, break things, fix them, and learn through doing.

About This Post

This blog post was written based on the project's Terraform configuration, Spring Boot setup scripts, and my personal reflections throughout the learning process. The narrative was structured and refined with AI assistance to create a clear and approachable explanation of the technical implementation.

My First Data Engineering Project: Building a Real-Time IoT Pipeline on Azure

Humza Inam — Mon, 20 Oct 2025 20:26:04 +0000

From zero data engineering experience to deploying a streaming analytics platform powered by Azure's student tier

What I Built

I created an end-to-end IoT data pipeline that ingests simulated sensor data, detects anomalies in real-time, stores everything in a database, and visualizes live metrics on a Power BI dashboard. Think of it as a complete "data journey", from sensor readings on a phone to insights on a dashboard, all happening in real-time.

The Pipeline Flow

IoT Central (Simulated Devices) → Event Hub (Ingestion) → Stream Analytics (Processing + ML) → Azure SQL (Storage) → .NET Function → Power BI (Visualization)

What It Does

Simulates IoT sensors using Azure IoT Central's Plug & Play templates (accelerometer, gyroscope, battery, GPS)
Processes streaming data in real-time with Azure Stream Analytics
Detects anomalies using built-in ML algorithms (battery spikes, unusual acceleration patterns)
Stores raw data in Azure Data Lake Gen2 for future analysis
Curates processed data in Azure SQL Database with proper schema design
Streams live metrics to Power BI through a custom .NET 8 Azure Function
Visualizes everything on a real-time dashboard with KPIs, maps, and alerts

Why This Project?

I wanted to understand how data flows in the real world. Not just theory or toy examples, but an actual production-grade pipeline that could handle real IoT scenarios. As my first data engineering project, I needed to learn:

How to ingest high-velocity streaming data
How to process and transform data in real-time
How to apply machine learning for anomaly detection
How to store data efficiently for analytics
How to visualize insights for decision-making

Most importantly, I wanted to build something tangible that demonstrated the entire data lifecycle.

The Azure Student Advantage

Here's the best part: This entire project cost me nothing. Azure's student tier provided everything I needed:

$100 in free credits (renewed annually)
Free tier services like Azure Functions and IoT Central
12 months of free services including SQL Database and Stream Analytics hours
Access to enterprise-grade tools that companies actually use

How You Can Do This Too

Verify your student status at azure.microsoft.com/free/students
No credit card required for the initial signup
Explore beyond your university - Azure is an "external organization" offering resources to students globally

The key insight: Don't limit yourself to your school's resources. Companies like Microsoft, AWS, and Google offer generous student programs specifically to help you learn their platforms. Take advantage of them.

The Architecture Journey

Phase 1: Device Simulation with IoT Central

I started with Azure IoT Central, a managed IoT platform that let me simulate devices without owning physical hardware. Using Plug & Play device templates, I modeled smartphones with:

Accelerometer (x, y, z axes)
Gyroscope readings
Battery percentage
GPS coordinates
Barometric pressure

IoT Central has a built-in transformation engine that let me normalize the data format before sending it downstream. This was crucial, cleaning data at the source meant less work later.

Phase 2: Ingestion with Event Hub

Azure Event Hub acts as the front door for streaming data. It's a distributed ingestion system that can handle millions of events per second with guaranteed durability.

Key learning: Event Hubs use partitions for parallel processing. Understanding partitioning strategy was essential for scalability.

Phase 3: Real-Time Processing with Stream Analytics

This is where the magic happens. Azure Stream Analytics is a SQL-like query engine that processes streams in real-time.

I implemented:

Magnitude Calculations - Converting 3-axis accelerometer data into a single acceleration magnitude:

SQRT(accelerometer.x² + accelerometer.y² + accelerometer.z²)

Anomaly Detection - Using built-in ML algorithms to flag unusual patterns:

AnomalyDetection_SpikeAndDip(battery, 95, 85, 'spikesanddips')
  OVER (LIMIT DURATION(second, 60))

This function analyzes a 60-second sliding window and identifies battery spikes or dips with 95% confidence. No custom ML model needed, it's built into Stream Analytics.

Dual Outputs:

Raw data → Azure Data Lake Gen2 (for future ML training)
Processed data → Azure SQL Database (for business intelligence)

Phase 4: Data Storage Strategy

I used a two-tier storage approach:

Azure Data Lake Gen2 - Raw event archive

Every single event preserved
Parquet format for efficient querying
Foundation for future ML model training

Azure SQL Database - Curated analytical store

Two tables: Devices (metadata) and Telemetry (time-series data)
Proper foreign key relationships
Optimized for BI queries and joins

This mirrors real-world data lakehouse architecture, raw data in the lake, curated data in the warehouse.

Phase 5: .NET 8 Azure Function for Power BI Integration

Stream Analytics doesn't natively push to Power BI streaming datasets, so I built a custom Azure Function in .NET 8:

What it does:

Runs every minute on a timer trigger
Queries Azure SQL for new telemetry since last run
Batches records (up to 500 at a time)
POSTs JSON to Power BI's REST API
Tracks state using Azure Table Storage

Key technical decisions:

Isolated worker model (latest .NET Functions pattern)
Incremental processing to avoid duplicates
Batching to respect Power BI API limits
Idempotent operations for reliability

Phase 6: Power BI Visualization

The final piece was creating a live dashboard with:

Real-time KPI cards (latest battery %, acceleration)
Map visual showing device GPS locations
Time-series charts for trend analysis
Anomaly alerts highlighted in red

Power BI's streaming datasets update instantly, no refresh button needed.

What I Learned

Real-Time Data Engineering Patterns

Lambda architecture (hot path for real-time, cold path for batch)
Stream processing windowing (tumbling, hopping, sliding windows)
Event time vs processing time semantics
Idempotency and exactly-once processing

Azure Cloud Services

Before this project, I'd barely touched Azure. Now I'm comfortable with:

IoT Central device templates and exports
Event Hub partitioning and consumer groups
Stream Analytics query language and ML functions
Azure SQL managed databases
Azure Functions isolated worker model
Data Lake Gen2 hierarchical namespaces

Infrastructure as Code

I included a Terraform configuration in the repo as reference. While I deployed most resources through the Azure portal for faster iteration, I learned:

Resource definition with HCL syntax
State management concepts
Importance of IaC for reproducibility

.NET Backend Development

Writing the Azure Function taught me:

Async/await patterns in C#
Dependency injection in isolated worker model
HTTP client best practices
Configuration management (avoiding secrets in code)

Machine Learning Integration

I didn't build custom ML models, but I learned how to apply pre-built anomaly detection effectively:

Choosing appropriate sensitivity thresholds
Understanding spike vs. dip detection
Sliding window analysis
Real-time inference constraints

Technical Highlights Worth Sharing

Stream Analytics Query Design

The query processes raw events into multiple outputs simultaneously:

-- Raw passthrough to Data Lake
SELECT * INTO [RawOutput] FROM [IoTInput]

-- Device metadata extraction
SELECT DISTINCT deviceId, applicationId, templateId
INTO [DevicesOutput] FROM [IoTInput]

-- Enriched telemetry with anomalies
SELECT 
  deviceId,
  enqueuedTime,
  battery,
  SQRT(accel.x² + accel.y² + accel.z²) AS AccelMagnitude,
  CASE WHEN BatteryAnom.Score > 0.95 THEN 1 ELSE 0 END AS Anomaly
INTO [TelemetryOutput] FROM [IoTInput]

Database Schema for Time-Series Data

I designed normalized tables with proper indexing:

CREATE TABLE Devices (
  deviceId VARCHAR(50) PRIMARY KEY,
  applicationId VARCHAR(50),
  templateId VARCHAR(100)
);

CREATE TABLE Telemetry (
  telemetryId BIGINT IDENTITY PRIMARY KEY,
  deviceId VARCHAR(50) NOT NULL,
  enqueuedTime DATETIME2 NOT NULL,
  battery INT,
  AccelMagnitude FLOAT,
  Anomaly BIT DEFAULT 0,
  FOREIGN KEY (deviceId) REFERENCES Devices(deviceId)
);

The DATETIME2 type provides precision for time-series analysis, and the foreign key ensures referential integrity.

What's Next?

This project laid the foundation. Future enhancements could include:

Custom ML models trained on historical ADLS data (Python + Jupyter)
Managed Identity authentication instead of connection strings
Azure Key Vault integration for secrets management
Complete Terraform automation including Stream Analytics inputs/outputs
Predictive maintenance models using historical anomaly patterns

Try It Yourself

The project is open source on GitHub with all the code, SQL scripts, and configuration examples you need. Here's what's included:

Stream Analytics query files
SQL table creation scripts
.NET 8 Azure Function source code
IoT Central transformation templates
Terraform configuration reference
Architecture diagrams and documentation

Whether you're learning data engineering, exploring Azure, or building IoT solutions, this repo provides a complete reference implementation.

Resources for Students

Azure for Students: azure.microsoft.com/free/students

Don't forget:

GitHub Student Developer Pack (more free cloud credits)
JetBrains student licenses
DataCamp student subscriptions
Coursera student programs

The lesson: Companies invest heavily in student programs because they want you to learn their tools. Don't limit yourself to your university's offerings, actively seek out external resources. These "external organizations" can supercharge your learning journey.

Final Thoughts

This was my first real data engineering project, and it taught me that the best way to learn is by building. I could have watched tutorials or read documentation, but nothing compares to wrestling with real streaming data, debugging pipeline failures, and seeing live metrics update on a dashboard.

Starting with Azure's student tier removed the financial barrier completely. I experimented freely, broke things, rebuilt them, and learned through iteration, all without spending a dollar.

If you're a student interested in data engineering, cloud computing, or IoT, I encourage you to take advantage of these resources. Build something that processes real data, solves an actual problem, and demonstrates end-to-end technical skills.

The infrastructure is accessible. The tools are free. The only thing stopping you is getting started.

Github: https://github.com/Humza987/Azure_IoT_Realtime_Data_Pipeline

About This Post

This blog post was compiled from the project's README documentation combined with my personal reflections on the learning journey. The narrative was structured and refined with AI assistance to create a cohesive story of my first data engineering experience and the technical decisions behind the implementation.

Building Mindryx: From Local AWS Emulation to Production SaaS AI Quiz Generator

Humza Inam — Mon, 20 Oct 2025 17:32:58 +0000

A journey through serverless architecture, AI-powered learning, and the evolution of a full-stack quiz generation platform

What is Mindryx?

Mindryx is an AI-powered quiz generation platform that transforms how students interact with their study materials. Upload a PDF or enter any topic, and Mindryx generates tailored multiple-choice quizzes to help you learn more effectively.

Core Features

📝 Intelligent Quiz Generation

Create quizzes from any topic or PDF document. The platform uses advanced OCR (Optical Character Recognition) to extract text from even image-based PDFs, then leverages Google's Gemini Flash 2.0 API to generate contextually relevant questions.

📄 Unlimited PDF Processing

Unlike traditional LLM interfaces with restrictive file upload limits, Mindryx preprocesses PDFs using Tesseract.js OCR before sending them to the AI model. This approach bypasses typical file size constraints while taking advantage of Gemini's generous free tier.

📊 Progress Tracking

Review past quizzes, monitor your learning progress, and identify areas that need more attention. All quiz history and results are stored securely in a Supabase PostgreSQL database.

🤖 Experimental WebLLM Chat

An in-browser AI assistant runs entirely on your local machine, no API costs, no server calls, just pure client-side inference. This experimental feature showcases the future of accessible AI.

Tech Stack

Frontend: Next.js 15 with App Router, TailwindCSS 4
Backend: Supabase Edge Functions (Deno runtime)
Database: Supabase PostgreSQL
Authentication: Clerk Auth with server-side API protection
AI/ML: Google Gemini Flash 2.0, WebLLM, Tesseract.js OCR
Deployment: Vercel
Payments: Stripe (sandbox experimentation)

The Journey: Solving a Real Problem

The spark for Mindryx came from a frustration every student faces: file upload limits. When studying with AI tools like ChatGPT, I constantly hit walls trying to upload lengthy PDFs or image-based documents. I wanted to generate study materials from my lecture notes and textbooks, but the limitations made it impractical.

That's the problem Mindryx set out to solve unlimited PDF processing combined with AI-generated quizzes, all while leveraging free-tier APIs.

Phase 1: Learning Cloud Architecture with LocalStack

When I started this project, I had a clear goal: understand cloud infrastructure without prematurely committing to AWS costs. I wanted to learn Lambda, API Gateway, DynamoDB, and SQS, the building blocks of serverless architecture, but in a safe, local environment.

Enter LocalStack: A Docker-based AWS emulator that let me experiment freely.

What I Built

The testing branch became a fully functional serverless application running entirely on my machine:

AWS Lambda functions for quiz generation and data processing
DynamoDB for NoSQL data storage
SQS queues for asynchronous job processing
API Gateway for RESTful endpoints
SNS for notification experiments

This setup taught me the fundamentals of microservices architecture, event-driven design, queue-based processing, and stateless function execution. More importantly, it taught me Docker, which became crucial for containerized development and understanding modern DevOps practices.

Key Takeaways

Working with LocalStack gave me hands-on experience with serverless patterns before spending a dollar on cloud services. I learned how to structure Lambda functions, manage environment variables, handle cold starts, and design resilient async workflows. The testing branch remains a valuable learning sandbox for trying new AWS patterns.

Phase 2: Migration to Production Infrastructure

After proving the concept locally, I faced a decision: continue with AWS or explore alternatives? I chose Supabase and Vercel for production deployment, and this migration taught me an invaluable lesson, understanding multiple architectural approaches.

Why Supabase + Vercel?

Supabase Edge Functions: Deno-based serverless functions with excellent PostgreSQL integration
Built-in PostgreSQL: More familiar than DynamoDB for complex queries and relational data
Vercel Deployment: Seamless Next.js deployment with automatic optimizations
Developer Experience: Faster iteration cycles and simpler environment management

The Migration Challenge

Translating my LocalStack architecture to Supabase wasn't just a copy-paste job. I had to:

Convert Python Lambda functions to TypeScript/Deno Edge Functions
Redesign data models from NoSQL (DynamoDB) to SQL (PostgreSQL)
Rethink authentication flow with Clerk's server-side protection
Implement proper error handling for production environments

This process solidified my understanding of serverless fundamentals that transcend specific platforms, concepts like stateless execution, API design, and async processing apply whether you're using AWS Lambda or Supabase Edge Functions.

Authentication & Payment Integration

Clerk Auth

Implementing authentication from scratch is complex and error-prone. Clerk simplified this dramatically with:

Pre-built UI components for sign-up/sign-in
Automatic JWT handling
Server-side API route protection
User management dashboard

Integrating Clerk taught me about OAuth flows, session management, and securing API endpoints, all without building everything from scratch.

Stripe Experimentation

While Mindryx isn't monetized yet, I integrated Stripe's sandbox environment to understand payment flows. Though not fully setup, their developer friendly approach makes it obvious why its a favorite for many SaaS applications.

The WebLLM Experiment: AI Without Servers

The most fascinating technical feature in Mindryx is WebLLM, an in-browser AI chat that runs entirely on client-side compute.

Why This Matters

Traditional AI features require:

Server infrastructure to host models
API calls that cost money per request
Network latency for every interaction

WebLLM eliminates all of this. The model downloads once, then runs locally using WebGPU. No API costs, no server dependency, instant responses.

This technology is still experimental, but it represents a paradigm shift. Imagine AI-powered features in web apps that work offline, respect privacy completely, and cost nothing to operate at scale. I included it in Mindryx to raise awareness and showcase what's possible.

Technical Highlights

OCR Pipeline

The PDF processing pipeline was the most technically challenging component:

PDF.js extracts text from text-based PDFs
Canvas rendering converts PDF pages to images
Tesseract.js performs OCR on images to extract text
Preprocessing cleans and structures the extracted content
Gemini API generates quiz questions from the processed text

This multi-stage approach handles both native PDFs and scanned documents, working around file size limitations while maximizing the free tier.

Serverless Edge Functions

Supabase Edge Functions run on Deno at the edge, close to users globally. I structured them as:

quiz/new - Validates input and queues quiz generation
quiz/{quizId} - Retrieves quiz data with caching
submit - Processes answers and calculates scores
past-quizzes - Aggregates user history with pagination

Each function is stateless, meaning they scale automatically and stay fast under load.

What This Project Taught Me

MVP to Polished Product

Mindryx evolved from a rough proof-of-concept to a near-production SaaS application. This journey taught me:

Feature prioritization: Focus on core value before adding bells and whistles
Iterative refinement: Ship something that works, then improve it
User-centric design: Every technical decision should serve the end user

Cloud Architecture Fundamentals

By working with both LocalStack and Supabase, I developed platform-agnostic knowledge:

Serverless function design patterns
Async processing with queues
Database schema design (both NoSQL and SQL)
API security and authentication
Error handling and observability

Docker & DevOps

LocalStack's Docker-based approach gave me practical experience with:

Container orchestration
Environment isolation
Reproducible development setups
Docker Compose workflows

These skills are transferable to any modern development environment.

Current Status & Future Roadmap

Mindryx is nearly feature-complete as a SaaS product. The core functionality works reliably, authentication is secure, and the UI is polished. A few finishing touches would make it fully production-ready:

Planned Enhancements

Lesson Generation: Expand beyond quizzes to flashcards and study notes
Enhanced OCR: Better handling of tables, diagrams, and complex layouts
Spaced Repetition: Smart scheduling algorithms for optimal retention
Collaborative Features: Share quizzes and study together
Export Options: Generate PDFs and Anki decks from quizzes
Analytics Dashboard: Visualize learning progress and weak areas

Try It Yourself

Mindryx is live at mindryxify.vercel.app

The codebase is open source (MIT License) and available on GitHub. Whether you're interested in serverless architecture, AI integration, or building educational tools, feel free to explore the code and contribute.

Acknowledgments

This project wouldn't exist without incredible open-source tools:

Supabase for backend infrastructure
Google AI Studio for accessible Gemini API access
Clerk for authentication
Tesseract.js for OCR capabilities
WebLLM for browser-based AI
Next.js team for the excellent framework
LocalStack for AWS emulation during development

Final Thoughts

Building Mindryx was about more than creating a quiz app, it was about understanding modern web development from first principles. By starting with LocalStack's AWS emulation and migrating to Supabase, I gained perspective on different architectural approaches and learned which patterns are universal versus platform-specific.

The biggest lesson? Ship something that solves a real problem. I built Mindryx because I needed it as a student. That authentic need guided every technical decision and kept the project focused on delivering value.

If you're working on your own project, I encourage you to experiment with different architectures, learn by building, and don't be afraid to migrate when you find a better solution. The journey is just as valuable as the destination.

Github: https://github.com/Humza987/Mindryx

About This Post

This blog post was compiled from project README files documenting both the testing and production branches of Mindryx, combined with my personal reflections and scattered thoughts collected throughout the development journey. The narrative was structured and refined with AI assistance to create a cohesive story of the technical evolution and learning experiences behind the project.

Building SafeScript: Our Journey Creating a Security Tool for AI-Generated Code

Humza Inam — Mon, 20 Oct 2025 17:28:53 +0000

What six engineering students learned about security, AI, and teamwork over eight months

When our team started this capstone project, we had a simple observation: AI code generators like ChatGPT and GitHub Copilot are incredibly powerful, but they sometimes produce code with security vulnerabilities. What if we could catch those issues right in the IDE, as developers write?

Eight months later, we've built SafeScript, a VS Code extension that analyzes C code for common security vulnerabilities in real-time. Here's what we learned along the way.

The Problem We Tackled

AI-powered code generation has revolutionized development, but it comes with a catch. These tools can generate code that lacks essential safeguards against vulnerabilities like buffer overflows, path traversal, or insecure API calls. Developers might trust the generated code without thoroughly validating its security implications.

We wanted to build something that would help developers catch these issues early, without disrupting their workflow.

Why We Focused on C

We narrowed our scope to C for a good reason: it's notoriously unsafe. With no memory safety, unprotected pointers, and manual resource handling, C is prone to critical vulnerabilities like buffer overflows, use-after-free, and integer overflows.

By focusing on C, we could leverage language-specific syntax parsing to enable accurate, fine-grained analysis rather than relying on generic patterns.

This constraint actually helped us. Instead of building a shallow tool for many languages, we could create something truly useful for C developers.

The Technical Journey

From Line-by-Line to Method-Level Analysis

Our first version analyzed code line by line. It worked, but we quickly hit a wall: too many false positives. The tool would flag code as insecure without understanding the broader context of the function.

The breakthrough came when we switched to method-level analysis using Tree-sitter, an AST parser. This allowed us to:

Track buffer sizes throughout a function
Detect whether input validation was actually happening
Understand pointer relationships and memory usage patterns
Provide context-aware warnings that made sense

The difference was night and day. Our false positive rate dropped significantly, and the feedback became actually useful for developers.

What SafeScript Detects

We implemented detection for over 10 types of C-specific vulnerabilities:

Unsafe functions like strcpy, gets, sprintf with suggestions for safer alternatives
Buffer overflows through AST analysis of array indexing and memory operations
Hardcoded credentials and sensitive values
Heap overflows, race conditions, weak hashing, integer overflows
Each mapped to their corresponding CWE

The Architecture

We built SafeScript using a modular factory pattern. Each security check is its own class implementing a common interface, making it easy to add new tests or maintain existing ones independently.

Tech stack: TypeScript, VS Code API, Tree-sitter, Jest

The UI includes three key panels:

Security Analysis Panel – Shows detected issues with CWE/CVE details
AI Suggestion History – Tracks AI-generated improvements
Dual-mode Interface – Analyze existing code or generate new secure code

The Challenges

Server Security Wake-Up Call

We had a critical security issue early on. Our server was accepting direct requests without filtering, running everything as root. Anyone with the IP address could send malicious requests.

The fix? We implemented a reverse proxy that filters requests before they hit the main server. It was a humbling reminder that security tools need to be secure themselves.

The Machine Learning Pivot

Originally, we planned to implement a deep learning model for vulnerability detection. Reality check: we didn't have the time, compute resources, or training data.

Instead, we pivoted to a shallow Random Forest model that classifies code by CWE category. It's not as ambitious, but it works and gave us room to focus on what mattered most: the core detection engine.

UI: Harder Than It Looks

We underestimated UI development. Building an intuitive interface in VS Code's constrained environment took multiple iterations. What seemed simple on paper—showing vulnerabilities and suggestions—required careful design to avoid overwhelming developers.

Key Stats

8 months of development
4 agile sprints
10+ vulnerability types detected
Under 3 seconds analysis time
161 story points completed
$850 in free credits spent on server hosting

What We Learned

Start with an MVP, Really

We spent too long perfecting security rules before getting user feedback. If we could do it again, we'd ship a working prototype faster and iterate based on actual usage.

Constraints Are Liberating

Focusing exclusively on C might seem limiting, but it allowed us to build something genuinely useful instead of a mediocre multi-language tool.

Communication Makes or Breaks Teams

With six people juggling different schedules and skills, clear communication was essential. Regular standups, detailed sprint retrospectives, and thorough documentation kept us aligned.

Testing Prevents Embarrassment

Unit testing with Jest caught issues before they hit production. Our regression tests were crucial for reducing false positives as we refined detection rules.

What's Next

SafeScript is live, but we're not done. Future improvements we're considering:

Dynamic code analysis for runtime vulnerability detection
Project-level analysis across multiple files
Deeper machine learning integration for autonomous code fixes

Try It Yourself

SafeScript is available now on the VS Code Marketplace. If you write C code or work with AI-generated code, give it a try and let us know what you think.

Final Thoughts

This project taught us that building developer tools isn't just about the technology—it's about understanding workflows, earning trust, and making security feel like a helpful assistant rather than a nagging critic.

Looking back, we're proud of what we built. SafeScript started as a class project and became a real tool that addresses a genuine need in modern software development. The journey taught us more about engineering, security, and collaboration than any lecture could.

To anyone building developer tools: start small, focus on real problems, and don't be afraid to pivot when reality challenges your assumptions. The best tools emerge from iteration, not perfection.

Built by Team 13
York University - Lassonde School of Engineering
Capstone Project 2024-2025

This article was structured with AI assistance from our technical capstone report. All content, data, and experiences are from our team's actual development of SafeScript.

Connect with me on Linkedin
https://www.linkedin.com/in/humza-inam/