Backend engineering,explained visually.

معرفی سامانه «ریسک من»؛ مرتبط با پوشش خبری دانشگاه علوم پزشکی شهید بهشتی درباره رونمایی این سامانه برای ارزیابی ریسک و ارائه راهنمایی سلامت در دوران کرونا. خبر مرتبط: https://sbmu.ac.ir/all_news/%D8%A7%D8%B2-%D8%B3%D8%A7%D9%85%D8%A7%D9%86%D9%87-%D8%B1%DB%8C%D8%B3%DA%A9-%D9%85%D9%86-%D8%B1%D9%88%D9%86%D9%85%D8%A7%DB%8C%DB%8C-%D8%B4%D8%AF

Have you ever wondered how to turn years of scattered technical articles, markdown notes, and complex JSON payloads into an interconnected, highly intelligent AI assistant? In this video, we walk through the step-by-step technical journey of building a GraphRAG (Graph Retrieval-Augmented Generation) reasoning engine from scratch to power a highly context-aware software architecture chatbot. 🚨 THE PROBLEM: Why Traditional RAG Fails Standard Retrieval-Augmented Generation (RAG) relies on flat vector similarity and keyword search. While this works fine for finding isolated paragraphs, it completely breaks down on complex, multi-hop architectural questions. For example, if you ask, "How does our streaming Kafka ingestion pipeline handle deadlocks and schemas when inserting into ClickHouse?", standard RAG will likely return disjointed text snippets about Kafka or ClickHouse, missing the structural connection entirely. Furthermore, simple similarity algorithms suffer from "Hub-Node Distortion". If two unrelated blog posts share a broad tag like #MachineLearning, standard Jaccard similarity erroneously scores their connection at a perfect 1.0, generating severe false positives. 💡 THE SOLUTION: An Interconnected Knowledge Graph To solve this, we transform chronological, unstructured archives into a high-fidelity Knowledge Graph. Here is the exact pipeline: 1️⃣ Data Staging & Formatting: We use an automated Python script (build_kg_docs.py) to convert raw JSON records into clean, structured Markdown documents with explicit frontmatter and headers. 2️⃣ Knowledge Graph Extraction: Using a graph extraction tool (graphify) routed through an LLM, we extract entity-relation-entity triples and multi-component system hyperedges. This uncovers the core pillars of the technical writing (Go, Kafka, ClickHouse, Keycloak, etc.). 3️⃣ Adamic-Adar Similarity: We implement an Adamic-Adar / Inverse-Degree Weighted Similarity algorithm in Python. This weights rare technical concepts heavily and broad concepts lightly, eliminating false similarity matches. 4️⃣ Breadth-First Search (BFS) Retrieval: We build a custom reasoning engine (graph_rag.py) that matches query keywords to seed graph entities, performs BFS expansion to extract a relevant localized subgraph, and passes this rich context to the LLM. 5️⃣ Frontend Integration: We wire the graph to a TanStack Router frontend using a normalized slug resolver to support fuzzy matching across articles. 🎯 What This Enables By shifting from flat vector search to an interconnected Knowledge Graph, we unlock: 🌐 Interactive Navigation: Genuinely related post recommendations based on shared architectural topology rather than simple keyword collisions. 🤖 Context-Aware Chatbot: An AI assistant that truly understands the relationships between Go workers, Kafka pipelines, Redis caches, and ClickHouse databases. 🔍 Knowledge Gap Audits: A visual way to find isolated concepts and thin communities, creating a clear roadmap for future deep-dive articles. 🛠️ Key Technologies & Frameworks Mentioned: Graph Database & Extraction: Graphify, OpenAI API (gpt-5.6-luna) GraphRAG Architecture: Python, Breadth-First Search (BFS) Scale-Aware Systems: Go, Kafka, Redis, ClickHouse, Keycloak, OpenFGA Frontend: TanStack Router If you found this technical breakdown helpful, please LIKE, SHARE, and SUBSCRIBE for more deep dives into software architecture, Knowledge Graphs, and LLM orchestration! 🔔

