<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Architecture on Commentary of Takao</title><link>https://takao.blog/en/tags/architecture/</link><description>Recent content in Architecture on Commentary of Takao</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>Commentary of Takao</copyright><lastBuildDate>Sat, 13 Jun 2026 23:11:50 +0900</lastBuildDate><atom:link href="https://takao.blog/en/tags/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>Serverless Architecture Patterns: Beyond Lambda Functions</title><link>https://takao.blog/en/web/serverless-patterns/</link><pubDate>Tue, 17 Sep 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/serverless-patterns/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Serverless Architecture Patterns: Beyond Lambda Functions" /&gt;&lt;p&gt;Serverless computing has evolved far beyond replacing simple REST APIs with Lambda functions behind API Gateway. Modern serverless architectures are fully event-driven, asynchronous, and decompose monoliths into coordinated function workflows. Major enterprises now run production workloads on AWS Lambda, Azure Functions, and Cloudflare Workers. This article explores patterns that go beyond the basics.&lt;/p&gt;
&lt;h2 id="event-driven-architecture-foundation"&gt;Event-Driven Architecture Foundation
&lt;/h2&gt;&lt;p&gt;At the core of serverless is the event-driven model: event producers emit events, event routers deliver them, and event consumers react. AWS offers multiple routing services — EventBridge for schema-aware event buses, SQS for queue-based decoupling, SNS for pub/sub messaging, and Kafka for high-throughput streaming.&lt;/p&gt;</description></item><item><title>TypeScript Project References: Scaling Large Codebases</title><link>https://takao.blog/en/web/typescript-project-references/</link><pubDate>Tue, 13 Aug 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/typescript-project-references/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post TypeScript Project References: Scaling Large Codebases" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;As TypeScript codebases grow, the monolithic &lt;code&gt;tsconfig.json&lt;/code&gt; approach breaks down. Every invocation of &lt;code&gt;tsc&lt;/code&gt; type-checks and emits the entire project — a process that can take minutes even with &lt;code&gt;--noEmit&lt;/code&gt; in large monorepos. Worse, without module boundaries, any file can import any other file, creating tangled dependency graphs that are difficult to refactor. &lt;strong&gt;TypeScript Project References&lt;/strong&gt; solve this by allowing you to split your codebase into independent sub-projects, each with its own &lt;code&gt;tsconfig.json&lt;/code&gt;, enabling incremental builds, enforced API boundaries, and dramatically faster type-checking.&lt;/p&gt;</description></item><item><title>CSS @layer: Managing Cascade with Layer Architecture</title><link>https://takao.blog/en/web/css-layer-architecture/</link><pubDate>Tue, 11 Jun 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/css-layer-architecture/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post CSS @layer: Managing Cascade with Layer Architecture" /&gt;&lt;p&gt;If you have ever battled specificity wars in a large CSS project — overriding third-party styles, sprinkling &lt;code&gt;!important&lt;/code&gt; declarations, or restructuring HTML just to win the cascade — &lt;code&gt;@layer&lt;/code&gt; is the solution you have been waiting for. The CSS &lt;code&gt;@layer&lt;/code&gt; at-rule gives developers explicit control over the cascade order, independent of specificity or source order.&lt;/p&gt;
&lt;h2 id="the-cascade-problem-before-layer"&gt;The Cascade Problem Before @layer
&lt;/h2&gt;&lt;p&gt;Before &lt;code&gt;@layer&lt;/code&gt;, cascade management relied entirely on conventions: BEM naming, SMACSS categories, ITCSS architecture. These conventions worked, but they were not enforced by the browser. Third-party CSS could override carefully crafted component styles, and source-order fragility meant that a single &lt;code&gt;&amp;lt;link&amp;gt;&lt;/code&gt; tag reorder could break an entire design system.&lt;/p&gt;</description></item></channel></rss>