Tawfiq Hussein Farid’s Post

🚀 New blog post is live! When working with JavaScript, precision matters more than you might think. In my latest post, I explore how numeric precision loss can occur when using JavaScript, and more importantly, how to avoid it. If you're working with financial data, large integers, or anything where accuracy is critical, this is something you don’t want to overlook. 💡 Key takeaways: - Why JavaScript number handling can introduce precision issues - How MLE changes the way we think about data processing in the database - Practical techniques to preserve accuracy when working with numbers 👉 Read the full article here: https://lnkd.in/ejYKxeUD #OracleDatabase #JavaScript #DatabaseDevelopment #AI #MLE #DataEngineering

# New learning and Self imporvement Modern backend systems often don’t fail because of scale alone — they struggle due to complexity. In a recent architecture redesign, the focus was on simplifying how dynamic, large-scale form data is handled while improving performance, maintainability, and developer experience. The shift (as shown in the diagram): 🔹 Moved from rigid column-based schema → flexible JSONB-based storage 🔹 Replaced heavy raw SQL usage with clean Python ORM-driven data access 🔹 Introduced structured payload handling with clear state management (status-driven flow) ⚙️ Backend Architecture Improvements ✔️ Adopted a modular design using Django applications for better separation of concerns ✔️ Implemented class-based views for cleaner, reusable API logic ✔️ Structured API routing using Django Ninja Router for better organization and scalability ✔️ Reduced the number of APIs by consolidating responses into optimized, meaningful endpoints ✔️ Designed APIs in collaboration with frontend to ensure smooth data flow and minimal overhead 📦 Data Handling Strategy Instead of creating hundreds of columns for dynamic forms: → Stored complete form responses as JSON objects → Managed 300–500+ fields without schema changes → Simplified debugging with structured payload visibility → Enabled faster iteration without impacting production stability Processing Flow User Input → API Validation → Store JSON (status = 0) → Async Processing (Celery + Redis) → Update status = 1 → Dashboard Reflection 🚀 Outcome ✔️ Reduced system complexity significantly ✔️ Improved API performance and response clarity ✔️ Eliminated production risks caused by excessive raw queries ✔️ Created a scalable foundation for handling dynamic data ✔️ Delivered a smoother integration experience for frontend systems Security handled using JWT-based authentication with proper token flow. The system continues to evolve with ongoing improvements in validation, background processing, and performance tuning. #BackendEngineering #Django #Python #SystemDesign #PostgreSQL #APIs #Celery #Redis #JWT #SoftwareArchitecture