How does an engineer’s mind change over a decade of building production systems? Twelve years ago, I wrote a book called "Chess with Ludo Rules" and believed that "programming is the philosophy to protest against everything". To my 2014 self, the target was simple: closed-source software. If I couldn't see inside a system, I didn't trust it. Fast forward to today, and my perspective has fundamentally shifted. In this video, I share my personal transition from an idealistic open-source rebel to a pragmatic systems architect. I break down why simply making code "open" isn't enough anymore, and how unconstrained human and technical processes behave exactly like unbounded system loops—consuming trust, goodwill, and resources until everything crashes. If you are a junior engineer looking to understand how the unit of reasoning changes as you grow, or a senior leader managing the trade-offs of modern scale, this video is for you. What we cover in this video: 📌 00:00 - The 2014 Rebel: Closed Source is the Enemy 📌 02:15 - The Realization: Open systems can still be used against us 📌 04:30 - What is an "Unbounded Process" in human teams? 📌 07:15 - Why we must design honest constraints 📌 09:45 - Junior vs. Senior: Shifting from principles to trade-offs 📌 12:30 - Pragmatic Systems Thinking in Action (Go, Kafka, ClickHouse) 🔗 Read my full articles and view my open-source blueprints: https://mobinshaterian.com/blog/Me-Against-Myself--From-Rebellious-Idealism-to-Pragmatic-Systems-Thinking-bzrae 💬 Let's discuss: How has your software engineering philosophy changed over your career? Drop a comment below! #SoftwareEngineering #SystemDesign #Golang #SoftwareArchitecture #SystemsThinking #CareerDevelopment #ClickHouse #Kafka

Are you struggling with **database migration conflicts** during large-scale refactors? This video explores why legacy and refactor branches often represent incompatible views of the same database and why pointing them at the same development instance is a recipe for disaster. In this guide, we break down why migration tools fail when histories diverge—explaining that they track the **sequence of operations** and checksums rather than just the final schema shape. We also dive into why common "fixes" like `IF NOT EXISTS` can paper over dangerous schema drift. **What you will learn:** * **The Isolation Model:** How to host multiple independent databases on a single local MySQL server to keep your development environment predictable. * **Step-by-Step Setup:** A walkthrough of creating branch-specific databases, granting privileges, and managing environment variables safely. * **The Safe Branch-Switching Routine:** A deliberate workflow for stopping applications and using specific Docker flags (`--no-deps`, `--force-recreate`) to ensure environment variables are correctly reloaded. * **Verification & Recovery:** How to triple-check that your Git branch, environment variables, and migration logs agree before running any commands, and how to recover if a cross-branch migration occurs. * **Converging for Release:** Strategies for merging your refactor, including choosing a canonical history and running **clean-install vs. upgrade tests** to catch different failure classes. **Key Strategy:** Isolate divergent histories during development, then converge them deliberately before you ever hit production. Stop fighting your migration history and start **isolating your databases** for a smoother, safer refactoring experience.

