<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Articles on Modern Angular Architecture</title><link>https://modernfrontendarchitecture.com/articles/</link><description>Recent content in Articles on Modern Angular Architecture</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 30 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://modernfrontendarchitecture.com/articles/index.xml" rel="self" type="application/rss+xml"/><item><title>Best Apps to Learn Angular in 2026 (iOS and Android Review)</title><link>https://modernfrontendarchitecture.com/articles/best-apps-to-learn-angular-2026/</link><pubDate>Thu, 30 Apr 2026 00:00:00 +0000</pubDate><guid>https://modernfrontendarchitecture.com/articles/best-apps-to-learn-angular-2026/</guid><description>&lt;blockquote>
&lt;p>&lt;strong>Disclosure:&lt;/strong> I build &lt;a href="https://modernfrontendarchitecture.com/apps/daily-angular/">Daily Angular&lt;/a>
, one of the apps reviewed below. I have tried to be fair about what it does and does not do, and to be honest about its competitors — including the one I think is genuinely interesting. If you only trust app reviews written by people with no skin in the game, that is a reasonable position; this is not that review.&lt;/p>&lt;/blockquote>
&lt;p>If you searched for the best phone app to learn Angular in 2026, you probably expected a top-ten list. The honest answer is that the dedicated Angular app market is unexpectedly thin. There are roughly three serious iOS apps, one or two serious Android apps, and a long tail of offline tutorial wrappers — many of which actually teach AngularJS 1.x, the obsolete 2010-era framework, not modern Angular.&lt;/p></description></item><item><title>How I Rebuilt Daily Angular with Claude Code in 2 Weeks</title><link>https://modernfrontendarchitecture.com/articles/daily-angular-claude-code-story/</link><pubDate>Wed, 22 Apr 2026 00:00:00 +0000</pubDate><guid>https://modernfrontendarchitecture.com/articles/daily-angular-claude-code-story/</guid><description>&lt;p>Eight years ago I wanted an app I could use for five minutes a day to practice front-end interview questions on the bus, in a queue, waiting for coffee. The kind of app that respects that your time is stolen in tiny pieces. I looked for it. It did not exist.&lt;/p>
&lt;p>I tried to build it myself. That first version took me roughly eight months of evenings and weekends, and I eventually shelved it — not because the idea was wrong, but because I had two small kids and no runway to keep maintaining a side project that was not paying rent. It sat on a hard drive and I moved on.&lt;/p></description></item><item><title>Angular rxResource Guide: Async Data with Signals (2026)</title><link>https://modernfrontendarchitecture.com/articles/angular-rxresource-guide/</link><pubDate>Fri, 17 Apr 2026 00:00:00 +0000</pubDate><guid>https://modernfrontendarchitecture.com/articles/angular-rxresource-guide/</guid><description>&lt;p>Angular&amp;rsquo;s &lt;a href="https://angular.dev/api/core/rxjs-interop/rxResource" target="_blank" rel="noopener noreferrer">&lt;code>rxResource&lt;/code>&lt;/a>
 is an &lt;a href="https://rxjs.dev/" target="_blank" rel="noopener noreferrer">RxJS&lt;/a>
-aware variant of the &lt;a href="https://angular.dev/guide/signals/resource" target="_blank" rel="noopener noreferrer">&lt;code>resource()&lt;/code>&lt;/a>
 primitive for loading async data with &lt;a href="https://angular.dev/guide/signals" target="_blank" rel="noopener noreferrer">signals&lt;/a>