Built a personal project called 𝗥𝗲𝗲𝗹𝗩𝗮𝘂𝗹𝘁 over the past few weeks and wanted to share what went into it. 𝗧𝗵𝗲 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝗜 𝘄𝗮𝘀 𝘀𝗼𝗹𝘃𝗶𝗻𝗴: I watch a lot of content on Instagram and YouTube about AI tools, open source models, and dev resources. I kept losing track of things I wanted to revisit. 𝗖𝗼𝗺𝗺𝗲𝗻𝘁𝘀 𝗮𝗻𝗱 𝗯𝗼𝗼𝗸𝗺𝗮𝗿𝗸𝘀 𝗱𝗼 𝗻𝗼𝘁 𝗰𝘂𝘁 𝗶𝘁. So I built a full-stack application where I can save any link, reel, or note and 𝘀𝗲𝗮𝗿𝗰𝗵 𝗶𝘁 𝗹𝗮𝘁𝗲𝗿 𝘂𝘀𝗶𝗻𝗴 𝗻𝗮𝘁𝘂𝗿𝗮𝗹 𝗹𝗮𝗻𝗴𝘂𝗮𝗴𝗲. Not keyword search. Meaning-based search. Tech used: Backend — 𝗝𝗮𝘃𝗮 𝟮𝟭 with Spring Boot 3.2, Spring Data JPA, REST APIs Database — 𝗣𝗼𝘀𝘁𝗴𝗿𝗲𝗦𝗤𝗟 with 𝗽𝗴𝘃𝗲𝗰𝘁𝗼𝗿 extension on Supabase Embeddings — 𝗛𝘂𝗴𝗴𝗶𝗻𝗴 𝗙𝗮𝗰𝗲 Inference API using sentence-transformers/all-MiniLM-L6-v2 to convert 𝘁𝗲𝘅𝘁 𝗶𝗻𝘁𝗼 𝟯𝟴𝟰-𝗱𝗶𝗺𝗲𝗻𝘀𝗶𝗼𝗻𝗮𝗹 𝘃𝗲𝗰𝘁𝗼𝗿𝘀 Search — Cosine similarity search using 𝗽𝗴𝘃𝗲𝗰𝘁𝗼𝗿'𝘀 𝗶𝘃𝗳𝗳𝗹𝗮𝘁 𝗶𝗻𝗱𝗲𝘅 𝗧𝗲𝗹𝗲𝗴𝗿𝗮𝗺 𝗕𝗼𝘁 — built into the Spring Boot service, lets me send a URL and get it saved automatically with metadata extracted via Jsoup Frontend — Vanilla HTML, CSS, JS 𝗱𝗲𝗽𝗹𝗼𝘆𝗲𝗱 𝗼𝗻 𝗩𝗲𝗿𝗰𝗲𝗹 Deployment — 𝗗𝗼𝗰𝗸𝗲𝗿𝗶𝘇𝗲𝗱 𝗦𝗽𝗿𝗶𝗻𝗴 𝗕𝗼𝗼𝘁 𝗮𝗽𝗽 𝗼𝗻 𝗥𝗲𝗻𝗱𝗲𝗿 What I learned from actually shipping it: Hugging Face free tier uses a different endpoint than documented. Had to debug a 404 mid-production. Render is IPv4 only so Supabase Direct Connection does not work. Transaction Pooler with stringtype=unspecified in the JDBC URL is the fix. pgvector requires data to exist before the ivfflat index is useful. This project gave me hands-on experience with vector embeddings, semantic search, RAG-adjacent architecture, and end-to-end deployment on free-tier infrastructure. 𝗚𝗶𝘁𝗛𝘂𝗯 𝗹𝗶𝗻𝗸 𝗶𝗻 𝗰𝗼𝗺𝗺𝗲𝗻𝘁𝘀. #Java #SpringBoot #SemanticSearch #VectorDatabase #pgvector #HuggingFace #BackendDevelopment #FullStackDevelopment #RAG #GenerativeAI #AIEngineering #PostgreSQL #Docker #SoftwareEngineering #OpenSource