🚀 Migrating from database-backed sessions to stateless JWT authentication is one of the most impactful architectural upgrades you can make for a scaling NestJS application. But authentication refactoring is a cross-cutting change that touches everything—controllers, guards, CASL policies, request context, and your test suite. In this video, we break down a complete migration journey, showcasing how you can leverage Generative AI coding agents to accelerate this process while avoiding the dangerous "local correctness" trap. 💻 READ THE FULL ARTICLE AND RESOURCES HERE: [Insert Link to Article/Github Repository] 🧠 KEY CONCEPT: The Database Scalability Math Before the migration, every protected request required multiple authentication/authorization queries (reading session keys, fetching user data, loading roles/permissions, checking project membership). Load = R × Q (where R = requests/sec, Q = queries/request) After the migration, authentication becomes stateless at the API boundary, validating a signed JWT locally. Load = I × T + Resource-specific queries (where I = token-issuance/sec, T = claim-assembly queries) For a workload of 1,000 req/sec, this shifts the repeated authorization load from the request frequency directly down to token-issuance frequency—reducing thousands of queries per second! 🤖 HOW AI ACCELERATES DEPLOYMENT: Coding agents excel at repository-wide searches and repetitively modifying boilerplate. We used AI for: - Mapping session cookie dependencies across the entire codebase. - Generating and propagating the typed claims contract. - Rewriting repetitive unit and E2E test setups. - Automating TypeScript type-error fixes. ⚠️ THE AI TRAP: "Local Correctness" AI is incredibly fast, but it can write code that looks perfect in isolation while failing systemically. An agent might hide a session-cookie workaround inside a test helper to get tests to pass without actually using bearer tokens. To control AI agents, you need: 1. A highly descriptive Software Requirements Specification (SRS) with explicit inclusions/exclusions. 2. Robust black-box End-to-End (E2E) tests that test the actual HTTP boundary rather than internal mocks. --- 🔧 RESOURCES & CONFIGURATION: - NestJS: https://nestjs.com/ - CASL (Authorization): https://casl.js.org/ - Passport JWT: https://docs.nestjs.com/security/authentication#jwt-functionality 💬 Let us know in the comments: Have you migrated from sessions to JWTs? What are your favorite prompt strategies for codebase-wide refactoring? #NestJS #JWT #SoftwareArchitecture #ArtificialIntelligence #WebDevelopment #Backend #TypeScript #CodingAgent #SoftwareEngineering #Programming

### **Simple Explanation of the Articles** Imagine you are running a massive construction company with over **10,000 projects**. Right now, all your data (tasks, budgets, comments) is stored in a traditional database (MySQL) where everything is neatly organized but disconnected across dozens of tables. The problem is that every time a manager wants a "Project Overview," the database has to do a massive amount of "math" (joins and calculations) to put that picture together. This makes your app slow. **The articles explain a three-step fix:** 1. **Don’t do the work when someone asks; do it when the data changes:** Instead of calculating a project’s total cost every time a user refreshes the page, calculate it the moment a single expense is added. 2. **Use a "Digital Assistant" (CDC):** Tools like **Debezium and Kafka** "watch" your MySQL database. Every time something changes, they grab that change and send it downstream instantly without slowing down the main system. 3. **Build "Ready-to-Read" Documents:** You send those changes to **MongoDB**, which stores a single "Overview Document" for each project that is already filled out and ready to go. When a user clicks "View Project," the app just grabs that one document instead of doing hours of "relational math". 4. **Google-like Search:** For searching across thousands of projects, the articles recommend **MongoDB Atlas Search** (or dedicated engines like Meilisearch). These tools are built specifically to handle typos and find results instantly, which standard databases struggle with. ### **YouTube Video Description** **Title Ideas:** * *Stop Using Slow SQL Joins: Scaling to 10,000+ Projects with CDC* * *MySQL to MongoDB: Building High-Performance Read Models* * *System Design: Fast Search & Reporting with Debezium, Kafka, and MongoDB* **Description:** Are your SQL joins slowing down as your data grows? In this video, we dive into a professional architectural strategy for scaling enterprise project intelligence. We're moving beyond traditional 3NF MySQL structures to a decoupled, event-driven architecture designed for sub-50ms query speeds. **What you’ll learn:** * **The Power of CDC:** How to use Debezium and Kafka to capture database changes in real-time without impacting your production MySQL instance. * **Request-Time vs. Change-Time:** Why moving expensive aggregations (like budget totals and task counts) to the "write" phase is the key to instant dashboards. * **MongoDB for Read Models:** How to design denormalized "Project Overview" documents that eliminate the need for complex joins. * **Advanced Search:** Comparing Native MongoDB Text Indexes vs. Atlas Search (Lucene) vs. dedicated engines like Meilisearch for fuzzy matching and autocomplete. * **Scaling to 10k+ Projects:** Why the number of projects isn't your bottleneck—and how to handle the real variables like peak change rates and searchable text volume. **Tech Stack Mentioned:** * **Primary Database:** MySQL (Prisma ORM) * **Data Pipeline:** Debezium, Apache Kafka, Redpanda * **Read/Search Layer:** MongoDB, Atlas Search, Typesense, Meilisearch **Key Chapters:** 0:00 The Problem: Slow Joins in 3NF MySQL 2:15 Introduction to Change Data Capture (CDC) 5:30 Building the Projection Service 8:45 MongoDB Schema Design: The Computed Pattern 12:10 Full-Text Search: Atlas Search vs. Dedicated Engines 15:40 Production SLOs and Monitoring #SystemDesign #MongoDB #MySQL #Kafka #Debezium #SoftwareArchitecture #DatabaseScaling --- ### **Summary of the Core Articles** * **The Transition Strategy:** The sources advocate for **Command Query Responsibility Segregation (CQRS)**. MySQL remains the "source of truth" for writing data, while MongoDB acts as a high-speed "read model" for displaying it. * **Schema Design:** Instead of copying MySQL tables exactly, you should create **denormalized documents**. For example, a `project_overviews` document should already contain pre-calculated counts for tasks, files, and costs so the UI can load them instantly. * **Search Optimization:** For enterprise-grade search, **MongoDB Atlas Search (using Apache Lucene)** is preferred over legacy text indexes because it supports complex features like BM25 scoring, fuzzy matching, and multi-language analyzers. * **Operational Resilience:** The architecture must be **idempotent**—meaning if a message is sent twice by mistake, the database is smart enough not to double-count it. Everything in the "read" side (MongoDB/Search) should be **rebuildable** from the original MySQL data if a bug occurs.