. It lets you model remote calls as reactive resources that automatically re-execute when their input signals change, while giving you the full power of RxJS operators for the actual request. If you have been mixing &lt;code>effect()&lt;/code>, &lt;code>HttpClient&lt;/code>, and manual signal updates to load data, &lt;code>rxResource&lt;/code> is designed to replace that pattern with something declarative and SSR-safe.&lt;/p></description></item><item><title>Angular SSR Sitemap Generation: Build-Time Guide (2026)</title><link>https://modernfrontendarchitecture.com/articles/angular-ssr-sitemap-generation/</link><pubDate>Tue, 17 Mar 2026 00:00:00 +0000</pubDate><guid>https://modernfrontendarchitecture.com/articles/angular-ssr-sitemap-generation/</guid><description>&lt;p>A well-structured &lt;a href="https://www.sitemaps.org/protocol.html" target="_blank" rel="noopener noreferrer">&lt;code>sitemap.xml&lt;/code>&lt;/a>
 tells search engines which URLs exist on your Angular application, when they were last updated, and how important they are relative to each other. For &lt;a href="https://angular.dev/guide/ssr" target="_blank" rel="noopener noreferrer">Angular SSR&lt;/a>
 apps, sitemap generation requires extra attention because routes are defined in TypeScript — not in a file system — and the sitemap must stay in sync with both your content and your &lt;a href="https://developers.google.com/search/docs/crawling-indexing/canonicalization" target="_blank" rel="noopener noreferrer">canonical URL strategy&lt;/a>
.&lt;/p>
&lt;h2 id="why-angular-ssr-needs-explicit-sitemap-generation">Why Angular SSR needs explicit sitemap generation&lt;/h2>
&lt;p>Frameworks with file-system routing (Next.js, Hugo, Astro) can infer sitemaps from directory structure. Angular cannot. Routes live in &lt;code>Routes[]&lt;/code> arrays, often behind lazy imports and guards. The router configuration alone does not tell you which routes are content pages, which are behind authentication, and which should be excluded from indexing.&lt;/p></description></item><item><title>Angular Prerendering vs SSR: When to Use Each (2026)</title><link>https://modernfrontendarchitecture.com/articles/angular-prerendering-vs-ssr/</link><pubDate>Fri, 13 Mar 2026 00:00:00 +0000</pubDate><guid>https://modernfrontendarchitecture.com/articles/angular-prerendering-vs-ssr/</guid><description>&lt;p>Angular supports both &lt;a href="https://angular.dev/guide/prerendering" target="_blank" rel="noopener noreferrer">prerendering&lt;/a>
 (build-time HTML generation) and &lt;a href="https://angular.dev/guide/ssr" target="_blank" rel="noopener noreferrer">server-side rendering&lt;/a>
 (request-time HTML generation). They solve the same problem — delivering fully rendered HTML to crawlers and users — but with different trade-offs in build time, scalability, content freshness, and infrastructure complexity. See &lt;a href="https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics" target="_blank" rel="noopener noreferrer">Google Search Central&amp;rsquo;s JavaScript SEO guide&lt;/a>
 for how modern crawlers handle each strategy. Most production Angular applications benefit from using both strategically.&lt;/p>
&lt;h2 id="what-prerendering-does">What prerendering does&lt;/h2>
&lt;p>Prerendering generates static HTML files at build time. When you run &lt;code>ng build&lt;/code> with prerendering enabled, Angular renders each configured route and saves the resulting HTML as a file. At request time, the server delivers this pre-built HTML directly — no Node.js runtime, no rendering on the fly.&lt;/p></description></item><item><title>Native Federation vs Iframes: Which Angular Micro Frontend Wins in 2026?</title><link>https://modernfrontendarchitecture.com/articles/angular-micro-frontends-native-federation-vs-iframes/</link><pubDate>Fri, 13 Mar 2026 00:00:00 +0000</pubDate><guid>https://modernfrontendarchitecture.com/articles/angular-micro-frontends-native-federation-vs-iframes/</guid><description>&lt;p>&lt;a href="https://martinfowler.com/articles/micro-frontends.html" target="_blank" rel="noopener noreferrer">Micro frontends&lt;/a>
 allow multiple teams to own, deploy, and evolve parts of a web application independently. In the Angular ecosystem, two dominant approaches have emerged: &lt;a href="https://github.com/angular-architects/module-federation-plugin/blob/main/libs/native-federation/README.md" target="_blank" rel="noopener noreferrer">Native Federation&lt;/a>
 (the evolution of &lt;a href="https://webpack.js.org/concepts/module-federation/" target="_blank" rel="noopener noreferrer">Module Federation&lt;/a>
 for Angular) and &lt;a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe" target="_blank" rel="noopener noreferrer">iframes&lt;/a>
