Syed Zubyl N | Software Developer - Architecture

Designing a Production-Oriented Application from Mobile UI to Database

2026-05-02T00:00:00+00:00

The Problem</h3>
When transitioning from building simple prototype applications to production-oriented software, the architecture must change fundamentally. A prototype can connect a mobile UI directly to a database like Firebase, bypassing strict backend validation. A production application cannot. It requires clear separation of concerns, strict validation, and the ability to scale different components independently.</p>

Context</h3>

The goal is to design a system where a Flutter mobile client securely interacts with a Java Spring Boot backend, which in turn manages business logic and talks to a relational database (MySQL).</p>

The flow looks like this:</p>

Mobile Client </span></span>
  ↓ (JSON over HTTPS)</span></span>
API Gateway / Controller </span></span>
  ↓ (DTOs)</span></span>
Service Layer </span></span>
  ↓ (Entities)</span></span>
Repository Layer </span></span>
  ↓ (SQL)</span></span>
Database</span></span></code></pre>What I Tried (The Anti-Pattern)</h3>
Early in my learning journey, I tried building “fat controllers.” The API controller would receive an HTTP request, open a database transaction, parse the JSON, write custom SQL queries, and return an HTTP response all in one massive function.</p>
What Failed</h3>
This failed spectacularly as the application grew.</p>

Testing:</strong> I couldn’t test the business logic without mocking the entire HTTP request/response cycle.</li>
Reusability:</strong> When a scheduled background job needed to update user records, I had to duplicate the code from the controller because the controller was tightly coupled to HTTP requests.</li>
Security:</strong> Raw data structures were passed directly back to the client, exposing internal database IDs and password hashes.</li>
</ol>
What Worked & Technical Explanation</h3>
I implemented a strict N-Tier Architecture, separating concerns at every layer.</p>
1. The API Layer (Controllers)</strong>
Controllers only care about HTTP. They receive a request, validate the incoming JSON against a Data Transfer Object (DTO), and immediately pass the data to the Service Layer.</p>
2. The Service Layer (Business Logic)</strong>
This is the brain of the application. It knows nothing about HTTP or SQL. It receives validated DTOs, applies business rules (e.g., “A user cannot register if they are under 18”), and coordinates with the Repository Layer.</p>
3. The Repository Layer (Data Access)</strong>
This layer handles the actual database communication using an ORM like Hibernate or raw SQL queries. It returns Domain Entities.</p>
4. External Services</strong>
If the application needs to send an email or process a payment, the Service Layer calls an Interface (e.g., EmailService</code>). The actual implementation (e.g., SendGridEmailServiceImpl</code>) is injected.</p>
Lessons Learned</h3>
Separation of concerns is not just theoretical computer science overhead. It is the only way to build software that can survive changing requirements. By decoupling the HTTP layer from the business logic, I can swap out the web framework. By decoupling the business logic from the database, I can swap out the ORM.</p>
What I Would Do Differently</h3>
I would introduce an API Gateway pattern earlier if the system required microservices. However, for most of the production applications I build, a well-structured modular monolith using the exact architecture described above is significantly more efficient to deploy and maintain.</p>



Designing a Reliable API Layer for a Mobile Application
2026-03-22T00:00:00+00:00
The Problem</h3>
In the early stages of a mobile LMS application, HTTP requests were scattered directly inside UI widgets. Buttons would execute http.get</code>, parse JSON inline, and call setState</code>. This quickly became unmaintainable. Token expiration caused random crashes, error handling was inconsistent, and mocking data for tests was impossible.</p>
Context</h3>
A robust mobile application requires a strict separation of concerns. The UI should only care about displaying</em> state, not fetching it. The networking layer must handle token injection, timeouts, retries, and error standardization before the data ever reaches the UI.</p>
What I Tried</h3>
I initially tried to create a single massive ApiService</code> class that contained every single endpoint in the application.</p>
What Failed</h3>
The ApiService</code> file grew to thousands of lines. When multiple developers worked on different features (Authentication, Courses, User Profile), merge conflicts became a daily nightmare. Furthermore, handling token refreshes on a per-method basis resulted in heavily duplicated code.</p>
What Worked & Technical Explanation</h3>
I re-architected the API layer into a layered, modular system based on the Repository Pattern and Interceptors.</p>
1. The Base HTTP Client (The Interceptor Layer)</strong>
Instead of using raw http.Client</code>, I implemented a wrapper (using packages like dio</code> or custom http.BaseClient</code> implementations) that intercepts every request.</p>