https://mobinshaterian.medium.com/architecting-search-engines-a-deep-dive-into-meilisearch-internals-vector-retrieval-and-algolia-92779f29488e 🔍 Mastering Modern Search: Meilisearch Internals vs. Algolia Why is "search-as-you-type" so hard to build? In this video, we go under the hood of modern application search engines to understand how they achieve sub-50ms latency while handling millions of documents. We’ll specifically tear down the Rust-based architecture of Meilisearch and compare its trade-offs with the industry giant, Algolia. What You’ll Learn: The Death of BM25 for UI: Why traditional statistical scoring (like in Elasticsearch) fails in front-end search bars due to unpredictability and "typo instability". Meilisearch’s Secret Sauce: We break down the internal components that make Meilisearch fast and efficient: LMDB (Storage): Leveraging OS virtual memory mapping (mmap) to serve data at raw memory speeds without the massive RAM footprint. Finite-State Transducers (FST): How Meilisearch reduces dictionary RAM usage by 80–90% while enabling fuzzy typo tolerance. Roaring Bitmaps: The math behind SIMD-accelerated filtering for categories and tags. The Bucket Sort Pipeline: A deep dive into deterministic ranking rules (words, typos, proximity) that ensure predictable results. Hybrid & Vector Search: How the Arroy engine integrates DiskANN-based vector retrieval for AI-powered semantic search. Meilisearch vs. Algolia: A head-to-head comparison of architecture, memory models, data sovereignty, and cost dynamics. Key Architectural Takeaways: Memory Management: Algolia keeps data heavily loaded in RAM for edge speed, while Meilisearch uses LMDB to allow datasets larger than available RAM to sit on disk while maintaining performance. Sovereignty: Meilisearch offers an open-source, self-hosted path (MIT License) for privacy-conscious workloads, whereas Algolia provides a fully managed SaaS experience with advanced merchandising tools. Timestamps: 0:00 - The Transformation of Application Search 2:15 - Why Traditional SQL & BM25 Fail the UI 4:45 - Meilisearch Internal Architecture Overview 7:30 - Deep Dive: LMDB & Virtual Memory Mapping 10:15 - FSTs and Roaring Bitmaps Explained 13:00 - The Bucket Sort Ranking Engine 15:45 - Native Hybrid Search (Lexical + Vector) 18:30 - Meilisearch vs. Algolia: Which should you choose? Resources: Source Material: "Architecting Search Engines: A Deep Dive into Meilisearch Internals, Vector Retrieval, and Algolia". Meilisearch Repository: Built with Rust for memory safety and performance. #SearchEngine #Meilisearch #Algolia #RustLang #SystemDesign #SoftwareArchitecture #VectorSearch #OpenSource

