<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Engineering on Birdor Blog</title>
		<link>https://blog.birdor.com/categories/engineering/</link>
		<description>Recent content in Engineering on Birdor Blog</description>
		<generator>Hugo</generator>
		<language>en</language>
		
		
		
		
			<lastBuildDate>Tue, 30 Dec 2025 20:30:00 +0800</lastBuildDate>
		
			<atom:link href="https://blog.birdor.com/categories/engineering/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>A Minimal Service Framework That Returns to the Essence of Go</title>
				<link>https://blog.birdor.com/docs/plumego/reference/plumego-introduction/</link>
				<pubDate>Sun, 28 Dec 2025 00:28:00 +0800</pubDate>
				<guid>https://blog.birdor.com/docs/plumego/reference/plumego-introduction/</guid>
				<description>&lt;h2 id=&#34;preface-why-build-yet-another-go-framework&#34;&gt;Preface: Why Build Yet Another Go Framework&lt;/h2&gt;&#xA;&lt;p&gt;In today’s highly mature Go ecosystem, &lt;strong&gt;“building yet another Go web framework”&lt;/strong&gt; may seem redundant—or even boring.&lt;/p&gt;&#xA;&lt;p&gt;We already have:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;Feature-rich, full-stack frameworks with massive communities&lt;/li&gt;&#xA;&lt;li&gt;Performance-oriented, low-level HTTP / RPC frameworks&lt;/li&gt;&#xA;&lt;li&gt;Cloud-native application runtimes deeply integrated with Kubernetes&lt;/li&gt;&#xA;&lt;li&gt;Complete engineering systems tailored for microservices&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;&lt;strong&gt;Plumego is not meant to compete with them.&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;The motivation behind Plumego comes from a different, often overlooked, set of real-world engineering needs:&lt;/p&gt;</description>
			</item>
			<item>
				<title>Plumego vs Common Go Frameworks: Design Trade-offs Explained</title>
				<link>https://blog.birdor.com/docs/plumego/reference/plumego-vs-go-frameworks/</link>
				<pubDate>Sun, 28 Dec 2025 00:36:00 +0800</pubDate>
				<guid>https://blog.birdor.com/docs/plumego/reference/plumego-vs-go-frameworks/</guid>
				<description>&lt;h2 id=&#34;introduction-comparing-frameworks-is-ultimately-about-values&#34;&gt;Introduction: Comparing Frameworks Is Ultimately About Values&lt;/h2&gt;&#xA;&lt;p&gt;In technical communities, discussions of “Framework A vs Framework B” never seem to end.&lt;/p&gt;&#xA;&lt;p&gt;But experienced engineers usually understand one thing clearly:&lt;/p&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;Framework debates are rarely about right or wrong technology—they are about value trade-offs.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;Plumego was not created in a “blank market.”&lt;br&gt;&#xA;On the contrary, it deliberately chose a seemingly “unattractive” path &lt;strong&gt;in an already thriving Go ecosystem&lt;/strong&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Therefore, this article does not attempt to prove that:&lt;/p&gt;</description>
			</item>
			<item>
				<title>When You Should Not Use Plumego</title>
				<link>https://blog.birdor.com/docs/plumego/reference/when-not-to-use-plumego/</link>
				<pubDate>Sun, 28 Dec 2025 07:30:00 +0800</pubDate>
				<guid>https://blog.birdor.com/docs/plumego/reference/when-not-to-use-plumego/</guid>
				<description>&lt;h2 id=&#34;introduction-a-responsible-framework-must-define-its-non-use-cases&#34;&gt;Introduction: A Responsible Framework Must Define Its “Non-Use Cases”&lt;/h2&gt;&#xA;&lt;p&gt;Any framework that takes engineering quality seriously must be willing to answer one question:&lt;/p&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;“In what situations should you not use me?”&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;If a framework claims that it:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;fits every team,&lt;/li&gt;&#xA;&lt;li&gt;fits every stage,&lt;/li&gt;&#xA;&lt;li&gt;fits every business,&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;then it is almost certainly not credible.&lt;/p&gt;&#xA;&lt;p&gt;Plumego was never designed to be a universal answer.&lt;br&gt;&#xA;It is a choice &lt;strong&gt;explicitly created for a specific class of engineering problems&lt;/strong&gt;.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Plumego Advanced Guide: Designing Explicit, Scalable Go Services</title>
				<link>https://blog.birdor.com/plumego-advanced-guide/</link>
				<pubDate>Tue, 30 Dec 2025 20:30:00 +0800</pubDate>
				<guid>https://blog.birdor.com/plumego-advanced-guide/</guid>
				<description>&lt;h1 id=&#34;plumego-advanced-guide-designing-explicit-scalable-go-services&#34;&gt;Plumego Advanced Guide: Designing Explicit, Scalable Go Services&lt;/h1&gt;&#xA;&lt;h2 id=&#34;introduction-beyond-the-basics&#34;&gt;Introduction: Beyond the Basics&lt;/h2&gt;&#xA;&lt;p&gt;The introductory Plumego documentation explains &lt;em&gt;what&lt;/em&gt; Plumego is and &lt;em&gt;why&lt;/em&gt; it exists. This guide focuses on a different question:&lt;/p&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;How do you design serious, long-lived systems with Plumego?&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;This article assumes that you already understand:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;Go fundamentals&lt;/li&gt;&#xA;&lt;li&gt;HTTP server basics&lt;/li&gt;&#xA;&lt;li&gt;The core Plumego APIs&lt;/li&gt;&#xA;&lt;li&gt;The philosophy of explicitness&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;What follows is an advanced, production-oriented tutorial. We will explore architectural patterns, not just APIs. The emphasis is on &lt;strong&gt;design decisions&lt;/strong&gt;, &lt;strong&gt;trade-offs&lt;/strong&gt;, and &lt;strong&gt;operational correctness&lt;/strong&gt;—the areas where Plumego provides leverage without hiding complexity.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Plumego: A Deliberate Go Framework for Engineers Who Value Explicitness</title>
				<link>https://blog.birdor.com/introducing-plumego-go-framework/</link>
				<pubDate>Tue, 30 Dec 2025 19:00:00 +0800</pubDate>
				<guid>https://blog.birdor.com/introducing-plumego-go-framework/</guid>
				<description>&lt;h2 id=&#34;introduction-why-another-go-framework&#34;&gt;Introduction: Why Another Go Framework?&lt;/h2&gt;&#xA;&lt;p&gt;The Go ecosystem does not suffer from a lack of web frameworks. From minimalist routers to batteries-included solutions, developers can choose from a wide spectrum of abstractions. Yet, despite this abundance, many experienced teams eventually encounter a recurring problem:&lt;/p&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;Their framework either does too little to guide large systems, or too much to stay out of the way.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://github.com/spcent/plumego&#34;&gt;&lt;strong&gt;Plumego&lt;/strong&gt;&lt;/a&gt; exists in the narrow but important space between these extremes.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