. Both solve the same core problem — runtime composition of independent frontend applications — but with radically different trade-offs in integration depth, performance, and isolation.&lt;/p>
&lt;h2 id="what-micro-frontends-solve">What micro frontends solve&lt;/h2>
&lt;p>Large frontend monoliths create bottlenecks. A single Angular application owned by five teams means coordinated releases, shared &lt;code>node_modules&lt;/code>, conflicting merge schedules, and slow CI pipelines. Micro frontends break this coupling by letting each team build, test, and deploy their feature area independently.&lt;/p></description></item><item><title>Angular Signals vs RxJS: When to Use Each (2026 Guide)</title><link>https://modernfrontendarchitecture.com/articles/angular-signals-vs-rxjs/</link><pubDate>Tue, 10 Mar 2026 00:00:00 +0000</pubDate><guid>https://modernfrontendarchitecture.com/articles/angular-signals-vs-rxjs/</guid><description>&lt;p>&lt;a href="https://angular.dev/guide/signals" target="_blank" rel="noopener noreferrer">Angular Signals&lt;/a>
 and &lt;a href="https://rxjs.dev/guide/overview" target="_blank" rel="noopener noreferrer">RxJS&lt;/a>
 are both reactive primitives, but they solve fundamentally different problems. Signals manage synchronous state and derived values. RxJS manages asynchronous event streams with &lt;a href="https://rxjs.dev/guide/operators" target="_blank" rel="noopener noreferrer">operators&lt;/a>
 for timing, cancellation, and orchestration. Understanding where they overlap and where they complement each other is essential for building Angular applications that are simple where possible and powerful where necessary.&lt;/p>
&lt;h2 id="what-signals-are-designed-for">What signals are designed for&lt;/h2>
&lt;p>Signals are Angular&amp;rsquo;s answer to synchronous reactive state. They represent a value that changes over time and automatically notify consumers when it updates.&lt;/p></description></item><item><title>NgRx in 2026: When You Still Need It (and When Signals Are Enough)</title><link>https://modernfrontendarchitecture.com/articles/ngrx-to-be-or-not-to-be/</link><pubDate>Tue, 10 Mar 2026 00:00:00 +0000</pubDate><guid>https://modernfrontendarchitecture.com/articles/ngrx-to-be-or-not-to-be/</guid><description>&lt;p>&lt;a href="https://ngrx.io/" target="_blank" rel="noopener noreferrer">NgRx&lt;/a>
 has been the default state management library for enterprise Angular applications for years. But Angular now ships with &lt;a href="https://angular.dev/guide/signals" target="_blank" rel="noopener noreferrer">signals&lt;/a>