https://medium.datadriveninvestor.com/architecting-an-open-source-search-engine-from-algolia-internals-to-vector-similarity-and-qdrant-0423dad529fc In this video, we explore how to **architect a high-performance open-source search engine** that rivals proprietary leaders like Algolia. Learn how to achieve **sub-50ms query latency** and "search-as-you-type" functionality by building a hybrid discovery pipeline that decouples ingestion from retrieval. We break down the technical stack, including **Change Data Capture (CDC)** with Debezium for real-time synchronization and **Redpanda** for sub-10ms event transport without the overhead of traditional Java-based systems. We also dive into the mechanics of **NeuralSearch**, demonstrating how to blend **lexical prefix matching** (via Typesense) with **semantic vector retrieval** (via Qdrant). You will discover how **Binary Quantization (Neural Hashing)** can compress complex vectors into **1-bit binary arrays**, reducing RAM requirements by **96.8%** and enabling the CPU to perform similarity scans using single-cycle hardware instructions. Finally, we analyze the **financial trade-offs** of search infrastructure. While proprietary SaaS is excellent for small-scale projects, we show why an open-source pipeline is the clear winner for high-volume platforms, offering **over 80% annual savings** and an engineering ROI of less than two months. Whether you are interested in the **mathematics of vector similarity** or the **architecture of scalable discovery**, this video provides the blueprint for modern search engineering.

This source provides a technical blueprint for a dual-purpose data versioning architecture that replaces traditional destructive write models with a system designed for both operational agility and AI reproducibility,. It implements Command Query Responsibility Segregation (CQRS) at the data layer by using bi-temporal validity periods (valid_from and valid_to) within a 3NF relational database, enabling backend applications to perform low-latency "time-travel" queries. To support high-throughput AI training without impacting production performance, the architecture utilizes Change Data Capture (CDC) to asynchronously stream data into a columnar lakehouse, which facilitates deterministic feature extraction and reproducible model evaluation,,. Although this approach leads to a linearly scaling storage footprint and increased schema complexity, it ensures a highly responsive backend while providing the immutable historical datasets required for modern intelligent software.

We break down the architectural overhaul of a telecom KPI platform that was struggling under the weight of massive data volumes. By moving away from flexible but expensive JSON-string storage to a flat columnar architecture in ClickHouse, we transformed a system that took minutes to respond into one that delivers results almost instantly. Key highlights of the redesign include: Flat Columnar Storage: We moved from "one-size-fits-all" JSON blobs to dedicated columns for every counter, allowing ClickHouse to leverage its native columnar strengths and reduce I/O costs by two orders of magnitude. Automated Schema Evolution: To handle frequent vendor updates, we built a self-healing pipeline using Airflow that automatically discovers new counters and adds them to the database schema without manual intervention. Decoupled Ingestion with Kafka: By introducing a Kafka buffer, we successfully managed a massive insert rate of 14 million records per hour, removing the performance bottlenecks caused by synchronous writes. Pre-calculated KPIs: We shifted heavy arithmetic from request-time to scheduled background tasks, allowing a lightweight Go-based backend to serve pre-computed results with minimal resource overhead. The ultimate takeaway for any large-scale analytics project? Flat beats nested at scale. Check out the full article to see how we optimized for ClickHouse’s strengths and built a self-maintaining data pipeline.

This technical guide describes the creation of an idempotent database seeder for a Go-based web service built on Clean Architecture. The system is designed to separate structural schema changes from initial data population, ensuring that migrations remain clean and versioned. By using a tracking table called seed_history, the application can automatically inject data on startup without creating duplicate records. The implementation utilizes Uber FX for dependency injection, ensuring that seeds are executed in a specific order immediately after migrations. Safety is further maintained through transactional integrity and conditional SQL logic, which prevents errors during re-runs or environment-specific deployments. Ultimately, this approach allows developers to add new data by simply creating numbered SQL files without modifying the core application logic.