𝐚𝐬𝐲𝐧𝐜/𝐚𝐰𝐚𝐢𝐭 does NOT automatically make your code faster. Most beginners think it does. That's one of the biggest misconceptions in .NET. To truly understand what it actually does, we need to look back at how we used to write code. Before 𝐚𝐬𝐲𝐧𝐜/𝐚𝐰𝐚𝐢𝐭 existed, developers had one default habit: 👉 "Do one thing at a time, in order." 𝙫𝙖𝙧 𝐝𝐚𝐭𝐚 = 𝗚𝗲𝘁𝗗𝗮𝘁𝗮𝗙𝗿𝗼𝗺𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲(); 𝙫𝙖𝙧 𝐟𝐢𝐥𝐞 = 𝗥𝗲𝗮𝗱𝗙𝗶𝗹𝗲(); 𝙫𝙖𝙧 𝐫𝐞𝐬𝐮𝐥𝐭 = 𝗖𝗮𝗹𝗹𝗔𝗽𝗶(); Looks clean and fine. But here's the hidden problem, each line blocks everything behind it. If 𝐆𝐞𝐭𝐃𝐚𝐭𝐚𝐅𝐫𝐨𝐦𝐃𝐚𝐭𝐚𝐛𝐚𝐬𝐞() takes 3 seconds, the thread waits. The app waits. Everything waits. Your app is basically saying: "I refuse to continue life until SQL Server answers me." Imagine a waiter who takes your order, then stands frozen at the counter for 20 minutes staring at the kitchen, unable to serve anyone else. That's dumb. But that's exactly how a lot of code used to behave. Before 𝐚𝐬𝐲𝐧𝐜/𝐚𝐰𝐚𝐢𝐭, we tried to fix this with things like: 🔹 𝐁𝐞𝐠𝐢𝐧𝐑𝐞𝐚𝐝/𝐄𝐧𝐝𝐑𝐞𝐚𝐝 (𝐀𝐏𝐌): Powerful, but it made your code look like a jigsaw puzzle. 🔹 𝐂𝐚𝐥𝐥𝐛𝐚𝐜𝐤𝐬: "Call me when you're done." It worked, but it led to "Callback Hell"— code that was impossible to read or debug. In 2012, C# 5.0, .NET changed the game. They didn't make the "burger" (the database call) cook faster. They just made the Waiter smarter. Here is what the class and keywords actually mean: ✅ 𝐓𝐚𝐬𝐤: Think of this as a 𝐁𝐮𝐳𝐳𝐞𝐫 you get at a food court. It’s a "promise" that your food will be ready later. You can carry the buzzer around, put it on the table, or check it. ✅ 𝐀𝐬𝐲𝐧𝐜: This just tells the compiler: "Hey, this method is allowed to use Buzzers." ✅ 𝐀𝐰𝐚𝐢𝐭: This is the magic part. It says: "I’m going to pause this story here. Waiter, go serve other tables. When my buzzer goes off, come back and finish this." 𝐓𝐡𝐞 𝐓𝐫𝐮𝐭𝐡: 𝐈𝐭’𝐬 𝐚𝐛𝐨𝐮𝐭 𝐒𝐜𝐚𝐥𝐚𝐛𝐢𝐥𝐢𝐭𝐲, 𝐧𝐨𝐭 𝐒𝐩𝐞𝐞𝐝 If a Database takes 2 seconds to answer, 𝐚𝐰𝐚𝐢𝐭 will still take 2 seconds. It’s not "faster." But while that 2-second wait is happening, your server's 𝐓𝐡𝐫𝐞𝐚𝐝 is released. It goes and handles other users. 𝐀𝐬𝐲𝐧𝐜/𝐚𝐰𝐚𝐢𝐭 𝐢𝐬 𝐚𝐛𝐨𝐮𝐭 𝐝𝐨𝐢𝐧𝐠 𝐌𝐎𝐑𝐄 𝐰𝐢𝐭𝐡 𝐋𝐄𝐒𝐒. It keeps your UI from freezing and your Server from crashing under pressure. It turned "Standing Waiters" into "Productive Servers." We’ve moved from manually managing threads and messy callbacks to code that reads like a simple, top-to-bottom story. But here’s the real question that trips people up: If await pauses the method and releases the thread... how does the code know exactly where to pick up when the result comes back? There is a "hidden machine" inside the .NET runtime that manages this, and it’s crazier than you think. Maybe that’s a story for the next post. 😉 #dotnet #csharp #backend #programming #softwareengineering

🧠Claude Code SKILL chaining system that actually works🚀 Generic AI code reviews usually stay surface-level. They miss real issues especially when changes span across stacks (frontend, backend, database). 💡 Designed a Claude Code based hierarchical skill architecture to actually handle this properly How it’s structured: 📍fullstack-master → Analyzes request context, selects optimal skill combination & coordinates execution. 📍 Orchestrator skill → Decompose complex workflows, delegate to specialists, synthesize results 📍Specialist skill → deep expertise (React, Python, Spring Boot, PostgreSQL) 🎯 What happens on a typical PR (React + Spring Boot + PostgreSQL): 1️⃣ Entry layer analyzes the request and detects cross-stack changes 2️⃣ Selects the right orchestrator skill based on task type 3️⃣ Orchestrator decomposes work and delegates to multiple specialist skills in parallel 4️⃣ Outputs get stitched into a single unified report 5️⃣ Cross-stack contracts + edge cases get validated Example (Code Review) 👇 A PR: - Updates a React component - Modifies a Spring Boot API - Tweaks a PostgreSQL query Flow inside Claude Code: 1️⃣ fullstack-master analyzes the PR and detects multi-stack changes 2️⃣ Routes to fullstack-code-review (orchestrator) 3️⃣ Orchestrator decomposes the review and triggers specialist skills • 🟢 react-code-review skill → flags missing validation and unnecessary re-renders • 🟡 springboot-code-review → catches null handling issue in API • 🔵 postgresql-architect → identifies slow query (missing index) 4️⃣ Orchestrator synthesizes findings, validates cross-stack contracts (API schema matches frontend expectations, query performance meets SLA), and aggregates everything into one clean output What actually improved: ✅ Better detection of real, production-level issues 🔥 ✅ Clear ownership — each skill does ONE thing well 🎯 ✅ Context flows properly across Claude Code skills 🔄 🚀Big takeaway: Claude Code SKILLS really shine when it is built as a system of focussed skills —not a single oversized skill. #AI #ClaudeCode #SoftwareEngineering