, &lt;a href="https://angular.dev/guide/signals#computed-signals" target="_blank" rel="noopener noreferrer">computed values&lt;/a>
, &lt;a href="https://angular.dev/guide/signals#effects" target="_blank" rel="noopener noreferrer">effects&lt;/a>
, &lt;a href="https://angular.dev/api/core/linkedSignal" target="_blank" rel="noopener noreferrer">&lt;code>linkedSignal&lt;/code>&lt;/a>
, and &lt;a href="https://angular.dev/guide/signals/resource" target="_blank" rel="noopener noreferrer">&lt;code>resource&lt;/code>&lt;/a>
 — covering much of what NgRx was originally needed for. The question is no longer &amp;ldquo;should I use NgRx?&amp;rdquo; but &amp;ldquo;does NgRx still solve a problem that Angular itself does not?&amp;rdquo; The &lt;a href="https://redux.js.org/faq/general#when-should-i-use-redux" target="_blank" rel="noopener noreferrer">Redux documentation&amp;rsquo;s own guidance on when you need it&lt;/a>
 is a useful complementary lens.&lt;/p></description></item><item><title>Angular vs Next.js in 2026: SEO, SSR &amp; Content Platforms</title><link>https://modernfrontendarchitecture.com/articles/angular-vs-next-for-content-platforms/</link><pubDate>Fri, 30 Jan 2026 00:00:00 +0000</pubDate><guid>https://modernfrontendarchitecture.com/articles/angular-vs-next-for-content-platforms/</guid><description>&lt;p>&lt;a href="https://angular.dev/" target="_blank" rel="noopener noreferrer">Angular&lt;/a>
 and &lt;a href="https://nextjs.org/" target="_blank" rel="noopener noreferrer">Next.js&lt;/a>
 can both rank well and power excellent content platforms. The better choice depends less on framework popularity and more on &lt;strong>team skill set, architectural consistency needs, operational model, and how much custom product logic lives alongside content&lt;/strong>. If your organization values strong conventions and a unified framework for app + content surfaces, Angular can be a strong choice. If your team is deeply invested in &lt;a href="https://react.dev/" target="_blank" rel="noopener noreferrer">React&lt;/a>
 and needs fast content-centric iteration, Next.js may reduce time to ship. Benchmark real pages against &lt;a href="https://web.dev/articles/vitals" target="_blank" rel="noopener noreferrer">Core Web Vitals&lt;/a>
 before committing either way.&lt;/p></description></item><item><title>Angular SSR SEO Playbook: Hydration &amp; Metadata (2026)</title><link>https://modernfrontendarchitecture.com/articles/angular-ssr-seo-hydration-playbook/</link><pubDate>Tue, 18 Nov 2025 00:00:00 +0000</pubDate><guid>https://modernfrontendarchitecture.com/articles/angular-ssr-seo-hydration-playbook/</guid><description>&lt;p>&lt;a href="https://angular.dev/guide/ssr" target="_blank" rel="noopener noreferrer">Angular SSR&lt;/a>
 improves SEO for content sites when it delivers &lt;strong>fully rendered article HTML, correct metadata, and stable &lt;a href="https://angular.dev/guide/hydration" target="_blank" rel="noopener noreferrer">hydration&lt;/a>
 behavior&lt;/strong> on the initial response. The production pattern is not just &amp;ldquo;turn on SSR&amp;rdquo;: you need route-level metadata, canonical URLs, &lt;a href="https://schema.org/" target="_blank" rel="noopener noreferrer">structured data&lt;/a>
, prerendering for predictable content routes, and build-time generation of &lt;code>sitemap.xml&lt;/code>, &lt;code>robots.txt&lt;/code>, and &lt;code>rss.xml&lt;/code>. Hydration should enhance interactivity without duplicating data fetches or causing &lt;a href="https://web.dev/articles/cls" target="_blank" rel="noopener noreferrer">Cumulative Layout Shift&lt;/a>
.&lt;/p>
&lt;h2 id="why-ssr-still-matters-for-angular-seo-in-2026">Why SSR still matters for Angular SEO in 2026&lt;/h2>
&lt;p>Google can render JavaScript, but rendering is not the same as reliable indexing quality. Content-heavy sites get better results when article content is present in the server response because it improves:&lt;/p></description></item><item><title>Angular Signals State Management 2026: Enterprise Guide</title><link>https://modernfrontendarchitecture.com/articles/angular-signals-enterprise-state/</link><pubDate>Mon, 06 Oct 2025 00:00:00 +0000</pubDate><guid>https://modernfrontendarchitecture.com/articles/angular-signals-enterprise-state/</guid><description>&lt;p>&lt;a href="https://angular.dev/guide/signals" target="_blank" rel="noopener noreferrer">Angular Signals&lt;/a>
 are a strong fit for enterprise Angular applications when you use them as a &lt;strong>feature-level state primitive&lt;/strong>, not as a universal replacement for every reactive pattern. The practical model is: keep UI and derived state in signals, keep async orchestration and transport concerns in &lt;a href="https://rxjs.dev/" target="_blank" rel="noopener noreferrer">RxJS&lt;/a>
