Case study
Next.js Blog
A separate writing app that documents engineering decisions for the portfolio workspace, linked from the Angular host as an external project surface.
Overview
- Role
- Sole engineer — content model, App Router pages, host linking
- Timeline
- 2026
- Status
- In progress
- Case study path
- /projects/nextjs-blog
Problem
Long-form technical writing does not belong inside the Angular resume shell. Mixing MDX-style posts into the host would couple content authoring to the portfolio release cycle and blur the boundary between “product demo” and “engineering notes.”
Goals
- Ship a lightweight Next.js App Router site for posts
- Keep post content file-based and easy to extend
- Link the blog from the portfolio without federating it into Angular
- Use posts to explain the multi-app architecture in plain language
Key features
- Post index and slug-based detail routes
- Frontmatter-driven titles, dates, and summaries
- Portfolio nav deep-link to the blog origin
- Posts that document the micro-frontend workspace itself
Architecture
Runtime composition flow — top is the entry surface, bottom is the leaf dependency.
- Personal Website (Angular host nav)
- External Blog URL
- Next.js App Router
- File-based posts (content/posts)
The blog is a sibling app, not a federated remote—navigation is a hard link, not a runtime module load.
Technology
Each choice below includes the engineering reason it was selected for this project.
Next.js (App Router)
Why selected: File-system routing and server components fit a content-first writing site better than mounting another Angular remote.
TypeScript
Why selected: Shared typing for post frontmatter and listing helpers without runtime schema overhead.
Markdown posts on disk
Why selected: Posts stay reviewable in git; no CMS is required for a small personal writing surface.
Separate deployable app
Why selected: Writing cadence can change without rebuilding or redeploying the Angular host and federated remotes.
Engineering challenges
Concrete problems and the solutions that shipped.
Challenge 1
Should the blog be a federated remote or a separate product?
Solution
Keep it external. Federation adds value for Angular demos sharing the host shell; a writing site benefits more from Next.js content tooling and an independent origin.
Challenge 2
How should the host discover the blog URL across environments?
Solution
Centralize `BLOG_URL` / `BLOG_PATH` so local Next (`:3000/projects/blogs`) and production (`/projects/blogs`) stay aligned.
Architecture decisions
Decision · reason · alternative · trade-off for each major fork in the road.
Decision
Sibling Next.js app instead of an Angular blog feature
- Reason
- Content authoring and rendering fit the Next.js ecosystem; the host stays focused on resume + demos.
- Alternative
- Markdown rendering inside the Angular portfolio
- Trade-off
- Two front-end runtimes to maintain; cross-app navigation is a full page load.
Decision
File-based posts over a headless CMS
- Reason
- Zero infra for a small corpus; diffs are the editorial workflow.
- Alternative
- CMS-backed content API
- Trade-off
- Non-technical editing is harder; scaling editorial roles later would need a different model.
Performance
Demo / estimated metricsNo checked-in production measurements for the blog app. Values reflect the intended static/content profile.
Content source
Local markdown
No CMS round-trip
Routing
App Router
Slug pages under /posts/[slug]
Host coupling
URL only
No shared runtime with Angular
Lessons learned
What held up in practice, what did not, and what the next iteration should change.
What worked
- Using the blog to explain federation keeps the portfolio’s “why” discoverable outside the code
- Hard-linking from the host avoids over-engineering cross-framework composition
What didn't
- Treating every showcase surface as a federated remote by default
What would be improved
- Environment-specific blog base URL for deployed previews
- Shared brand tokens so host and blog typography feel closer
- RSS or sitemap once the post corpus grows
What I learned
- Architecture for a personal brand is often about boundaries between apps, not maximizing micro-frontends
Future improvements
Next engineering increments if this surface continues to evolve.
- Production blog path `/projects/blogs` embedded into the host deploy
- Tagging / topic indexes
- Search across posts
- Tighter visual alignment with the Angular host
Technical stack
Compact summary for scanning.