<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Solid on Daffa Abhipraya</title><link>https://blog.abhipraya.dev/tags/solid/</link><description>Recent content in Solid on Daffa Abhipraya</description><generator>Hugo</generator><language>en-us</language><copyright>© Daffa Abhipraya</copyright><lastBuildDate>Wed, 15 Apr 2026 00:00:00 +0700</lastBuildDate><atom:link href="https://blog.abhipraya.dev/tags/solid/index.xml" rel="self" type="application/rss+xml"/><item><title>PPL: Separation of Concerns, Feature Code to Infra [Sprint 2, Week 3]</title><link>https://blog.abhipraya.dev/ppl/part-b/s2w3-programming/</link><pubDate>Wed, 15 Apr 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-b/s2w3-programming/</guid><description>&lt;h2 id="what-i-worked-on">
 &lt;a class="anchor" href="#what-i-worked-on" data-anchor="what-i-worked-on" aria-hidden="true">#&lt;/a>
 What I Worked On
&lt;/h2>
&lt;p>Two weeks of work that ended up demonstrating the same principle at two very different scales. In the application code: isolating invoice number generation as a pure function (SIRA-123, MR !130) and composing authentication onto GET endpoints via FastAPI dependency injection (SIRA-82, MR !154). In the infrastructure: designing &lt;code>scripts/ci-supabase-slot.sh&lt;/code> (SIRA-274, MR !197) — a 110-line bash script that claims one of three parallel Supabase stacks and hands back an isolated environment to the caller. Different problem domains, same discipline: give each unit of code one reason to change.&lt;/p></description></item><item><title>PPL: SOLID Principles in a FastAPI Invoice System</title><link>https://blog.abhipraya.dev/ppl/part-a/solid/</link><pubDate>Thu, 09 Apr 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-a/solid/</guid><description>&lt;p>SIRA (Smart Invoice Reminder AI) is a system that automates invoice collection reminders. It monitors payment status, scores client risk using a weighted formula, and sends personalized reminders by email or messaging. The backend is built with FastAPI, Supabase (Postgres via REST), Celery for background jobs, and Redis as the message broker.&lt;/p>
&lt;p>This blog walks through how SOLID principles shaped the architecture at three levels: the overall layer structure, service-level design patterns, and individual function design. The goal is not to explain what SOLID stands for (there are plenty of articles for that), but to show what it looks like in production code and why certain design choices were made over simpler alternatives.&lt;/p></description></item><item><title>PPL: Programming [Sprint 2, Week 2]</title><link>https://blog.abhipraya.dev/ppl/part-b/s2w2-programming/</link><pubDate>Mon, 30 Mar 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-b/s2w2-programming/</guid><description>&lt;h2 id="what-i-worked-on">
 &lt;a class="anchor" href="#what-i-worked-on" data-anchor="what-i-worked-on" aria-hidden="true">#&lt;/a>
 What I Worked On
&lt;/h2>
&lt;p>Two major features this week, email integration (SIRA-160) and session management (SIRA-214), both followed the SOLID principles that have been established in the codebase. The email feature in particular offered a good opportunity to show SRP in action: sending an email and rendering an email template are genuinely different responsibilities, and keeping them separate made both easier to test.&lt;/p>
&lt;hr>
&lt;h2 id="email-integration-separating-transport-from-rendering">
 &lt;a class="anchor" href="#email-integration-separating-transport-from-rendering" data-anchor="email-integration-separating-transport-from-rendering" aria-hidden="true">#&lt;/a>
 Email Integration: Separating Transport from Rendering
&lt;/h2>
&lt;p>SIRA-160 (MR !108) introduced three distinct services:&lt;/p></description></item><item><title>PPL: Service Layer Instrumentation [Sprint 2, Week 1]</title><link>https://blog.abhipraya.dev/ppl/part-b/s2w1-programming/</link><pubDate>Mon, 23 Mar 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-b/s2w1-programming/</guid><description>&lt;h2 id="what-i-worked-on">
 &lt;a class="anchor" href="#what-i-worked-on" data-anchor="what-i-worked-on" aria-hidden="true">#&lt;/a>
 What I Worked On
&lt;/h2>
&lt;p>This week I implemented custom Sentry span instrumentation across 3 key API services to track sub-operation latency in GlitchTip. The interesting part wasn&amp;rsquo;t the Sentry API itself; it was &lt;strong>where&lt;/strong> to place the instrumentation in our layered architecture, and how the existing SOLID patterns made the change trivially simple.&lt;/p>
&lt;h2 id="following-the-architecture-spans-in-services-not-routers">
 &lt;a class="anchor" href="#following-the-architecture-spans-in-services-not-routers" data-anchor="following-the-architecture-spans-in-services-not-routers" aria-hidden="true">#&lt;/a>
 Following the Architecture: Spans in Services, Not Routers
&lt;/h2>
&lt;p>SIRA follows a strict Router → Service → DB pattern. Routers handle HTTP concerns (auth, status codes). Services hold business logic. DB queries are isolated in &lt;code>db/queries/&lt;/code>.&lt;/p></description></item><item><title>PPL: SOLID and Layered Architecture [Sprint 1, Week 3]</title><link>https://blog.abhipraya.dev/ppl/part-b/s1w3-programming/</link><pubDate>Fri, 13 Mar 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-b/s1w3-programming/</guid><description>&lt;h2 id="what-i-worked-on">
 &lt;a class="anchor" href="#what-i-worked-on" data-anchor="what-i-worked-on" aria-hidden="true">#&lt;/a>
 What I Worked On
&lt;/h2>
&lt;p>This week&amp;rsquo;s invoice management feature (MR !12) required a full CRUD stack with filtering, sorting, auth enforcement, and business validation (status transitions, admin-only delete). Building this properly meant enforcing strict layer boundaries and handling the tension between HTTP concerns and domain logic.&lt;/p>
&lt;h2 id="the-three-layer-pattern-in-practice">
 &lt;a class="anchor" href="#the-three-layer-pattern-in-practice" data-anchor="the-three-layer-pattern-in-practice" aria-hidden="true">#&lt;/a>
 The Three-Layer Pattern in Practice
&lt;/h2>
&lt;p>SIRA&amp;rsquo;s backend follows Router → Service → DB, where each layer has a single responsibility:&lt;/p></description></item></channel></rss>