, and reserve app-wide state for truly cross-cutting concerns. This approach reduces global-store sprawl, improves local reasoning, and still supports large-team governance — an application of the &lt;a href="https://htmx.org/essays/locality-of-behaviour/" target="_blank" rel="noopener noreferrer">locality of behavior principle&lt;/a>
 at the state layer.&lt;/p></description></item><item><title>Angular CI/CD with GitHub Actions for SSR Apps</title><link>https://modernfrontendarchitecture.com/articles/angular-cicd-github-actions-deployments/</link><pubDate>Tue, 09 Sep 2025 00:00:00 +0000</pubDate><guid>https://modernfrontendarchitecture.com/articles/angular-cicd-github-actions-deployments/</guid><description>&lt;p>A production Angular CI/CD pipeline should optimize for &lt;strong>confidence, speed, and safe rollback&lt;/strong>, not just a green checkmark. For &lt;a href="https://angular.dev/guide/ssr" target="_blank" rel="noopener noreferrer">Angular SSR&lt;/a>
 applications, that means validating content generation, linting, SSR builds, prerender output, and post-deploy smoke tests against real routes like article pages, &lt;code>sitemap.xml&lt;/code>, and &lt;code>rss.xml&lt;/code>. &lt;a href="https://docs.github.com/en/actions" target="_blank" rel="noopener noreferrer">GitHub Actions&lt;/a>
 is a strong fit when you pair caching with deterministic steps and explicit failure gates.&lt;/p>
&lt;h2 id="what-a-good-angular-cicd-pipeline-actually-does">What a good Angular CI/CD pipeline actually does&lt;/h2>
&lt;p>A mature pipeline does more than compile the app. It should answer these operational questions before production traffic sees a deploy:&lt;/p></description></item><item><title>Enterprise Angular Feature Architecture: Scalable Boundaries</title><link>https://modernfrontendarchitecture.com/articles/angular-enterprise-feature-architecture/</link><pubDate>Thu, 21 Aug 2025 00:00:00 +0000</pubDate><guid>https://modernfrontendarchitecture.com/articles/angular-enterprise-feature-architecture/</guid><description>&lt;p>Enterprise Angular architecture scales when you design around &lt;strong>feature boundaries and dependency direction&lt;/strong>, not just folders by technical type. A practical structure uses &lt;code>core&lt;/code> for infrastructure, &lt;code>shared&lt;/code> for reusable UI primitives, and &lt;code>features&lt;/code> for route-owned domain behavior. Combined with &lt;a href="https://angular.dev/guide/components/importing" target="_blank" rel="noopener noreferrer">standalone APIs&lt;/a>
 and &lt;a href="https://angular.dev/guide/routing/common-router-tasks#lazy-loading" target="_blank" rel="noopener noreferrer">lazy routes&lt;/a>
, this creates clearer ownership, better performance, and fewer cross-team regressions.&lt;/p>
&lt;h2 id="why-layer-only-folders-fail-as-teams-grow">Why layer-only folders fail as teams grow&lt;/h2>
&lt;p>The classic structure (&lt;code>components/&lt;/code>, &lt;code>services/&lt;/code>, &lt;code>models/&lt;/code>, &lt;code>utils/&lt;/code>) looks clean early on, but it degrades under team growth because it hides domain boundaries.&lt;/p></description></item></channel></rss>