🔥 𝗕𝗮𝗰𝗸𝗲𝗻𝗱 𝗙𝗲𝗲𝗹𝘀 𝗛𝗮𝗿𝗱… 𝗕𝗲𝗰𝗮𝘂𝘀𝗲 𝗬𝗼𝘂’𝗿𝗲 𝗙𝗼𝗹𝗹𝗼𝘄𝗶𝗻𝗴 𝘁𝗵𝗲 𝗪𝗿𝗼𝗻𝗴 𝗥𝗼𝗮𝗱𝗺𝗮𝗽 Let’s be honest. Most developers don’t hate backend. They hate the confusion around it But backend is not hard, unclear roadmap is. Here’s a clean, practical roadmap that actually works 👇 🧭 Step-by-Step Backend Roadmap (That Makes Sense) 1️⃣ 𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱 𝗛𝗼𝘄 𝘁𝗵𝗲 𝗪𝗲𝗯 𝗪𝗼𝗿𝗸𝘀 Before coding anything: • What happens when you hit a URL? • How request → response cycle works? • Client → Server → Database flow This is your foundation. 2️⃣ 𝗠𝗮𝘀𝘁𝗲𝗿 𝗢𝗻𝗲 𝗟𝗮𝗻𝗴𝘂𝗮𝗴𝗲 𝗣𝗿𝗼𝗽𝗲𝗿𝗹𝘆 Choose one: • Java / Node.js / Python Focus on: • functions • async behavior • error handling Depth > multiple languages. 3️⃣ 𝗟𝗲𝗮𝗿𝗻 𝗕𝗮𝗰𝗸𝗲𝗻𝗱 𝗙𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸 𝗕𝗮𝘀𝗶𝗰𝘀 Pick one: • Spring Boot (Java) • Express.js (Node) • Django / Flask (Python) Understand: • routing • controllers • middleware • project structure 4️⃣ 𝗕𝘂𝗶𝗹𝗱 𝗥𝗘𝗦𝗧 𝗔𝗣𝗜𝘀 This is core backend work: • GET, POST, PUT, DELETE • request/response handling • status codes Build small APIs first. 5️⃣ 𝗟𝗲𝗮𝗿𝗻 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲𝘀 𝗣𝗿𝗼𝗽𝗲𝗿𝗹𝘆 • SQL (MySQL/PostgreSQL) • NoSQL (MongoDB) Focus on: • schema design • indexing • query optimization 6️⃣ 𝗔𝗱𝗱 𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻 & 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 • JWT / sessions • password hashing • CORS • API protection This is where most beginners fail. 7️⃣ 𝗛𝗮𝗻𝗱𝗹𝗲 𝗘𝗿𝗿𝗼𝗿𝘀 & 𝗟𝗼𝗴𝗴𝗶𝗻𝗴 • global error handling • logging systems • debugging strategies Real-world systems fail - be ready. 8️⃣ 𝗟𝗲𝗮𝗿𝗻 𝗖𝗮𝗰𝗵𝗶𝗻𝗴 & 𝗣𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 • Redis basics • reducing DB calls • response optimization 9️⃣ 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 & 𝗘𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁 𝗦𝗲𝘁𝘂𝗽 • environment variables • build process • hosting your backend No deployment = incomplete backend skill. 🔟 𝗕𝗮𝘀𝗶𝗰 𝗦𝘆𝘀𝘁𝗲𝗺 𝗗𝗲𝘀𝗶𝗴𝗻 𝗧𝗵𝗶𝗻𝗸𝗶𝗻𝗴 • scalability • handling traffic • failure management This separates average from strong candidates. 💡 Important Truth - Backend is not tough. - Random learning is. Follow a roadmap → build step by step → connect concepts. You’ll start enjoying it. Stop avoiding backend. Start learning it the right way. Save this roadmap if you’re starting backend. #backend #roadmap #SystemDesign