These sources detail the development and architecture of go-wordpress, an open-source headless CMS backend built with the Go programming language. The project emphasizes Clean Architecture and modularity, utilizing PostgreSQL for data storage, sqlc for type-safe queries, and Redis for efficient caching. The system supports both RESTful APIs via the Gin framework and gRPC for high-performance service communication, all secured by JWT authentication. Additionally, the documentation covers advanced features such as WooCommerce web crawling, automated testing strategies, and dependency injection using Uber FX. Together, these materials provide a comprehensive blueprint for building scalable, production-ready web services with modern backend tools.

This article provides a technical deep dive into **go-wordpress**, a production-grade web scraping architecture developed in Go for extracting and managing product data from WordPress-based e-commerce sites. It outlines a sophisticated system designed for high performance and reliability, featuring **concurrent crawling**, data normalization specifically for **Persian language content**, and a modular design using Uber’s **fx framework** for dependency injection. The article details a multi-stage scraping pipeline that includes: * **Category Discovery:** An intelligent crawler that finds and validates product categories while filtering out irrelevant links. * **Concurrent Product Listing:** Utilization of the **Colly framework** to perform parallel scraping with configurable delays and CSS selectors, ensuring efficiency without overwhelming target servers. * **Batch Processing:** A semaphore-based approach for fetching product descriptions that maintains control over concurrent goroutines. * **Data Cleaning:** A specialized pipeline that normalizes prices by stripping currency labels and converting Persian digits to ASCII numerals. Beyond the scraping logic, the source describes a robust infrastructure supporting both **gRPC and HTTP REST APIs**, alongside a dual-layer storage strategy utilizing **SQL databases and Redis caching**. The article concludes by highlighting production-ready considerations such as **graceful degradation**, rate limiting, and comprehensive testing strategies, positioning the project as a scalable template for enterprise-level web data extraction. https://github.com/mobintmu/go-simple

The go-wordpress project is a Go-based scraper for e-commerce sites. It uses a configuration-driven architecture with JSON to handle diverse HTML structures without code changes. Key features include concurrent scraping, rate limiting, and data normalization for type safety. https://github.com/mobintmu/go-wordpress

Here is the translated and optimized English version of your YouTube description, tailored for a global developer audience. Proposed Title: Building a Scalable Poller–Dispatcher–Worker Architecture in Go 🚀 In this video, we dive deep into one of the most critical components of modern backend systems: Background Job Processing. If you are looking for a robust way to handle emails, data synchronization, or event-driven workflows in Go—without your system collapsing under heavy load—this architecture is your answer. What You Will Learn: The 4 Pillars of the Architecture: Job (The Unit of Work): How to design atomic, stateless, and repeatable tasks. Worker (The Executor): Implementing long-running Goroutines that focus solely on execution without worrying about scheduling. Dispatcher (The Orchestrator): Managing service-specific queues and applying Backpressure to prevent Goroutine explosions and memory leaks. Poller (The Decision Maker): The engine that monitors databases or APIs to determine "when" and "what" new jobs need to be triggered. Operational Benefits: Separation of Concerns: Decoupling business logic from execution mechanisms. Lifecycle Management: Implementing Graceful Shutdown to ensure no job is left half-finished. High Testability: Designing systems that allow for deterministic testing of concurrent behaviors without relying on "sleep" timers. This architecture, implemented in the open-source go-worker project, is ideal for ETL systems, microservices, and production-grade scheduled processing. https://github.com/mobintmu/go-worker

