Allan Roberto’s Post

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

Built a production-style semantic search and RAG backend using Spring Boot, Spring AI, PostgreSQL + pgvector, and Ollama. The system ingests text and PDF documents, chunks them for embedding, stores vectors in PostgreSQL, performs similarity search, and passes the top matches into the generation layer to return grounded answers with source references. The goal was to build the retrieval pipeline properly in Java end-to-end, not just wrap an LLM with an API. repo : https://lnkd.in/d5qBGg6r #Java #SpringBoot #SpringAI #RAG #SemanticSearch #PostgreSQL #pgvector #BackendEngineering

🚀 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

🚀 #PythonJourney | Day 151 — BREAKTHROUGH: API Fully Functional & First Successful Request Today marks a major milestone: **the URL Shortener API is LIVE and responding correctly!** After 8 days of building and debugging, I finally got the first successful POST request working. This breakthrough moment proves that all the pieces fit together. Key accomplishments: ✅ Fixed critical database type mismatch:   • PostgreSQL was storing user_id as VARCHAR   • SQLAlchemy was trying to query with UUID   • Solution: Dropped volumes, rebuilt schema from scratch ✅ Fixed Pydantic response validation:   • Model had clicks_total, database had total_clicks   • Docker image was caching old code   • Solution: Forced rebuild of container image ✅ First successful API call:   • POST /api/v1/urls now returns proper JSON   • Short code generated automatically   • URL stored in database correctly   • Full response validation passing ✅ Production-ready API endpoints confirmed:   • Authentication working (API key validation)   • Request validation (Pydantic models)   • Database operations (CRUD)   • Error handling (proper HTTP status codes)   • Response serialization (JSON output) ✅ Lessons learned about debugging:   • Always check the actual container logs   • Volume management is critical in Docker   • Type consistency across layers matters   • Docker caching can hide recent changes   • Patience and persistence beat quick fixes What happened today: → Identified the root cause through careful log analysis → Understood the full request/response cycle → Learned when to reset vs. when to patch → Experienced the joy of a working API! The API now successfully: - Validates user authentication - Creates shortened URLs with unique codes - Stores data in PostgreSQL - Returns properly formatted JSON responses - Handles errors gracefully This is what backend development is about: building reliable systems piece by piece, debugging methodically, and celebrating when it finally works. Status update: - ✅ Backend: FUNCTIONAL - ✅ Database: WORKING - ✅ API Endpoints: RESPONDING - ✅ Authentication: VERIFIED - ⏳ Full test suite: Next - ⏳ Deployment: Next week #Python #FastAPI #Backend #API #PostgreSQL #Docker #Debugging #SoftwareDevelopment #Victory #CodingJourney

# 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

Part 1: Architecture & Real-World System Design Modern backend systems don’t break because of scale alone — they break due to complexity. In a recent redesign, the focus was on simplifying the handling of large, dynamic form data while improving performance, maintainability, and the developer experience. 📊 The shift: 🔹 From rigid column-based schema → flexible JSONB-based storage 🔹 From heavy raw SQL → clean ORM-driven queries 🔹 From scattered APIs → structured, minimal endpoints ⚙️ Architecture Improvements ✔️ Modular design using separate Django applications ✔️ Class-based views for reusable and maintainable logic ✔️ API structuring using Django Ninja Router ✔️ Reduced the number of APIs by consolidating responses ✔️ Strong alignment with frontend for payload and contract design 📦 Data Handling Strategy Instead of creating hundreds of columns for dynamic forms: → Stored complete form responses as JSON objects → Handled 300–500+ fields without schema changes → Simplified debugging with structured payloads → Enabled faster iteration without production risks 🔄 Processing Flow User Input → API Validation → Store JSON (status = 0) → Async Processing (Celery + Redis) → Update status = 1 → Dashboard reflects real-time updates 🚀 Outcome ✔️ Reduced schema complexity ✔️ Improved API performance ✔️ Avoided production issues caused by raw queries ✔️ Built a scalable and flexible backend system ✔️ Delivered smoother frontend-backend integration Security handled via JWT-based authentication with proper token flow. Still evolving with improvements in performance, validation, and system design. #BackendEngineering #Django #Python #SystemDesign #PostgreSQL #APIs #Celery #Redis #JWT

𝗙𝗮𝘀𝘁𝗔𝗣𝗜 𝗶𝘀 𝗺𝗼𝗿𝗲 𝘁𝗵𝗮𝗻 𝗷𝘂𝘀𝘁 "𝗳𝗮𝘀𝘁." 𝗜𝘁’𝘀 𝗮 𝗺𝗮𝘀𝘁𝗲𝗿𝗰𝗹𝗮𝘀𝘀 𝗶𝗻 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲 (𝗗𝗫). 💎 Most developers switch to FastAPI for the benchmark speeds, but they stay for the architectural "Hidden Gems" that make production-grade code actually maintainable. If you’re building scalable backends, these 3 features are game-changers: 1️⃣ 𝗧𝗵𝗲 𝗣𝗼𝘄𝗲𝗿 𝗼𝗳 𝗗𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻 (𝗗𝗜) FastAPI’s DI system isn't just for database sessions. It’s a tool for clean architecture. By creating hierarchical dependencies, you can inject authentication or logging logic across routes effortlessly. 2️⃣ 𝗘𝗳𝗳𝗶𝗰𝗶𝗲𝗻𝘁 𝗕𝗮𝗰𝗸𝗴𝗿𝗼𝘂𝗻𝗱 𝗧𝗮𝘀𝗸𝘀 Stop making your users wait for emails or logs to process. You don't always need the overhead of Celery or RabbitMQ. With the BackgroundTasks class, you can execute logic after the response is sent. 3️⃣ 𝗠𝗼𝘂𝗻𝘁𝗶𝗻𝗴 𝗦𝘂𝗯-𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻𝘀 Why clutter one file when you can mount entire FastAPI instances within a main app? This is the secret to clean API Versioning (v1 vs v2) and isolating microservices within a monorepo. Speed gets you noticed, but using these features is what keeps a codebase from becoming technical debt. Are you leveraging these in your current stack, or sticking to the basics? Let’s talk architecture in the comments. 👇 #Python #FastAPI #BackendEngineering #SystemDesign #CleanCode #SoftwareArchitecture #AWS