Part 2: What Actually Matters in Backend Development After working on backend redesigns and handling large-scale data systems, one thing stands out: Tools don’t make systems scalable — understanding does. For anyone working with Python, Django, and APIs, here are the fundamentals that actually matter: 🧠 Core Thinking ✔️ Understand complete data flow: frontend → API → DB → processing → response ✔️ Design for flexibility, not just immediate requirements ✔️ Think about debugging, scaling, and long-term maintenance 🐍 Python ✔️ Strong grasp of data structures and OOP ✔️ Writing modular, clean, and reusable code ✔️ Proper validation and error handling 🌐 Django & APIs ✔️ Clear architecture (apps, models, views separation) ✔️ Use class-based views for structured design ✔️ Prefer ORM over raw queries ✔️ Optimize queries (select_related, indexing basics) ⚡ API Design (Django Ninja) ✔️ Clean routing and schema validation ✔️ Minimal and meaningful endpoints ✔️ Strong request/response contracts with frontend 🗄️ Database Concepts ✔️ When to use relational schema vs JSON storage ✔️ Handling dynamic data using JSON/JSONB ✔️ Query optimization and indexing basics 📦 Data Modeling ✔️ Design scalable payload structures ✔️ Handle dynamic forms efficiently ✔️ Use status-based workflows for processing ⚙️ Application-Level Practices ✔️ Reduce unnecessary APIs ✔️ Use background processing (Celery + Redis) ✔️ Secure APIs with JWT ✔️ Build logging and debugging into the system 🚀 Key Takeaway A strong backend system is not the one with more features — It’s the one that is simple, scalable, and reliable in production. #Python #Django #BackendDevelopment #SystemDesign #APIs #PostgreSQL #SoftwareEngineering

🚀 Built a Production-Grade RAG System with Spring Boot Most GenAI projects stop at “chatbot with PDFs”. I wanted to go deeper - and build something closer to how real backend systems work. Over the past few days, I designed and implemented a Spring Boot-based RAG system that ingests and queries knowledge across multiple sources. 🔧 What I built: 1️⃣ Ingestion Layer Multi-source connectors for PDFs, wiki documents, and PostgreSQL — with incremental updates. 2️⃣ Chunking Strategy (Critical for RAG) PDFs → fixed-size pragmatic chunks Wikis → semantic sections DB → row-level chunking 3️⃣ Embeddings + Vector Store Ollama embeddings Redis vector store with rich metadata (source, timestamps, access rules) 4️⃣ Retrieval Pipeline Semantic search + metadata filtering Supports domain constraints (date ranges, visibility rules) 5️⃣ Prompt Orchestration Grounding rules + structured prompts Source-aware responses with citations (reduced hallucination) 6️⃣ Knowledge Lifecycle Management Admin APIs to ingest/delete sources independently No need for full re-indexing 💡 Key Learnings: ✔️ Chunking strategy matters more than model choice ✔️ Metadata design = production-grade retrieval ✔️ Local models (Ollama) are great for cost-efficient development ✔️ RAG systems are fundamentally backend + data problems, not just AI 🧱 Tech Stack: Java 17 • Spring Boot 3.5 • Spring AI • Redis • PostgreSQL • Ollama 🔗 Repo: https://lnkd.in/dR5drAU3 Next: → Adding React UI for interactive querying → Writing a deep-dive on RAG system design & trade-offs #SpringBoot #RAG #AIEngineering #Backend #Java #SystemDesign