معماری Poller–Dispatcher–Worker در زبان Go یک راهکار مهندسی‌شده و مقیاس‌پذیر برای مدیریت پردازش‌های پس‌زمینه (Background Jobs) مانند ارسال ایمیل، همگام‌سازی داده‌ها و گردش‌کارهای رویدادمحور است. این ساختار بر پایه جداسازی دقیق مسئولیت‌ها بنا شده و شامل چهار بخش کلیدی است: Job (واحد اتمی کار)، Worker (مجری همزمان وظایف)، Dispatcher (مسئول مسیریابی و کنترل فشار) و Poller (موتور زمان‌بندی و تصمیم‌گیرنده) . در این مدل، Poller تعیین می‌کند «چه زمانی» کار انجام شود، Dispatcher مدیریت می‌کند «چگونه» توزیع شود و Workerها فقط روی «اجرای» صحیح تمرکز می‌کنند؛ این نظم ساختاری باعث می‌شود سیستم رفتاری کاملاً پیش‌بینی‌پذیر و قابل‌اعتماد داشته باشد. استفاده از این الگو، به‌ویژه در پروژه‌هایی مانند go-worker، مزایای عملیاتی حیاتی نظیر ایمنی در همزمانی و جلوگیری از نشت حافظه یا انفجار گوروتین‌ها را به ارمغان می‌آورد. به لطف استفاده از صف‌های محدود (Bounded queues) و جداسازی دامنه‌های خطا، هر سرویس می‌تواند به‌طور مستقل مقیاس‌پذیر شود و تحت بار شدید دچار خرابی آبشاری نشود. همچنین، این معماری با پشتیبانی از خاموشی ایمن (Graceful Shutdown) و قابلیت تست‌پذیری بالا، تضمین می‌کند که چرخه حیات سیستم به‌طور کامل تحت کنترل باشد و هیچ پردازشی بدون وضعیت مشخص رها نشود، که این امر برای پایداری سیستم‌های تولیدی (Production) ضروری است .

این منابع به طور جمعی، سیر تحول معماری پروژه گولنگ "go-simple" را مستند می‌کنند و آن را از یک سرور ابتدایی HTTP به یک سرویس تولیدی پیشرفته تبدیل می‌نمایند. این فرآیند سازماندهی‌شده با به‌کارگیری فریم‌ورک Gin و افزودن میان‌افزارهای امنیتی حیاتی مانند کنترل‌کننده سلامت و محدودیت زمانی درخواست‌ها آغاز شد. گام اصلی شامل مهاجرت به Uber FX برای مدیریت قدرتمند تزریق وابستگی (DI) و کنترل چرخه عمر برنامه بود تا ساختار پروژه مدولار و دامنه محور شود. علاوه بر این، ویژگی‌های مهمی مانند احراز هویت JWT برای محافظت از مسیرهای مدیریتی، استفاده از SQLC برای دسترسی ایمن به پایگاه داده، و یکپارچه‌سازی Zap Logger برای ثبت وقایع ساختاریافته افزوده شدند. در نهایت، با افزودن پروتکل gRPC و تنظیم SonarQube برای بازرسی کیفیت کد، این پروژه به یک نمونه جامع از بهترین شیوه‌های توسعه گولنگ تبدیل شد که مدیریت پیکربندی ایمن و محیط‌های جداگانه را تضمین می‌کند.

The provided sources describe Foreign Data Wrappers (FDW) within the context of PostgreSQL, which implement the SQL/MED standard for accessing external data stores as if they were local tables. The first source functions as a PostgreSQL wiki page, offering a broad, categorized list of various FDWs available for connecting to diverse data types, including other SQL databases, NoSQL databases, files, and web services, while cautioning that most are not officially supported. The second source specifically details the postgres_fdw module, which is an officially supplied extension for accessing data in external PostgreSQL servers, outlining its setup, configuration options for performance and connectivity, transaction management, and query optimization methods like pushing down WHERE clauses for remote execution. Together, the texts establish the concept of FDWs in PostgreSQL and provide a comprehensive overview of the ecosystem and the functionality of one essential wrapper for connecting to other PostgreSQL instances.