Request Interceptor:</strong> Automatically injects the Authorization: Bearer <token></code> header from secure storage into every outgoing request.</li>
Response Interceptor:</strong> Global error handling. If a 401 Unauthorized</code> is returned, the interceptor pauses all outgoing requests, silently hits the refresh-token endpoint, updates secure storage, and retries the failed requests.</li>
</ul>
2. Domain-Specific Repositories</strong>
Instead of one massive API class, I created focused repositories:</p>

AuthRepository</code>: Handles login, registration, and token management.</li>
CourseRepository</code>: Fetches course lists and lesson details.</li>
VideoRepository</code>: Manages video streaming URLs and playback telemetry.</li>
</ul>
3. Standardized Result Wrappers</strong>
Instead of throwing exceptions directly into the UI, repositories return a standardized Result type (often using Dart’s Either</code> pattern via the fpdart</code> or dartz</code> package).</p>
Future</span><</span>Either</span><</span>ApiFailure</span>,</span> Course</span>>></span> getCourseDetails</span>(</span>String</span> id) </span>async</span> {</span></span>
  try</span> {</span></span>
    final</span> response </span>= await</span> _client.</span>get</span>(</span>'/courses/$</span>id</span>'</span>);</span></span>
    return</span> Right</span>(</span>Course</span>.</span>fromJson</span>(response.data));</span></span>
  } </span>on</span> DioError</span> catch</span> (e) {</span></span>
    return</span> Left</span>(</span>ApiFailure</span>.</span>fromDioError</span>(e));</span></span>
  }</span></span>
}</span></span></code></pre>Lessons Learned</h3>
Separating the UI from the network layer is non-negotiable for production apps. The complexity of handling network latency, offline states, and token lifecycles must be encapsulated so the UI can remain declarative and clean.</p>
What I Would Do Differently</h3>
I would implement local caching (using SQLite) much earlier in the architecture. While the API layer was robust, relying entirely on network availability resulted in a poor experience on slow connections. Integrating a repository that checks local storage before</em> hitting the API is the next logical step.</p>


Flutter Splash Screens vs Native Android Startup Screens
2026-01-25T00:00:00+00:00
The Problem</h3>
A client wanted a highly customized, complex, animated Flutter-style splash screen to play the moment the user tapped the app icon. They wanted their branding to animate immediately, replacing the “boring” default app launch experience.</p>
Context</h3>
When an Android application launches, there is an unavoidable window of time where the OS loads the app process into memory. During this time, Android displays a system-controlled launch screen. With the introduction of Android 12, Google enforced the SplashScreen</code> API, standardizing this experience to show the app icon and a background color.</p>
Flutter operates inside an Android Activity. The Flutter engine must initialize, load the Dart isolate, and render the first frame. This takes time.</p>
What I Tried</h3>
The client wanted the animation to start instantly. I initially tried putting the animation directly into the first Flutter widget loaded by runApp()</code>.</p>
What Failed</h3>
This resulted in a jarring experience:</p>

User taps app.</li>
System shows Android 12 static splash screen (icon + background).</li>
System splash disappears.</li>
White flash (briefly, as Flutter attaches).</li>
Flutter animated splash screen begins.</li>
</ol>
It looked like two separate splash screens playing back-to-back.</p>
What Worked & Technical Explanation</h3>
The actual limitation is that the system-controlled Android launch splash occurs before</em> the Flutter UI is ready, especially under Android 12+ splash-screen rules. A Flutter animation can begin after the Flutter engine/UI becomes available, but it does not replace the system launch sequence in the same way.</p>
The correct approach was a hybrid hand-off:</p>