𝐅𝐫𝐨𝐦 𝐀𝐈 𝐒𝐜𝐫𝐢𝐩𝐭𝐬 𝐭𝐨 𝐒𝐜𝐚𝐥𝐚𝐛𝐥𝐞 𝐒𝐲𝐬𝐭𝐞𝐦𝐬 | 𝐅𝐮𝐥𝐥-𝐒𝐭𝐚𝐜𝐤 𝐎𝐫𝐜𝐡𝐞𝐬𝐭𝐫𝐚𝐭𝐨𝐫 🚀 In my last post, I talked about why Generative AI needs a solid backend to be useful. This week, I moved from theory to "Live on Production." I just finished and deployed my Full-Stack Task Orchestrator a system designed not just to manage tasks, but to serve as the structural foundation for the AI Agents. 𝐖𝐡𝐲 𝐅𝐮𝐥𝐥-𝐒𝐭𝐚𝐜𝐤 𝐌𝐚𝐭𝐭𝐞𝐫𝐬 𝐟𝐨𝐫 𝐀𝐈/𝐌𝐋 𝐄𝐧𝐠𝐢𝐧𝐞𝐞𝐫𝐬? Because an Agent without a structured database and a secure API is just a chatbot. Real-world AI needs to execute actions, maintain state, and handle user authentication. 𝗧𝗵𝗲 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 (𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻-𝗚𝗿𝗮𝗱𝗲): Instead of a simple script, I implemented a Modular Controller-Router-Model pattern: → Backend: FastAPI with strict Pydantic validation. → Auth: Secure JWT-based session management and password hashing (pwdlib). → Database: PostgreSQL with SQLAlchemy ORM and Alembic for migrations. → Frontend: A responsive React + Tailwind CSS dashboard to visualize data flow. 𝗟𝗶𝘃𝗲 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁: The project is fully containerized and deployed on Render. → Live Demo: https://lnkd.in/dD-gtaH2 → GitHub Repo: https://lnkd.in/dqZ36En3 #FullStack #FastAPI #ReactJS #PostgreSQL #AI #WebDevelopment #SoftwareArchitecture #BuildInPublic #Python #Deployment

🚀 𝗤𝘂𝗶𝘇 𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗕𝗮𝗰𝗸𝗲𝗻𝗱 𝗔𝗣𝗜 – 𝗕𝘂𝗶𝗹𝘁 𝘄𝗶𝘁𝗵 𝗙𝗮𝘀𝘁𝗔𝗣𝗜 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

🚀 The Myth of "10-Hour Vibe Coding": Architecting a Cloud-Native Brain for V3 🧠☁️ Everyone loves a good "I built this in 10 hours with AI" story. Yeah, right! 😅 What nobody tells you is that those initial 10 hours of vibe coding took me a solid month of hard yakka to refine into a proper, functioning memory sandbox. Moving from a local toy to a production cloud environment forced me into some deep engineering reality checks. 🛑 Local Docker Postgres was sweet as—sub-millisecond reads ⚡. But chucking it onto the cloud (Supabase)? Nah, mate. A 40ms network lag turned my DAG retrievals into a brutal N+1 query nightmare, freezing the UI for up to 5 seconds 🥶. You can't just run local sandbox code on a cloud server and hope for the best. So, I’m ripping into the V3 rewrite with a massive architectural shift to fully unleash Supabase's vector and graph potential: 🧠 Compute to Data: No more pulling heaps of data over the network to Python. I'm chucking the DAG traversal and vector cosine maths straight into Postgres RPCs. ⚡ Bypassing the Middleman: Next.js now talks straight to the DB via @supabase/ssr. Faster, leaner, and zero Python bottlenecks. 🤖 Background Worker: Demoting my Python FastAPI from a main server to a quiet internal worker agent. It handles AI logic and LLM deductions asynchronously via a message queue without causing network jitter. 🛡️ True Cloud-Native: Sorting out PgBouncer for transaction-level pooling and locking down strict RLS (Row Level Security) so everything is safe and sound. 🔒 Re-architecting this solo project from a local script into a true Serverless + Agentic beast has been a massive learning curve, but getting the engineering right is going to be absolutely brilliant. 🍻 Time to build! #BuildInPublic #Supabase #PostgreSQL #SoloDev #SoftwareEngineering #VectorSearch #Architecture