The source primarily focuses on the optimal design pattern for Query-Based Change Data Capture (CDC), a method used when access to database transaction logs (the preferred CDC method) is restricted. It advocates for a Hybrid Stateful Polling with Offset Tracking + Adaptive Backoff pattern as the superior solution for achieving near-real-time data synchronization reliably and efficiently. The article contrasts this hybrid approach with Simple Polling (fixed intervals) and Backoff Polling (adaptive retries), explaining that the hybrid pattern combines predictable Cron-driven scheduling, resourceful Exponential Backoff within cycles, and robust Stateful Offset Tracking to ensure data is processed exactly once, even during failures. The text includes detailed explanations and code examples for implementing both simple polling and adaptive backoff polling services, highlighting the utility of the hybrid pattern for cloud databases, read-only connections, and ETL pipelines that tolerate latencies of a few minutes.

The source is a technical article explaining the process of refactoring a monolithic Go web service built using the Gin framework into a modular and maintainable application by integrating Uber FX. The author outlines how Uber FX facilitates dependency injection and lifecycle management, solving the problems of hardcoded logic and poor testability present in the original structure. Key steps detailed include replacing the original entry point with an FX composition using fx.Provide to declare dependencies and fx.Invoke to wire application behavior, implementing lifecycle hooks for graceful startup and shutdown, and establishing a config-driven design for flexible settings. Ultimately, the refactoring results in a more robust and testable architecture, supported by behavioral testing that validates real endpoint interactions. https://medium.com/@mobinshaterian/refactoring-a-go-web-service-with-uber-fx-from-monolith-to-modular-elegance-2789a9ac8ec5

ارائه شده در جشنواره روز آزادی نرم‌افزار ۱۳۹۵ در تهران سایت جشنواره: http://sfd.fsug.ir/1395/ مقاله: https://sfd.fsug.ir/1395/component/rsform/?task=submissions.view.file&hash=b7ea4e22b9f6d8edc05209f83b89f7dd اسلایدها: https://sfd.fsug.ir/1395/images/presentations/Mobin_Shaterian_How_The_Philosophy_Of_Free_Software_Improve+Employees_Performance.zip مشاهده آنلاین اسلاید: http://dotarts.ir/present ارائه‌دهنده: مبین شاطریان برای توصیف آزادی لازم است که معنی اسارت را خوب درک کرده باشیم، لذا ابتدا اسارت را شرح می‌دهیم تا به معنی آزادی پی ببریم. کارمند دون پایه، شخصی است که در ابتدای امر بیشترین سهم ممکن یک کار را انجام می‌دهد ولی در نهایت کمترین بهره از فواید آن کار نصیب وی می‌شود. پس از اینکه فرد کمترین سهم از کار خود را دریافت کرد تبدیل به کارمند دون پایه می‌شود و تمام سعی خود را می‌کند که سهم کاری خود را کم کند و با تزویر نشان دهد که مشغول انجام کار است. این تعریف تنها برای شرکت‌های انحصاری نیست و برای دانشگاه و سایر مراکز قابل تعمیم است. نرم‌افزار آزاد برخلاف برخی از سیستم‌های انحصاری، مولد کارمند دون پایه (نیروی غیر کارآمد) نیست و بالعکس با تناسب بین سهم کاری و سهم درآمدی کارمندان، باعث بهبود عمل‌کرد و ارتقای سطح کارمندان می‌شود که این امر خود باعث پیشرفت جنبش نرم‌افزار آزاد می‌شود. سرفصل‌ها: نقد عیوب شرکت‌های سیستم انحصاری بیان راه حل برای عیوب مطرح شده با فلسفه نرم‌افزار آزاد پاسخ به سؤال «چرا فلسفه نرم‌افزار آزاد باعث بهبود عملکرد کارکنان می‌شود؟» کلمات کلیدی: مدیریت، عیوب مدیریت انحصاری، زندگی کارمندی، مدیریت ناصحیح کارمندان، مدیریت نرم‌افزار آزاد، افزایش بهره‌وری کارکنان برگزار شده توسط بنیاد دانش آزاد ایران مکان برگزاری جشنواره: دانشگاه صنعتی شریف - سالن آمفی‌تئاتر مرکزی