What "Idiomatic Go" Actually Means (And Why You Should Care) 🐹 I almost installed Gin for a personal project. Then I read the standard library docs. Here is what I learned about writing Go the way Go was meant to be written. When most developers pick up Go after JavaScript or Python, they do the same thing they always do. They open a terminal and start looking for packages. A web server? Find a framework. Database migrations? Find a library. JSON parsing? There must be a package for that. That instinct makes sense in other ecosystems. In Node.js, the standard library is deliberately minimal — the community fills the gaps. In Python, third-party packages are a first-class part of the experience. The assumption is that you will be pulling in dependencies constantly. Go was built on a different philosophy entirely. When I started a personal project recently, my first move was to reach for Gin. It is the obvious choice — everyone uses it, the docs are good, and I already knew it from building PakSentiment. But before installing it I spent ten minutes with Go's standard library documentation. What I found stopped me from opening my terminal. Go ships with a production-ready HTTP server and router built in. net/http handles routing, middleware, request parsing, and response writing without a single external dependency. For most backend services that do not need the specific extras Gin provides — and most do not — it is genuinely all you need. The code you write against it is explicit, readable, and has zero abstraction between you and what is actually happening. The same principle applies to database tooling. I chose golang-migrate for schema migrations instead of a full ORM. No magic. No hidden queries. No "where did that SQL come from" moments. You write the SQL, you control exactly what runs, and the binary stays small and fast. This is what idiomatic Go actually means. It is not about following style guides or formatting rules. It is about understanding that Go was designed to be explicit over abstract, lightweight over feature-rich, and clear over clever. The language authors put enormous effort into the standard library precisely so that you would not need to look elsewhere for most things. Every external package you add is a dependency you now own. It needs updating, it can break, it adds to your binary size, and it introduces abstractions you did not write and may not fully understand. Go's philosophy asks you to ask the question first: does the standard library already solve this? More often than you expect, the answer is yes. where you can read more: https://lnkd.in/dJFDuT2C #golang #softwaredevelopment #backenddevelopment #programming #softwareengineering #pakistan

🚀 𝗤𝘂𝗶𝘇 𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗕𝗮𝗰𝗸𝗲𝗻𝗱 𝗔𝗣𝗜 – 𝗕𝘂𝗶𝗹𝘁 𝘄𝗶𝘁𝗵 𝗙𝗮𝘀𝘁𝗔𝗣𝗜 I recently built a backend system for a Quiz Application using modern Python backend technologies. 🔧 𝗧𝗲𝗰𝗵 𝗦𝘁𝗮𝗰𝗸: • FastAPI (High-performance API framework) • SQLAlchemy (ORM for database management) • PostgreSQL (Relational database) • Pydantic (Data validation & schema handling) 📌 𝗞𝗲𝘆 𝗙𝗲𝗮𝘁𝘂𝗿𝗲𝘀: • RESTful API endpoints for questions and choices • One-to-many relationship between Questions and Choices • Secure database session handling with dependency injection • Proper request validation using Pydantic models • Clean and scalable backend architecture 🔗 𝗔𝗣𝗜 𝗘𝗻𝗱𝗽𝗼𝗶𝗻𝘁𝘀: • GET /questions/{question_id} → Fetch a specific question • GET /choices/{question_id} → Fetch all choices for a question • POST /questions → Create a question with multiple choices 🧠 𝗪𝗵𝗮𝘁 𝗜 𝗟𝗲𝗮𝗿𝗻𝗲𝗱: • How FastAPI handles async backend development efficiently • Working with SQLAlchemy ORM for relational data modeling • Designing clean backend architecture with separation of concerns • Implementing database relationships and migrations logic 💻 𝗚𝗶𝘁𝗛𝘂𝗯 𝗥𝗲𝗽𝗼𝘀𝗶𝘁𝗼𝗿𝘆: 👉 https://lnkd.in/dHJczetV This project helped me strengthen my understanding of backend development, API design, and database integration. #FastAPI #Python #BackendDevelopment #APIs #SQLAlchemy #PostgreSQL #SoftwareEngineering #LearningByBuilding