Configure the native Android 12 SplashScreen</code> via styles.xml</code> to match the exact background color and static logo of the first frame of the Flutter animation.</li>
Use the flutter_native_splash</code> package to hold the native splash screen up until Flutter is fully rendered.</li>
Once Flutter renders its first frame, immediately begin the complex Flutter animation from the exact state the native splash left off.</li>
</ol>
<!-- android/app/src/main/res/values-v31/styles.xml --></span></span>
<</span>style</span> name</span>=</span>"LaunchTheme"</span> parent</span>=</span>"Theme.SplashScreen"</span>></span></span>
    <</span>item</span> name</span>=</span>"windowSplashScreenBackground"</span>>@color/brand_background</</span>item</span>></span></span>
    <</span>item</span> name</span>=</span>"windowSplashScreenAnimatedIcon"</span>>@drawable/launch_icon</</span>item</span>></span></span>
    <</span>item</span> name</span>=</span>"postSplashScreenTheme"</span>>@style/NormalTheme</</span>item</span>></span></span>
</</span>style</span>></span></span></code></pre>Lessons Learned</h3>
You cannot fight the OS. The Android lifecycle dictates what happens before your application code runs. Understanding the boundaries between native Android processes and the Flutter engine is critical for smooth UX.</p>
What I Would Do Differently</h3>
I will clarify the distinction between “OS Launch Screen” and “App Onboarding Animation” to clients early on. Managing expectations around what happens in the first 500ms of an app’s lifecycle prevents impossible requests later.</p>

Syed Zubyl N | Software Developer - Architecture

Designing a Production-Oriented Application from Mobile UI to Database

What I Tried (The Anti-Pattern)</h3> Early in my learning journey, I tried building “fat controllers.” The API controller would receive an HTTP request, open a database transaction, parse the JSON, write custom SQL queries, and return an HTTP response all in one massive function.</p>

Designing a Reliable API Layer for a Mobile Application

Lessons Learned</h3> Separating the UI from the network layer is non-negotiable for production apps. The complexity of handling network latency, offline states, and token lifecycles must be encapsulated so the UI can remain declarative and clean.</p>

Flutter Splash Screens vs Native Android Startup Screens

The Problem</h3> A client wanted a highly customized, complex, animated Flutter-style splash screen to play the moment the user tapped the app icon. They wanted their branding to animate immediately, replacing the “boring” default app launch experience.</p>

Lessons Learned</h3> You cannot fight the OS. The Android lifecycle dictates what happens before your application code runs. Understanding the boundaries between native Android processes and the Flutter engine is critical for smooth UX.</p>

What I Would Do Differently</h3> I will clarify the distinction between “OS Launch Screen” and “App Onboarding Animation” to clients early on. Managing expectations around what happens in the first 500ms of an app’s lifecycle prevents impossible requests later.</p>

What I Tried (The Anti-Pattern)</h3>
Early in my learning journey, I tried building “fat controllers.” The API controller would receive an HTTP request, open a database transaction, parse the JSON, write custom SQL queries, and return an HTTP response all in one massive function.</p>

Lessons Learned</h3>
Separating the UI from the network layer is non-negotiable for production apps. The complexity of handling network latency, offline states, and token lifecycles must be encapsulated so the UI can remain declarative and clean.</p>

The Problem</h3>
A client wanted a highly customized, complex, animated Flutter-style splash screen to play the moment the user tapped the app icon. They wanted their branding to animate immediately, replacing the “boring” default app launch experience.</p>

Lessons Learned</h3>
You cannot fight the OS. The Android lifecycle dictates what happens before your application code runs. Understanding the boundaries between native Android processes and the Flutter engine is critical for smooth UX.</p>

What I Would Do Differently</h3>
I will clarify the distinction between “OS Launch Screen” and “App Onboarding Animation” to clients early on. Managing expectations around what happens in the first 500ms of an app’s lifecycle prevents impossible requests later.</p>