Syed Zubyl N | Software Developer - Backend

Understanding Java Backend Development by Building Real Projects

2026-06-12T00:00:00+00:00

The Problem</h3>
Learning Java syntax is easy. Understanding how to build a production-grade backend system is hard. Many tutorials stop at creating a simple `HelloWorldController</code>, leaving developers confused about how to structure a large application, manage dependencies, and handle complex business logic.`

Context</h3> When I started diving deep into Java and Spring Boot, I wanted to move past theoretical examples and understand the actual mechanics of a production backend. How do services communicate? How do we handle transactions? Where does business logic actually live? What I Tried</h3> I initially tried to learn by reading textbooks on Design Patterns and Object-Oriented Programming (OOP) in isolation. I studied Singleton, Factory, and Strategy patterns. What Failed</h3> While I understood the patterns conceptually, I had no idea when or why to use them in a real web server. The abstractions felt unnecessary. Writing an interface for a simple database query seemed like over-engineering when I could just write the logic directly in the controller. What Worked & Technical Explanation</h3> The “aha” moment came when I stopped reading isolated examples and built a real REST API managing complex data relationships. Suddenly, the concepts clicked: 1. Dependency Injection (DI) I finally understood why Spring’s @Autowired</code> (or constructor injection) is brilliant. Instead of a Service instantiating a specific Database class (tight coupling), the framework injects it. This meant I could swap my production database repository for a Mock repository during testing without changing a single line of business logic. 2. Interfaces and Implementations I used an interface PaymentProcessor</code>. In development, I injected a MockPaymentProcessor</code>. In production, I injected a StripePaymentProcessor</code>. The controller didn’t care; it just called paymentProcessor.charge()</code>. This is OOP in actual practice. 3. Exception Handling Instead of scattering try-catch</code> blocks everywhere, I utilized Spring’s @ControllerAdvice</code>. I threw custom exceptions (UserNotFoundException</code>) deep in the service layer, and a global handler automatically translated them into formatted 404 Not Found</code> JSON responses. Lessons Learned</h3> You cannot learn enterprise architecture by writing isolated Java classes. You learn it by encountering the pain of tightly coupled code in a growing project, and then discovering how frameworks like Spring Boot use DI and interfaces to solve that exact pain. What I Would Do Differently</h3> I would have focused on Test-Driven Development (TDD) from day one. Writing unit tests forces you to use Dependency Injection and interfaces properly. If a class is hard to test, it’s usually because it’s poorly architected. Testing is the ultimate feedback loop for good Java design.

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. 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). The flow looks like this: Mobile Client ↓ (JSON over HTTPS) API Gateway / Controller ↓ (DTOs) Service Layer ↓ (Entities) Repository Layer ↓ (SQL) Database</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. What Failed</h3> This failed spectacularly as the application grew. Testing: I couldn’t test the business logic without mocking the entire HTTP request/response cycle.</li> Reusability: 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: 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. 1. The API Layer (Controllers) 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. 2. The Service Layer (Business Logic) 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. 3. The Repository Layer (Data Access) This layer handles the actual database communication using an ORM like Hibernate or raw SQL queries. It returns Domain Entities. 4. External Services 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. 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. 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. Debugging a 405 Method Not Allowed Error in a Mobile API 2026-02-14T00:00:00+00:00 The Problem</h3> While developing a mobile application, a specific API endpoint for fetching user profile data suddenly started failing. The mobile client was receiving a 405 Method Not Allowed</code> HTTP status code, and the data refused to load. Context</h3> The application relies on a Spring Boot backend exposing RESTful endpoints. The mobile client (built in Flutter) communicates with this API using the http</code> package. The endpoint in question was /api/v1/users/profile</code>. What I Tried</h3> At first, I assumed the authentication token was invalid or the endpoint URL was misspelled. I checked the JWT token — it was valid.</li> I verified the URL string in the Dart code — it perfectly matched the backend controller.</li> I checked the server logs, expecting to see a NullPointerException</code> or a 400 Bad Request</code>. Instead, Spring Security was just quietly rejecting the request at the filter level.</li> </ol> What Failed</h3> I spent an hour looking at the backend logic, assuming the database query was failing or the routing was broken. None of this was the issue because the request wasn’t even reaching my controller method. What Worked & Technical Explanation</h3> The breakthrough came when I bypassed the mobile app entirely and used Postman to test the endpoint. When I sent a GET</code> request in Postman: 200 OK. When I looked closely at my Flutter network layer: // The bug final response = await http.post( Uri.parse('https://api.example.com/api/v1/users/profile'), headers: {'Authorization': 'Bearer $token'}, );</code></pre> The issue was glaringly simple: I was using http.post</code> for an endpoint that the backend explicitly defined as a @GetMapping</code>. A 405 Method Not Allowed</code> means exactly what it says: the server exists, the route exists, but the HTTP verb (GET, POST, PUT, DELETE) you used is not supported for that specific route. It is fundamentally different from a 404 Not Found</code> (route doesn’t exist) or a 400 Bad Request</code> (payload is wrong). I corrected the mobile client to use http.get</code>: // The fix final response = await http.get( Uri.parse('https://api.example.com/api/v1/users/profile'), headers: {'Authorization': 'Bearer $token'}, );</code></pre>Lessons Learned</h3> Read the HTTP Status Code literally. Don’t assume a 405 is a generic crash. It has a highly specific meaning defined by the HTTP protocol.</li> Isolate the client from the server. When an API fails in a mobile app, test the exact same request in curl</code> or Postman immediately. This tells you instantly if the bug is in the client code (Flutter) or the server code (Spring Boot).</li> </ol> What I Would Do Differently</h3> I will implement a centralized API client class in Flutter with strict typed methods (fetchProfile()</code>, updateProfile()</code>) rather than writing raw http.get</code> or http.post</code> calls scattered throughout the UI code. This reduces the surface area for simple typo bugs like using the wrong HTTP verb.

Syed Zubyl N | Software Developer - Backend

Understanding Java Backend Development by Building Real Projects

What I Tried</h3>
I initially tried to learn by reading textbooks on Design Patterns and Object-Oriented Programming (OOP) in isolation. I studied Singleton, Factory, and Strategy patterns.</p>

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>

Debugging a 405 Method Not Allowed Error in a Mobile API

The Problem</h3>
While developing a mobile application, a specific API endpoint for fetching user profile data suddenly started failing. The mobile client was receiving a `405 Method Not Allowed</code> HTTP status code, and the data refused to load.</p>`

What Failed</h3>
I spent an hour looking at the backend logic, assuming the database query was failing or the routing was broken. None of this was the issue because the request wasn’t even reaching my controller method.</p>

Syed Zubyl N | Software Developer - Backend

Understanding Java Backend Development by Building Real Projects

What I Tried</h3> I initially tried to learn by reading textbooks on Design Patterns and Object-Oriented Programming (OOP) in isolation. I studied Singleton, Factory, and Strategy patterns.</p>

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>

Debugging a 405 Method Not Allowed Error in a Mobile API

The Problem</h3> While developing a mobile application, a specific API endpoint for fetching user profile data suddenly started failing. The mobile client was receiving a 405 Method Not Allowed</code> HTTP status code, and the data refused to load.</p>

What Failed</h3> I spent an hour looking at the backend logic, assuming the database query was failing or the routing was broken. None of this was the issue because the request wasn’t even reaching my controller method.</p>

What I Tried</h3>
I initially tried to learn by reading textbooks on Design Patterns and Object-Oriented Programming (OOP) in isolation. I studied Singleton, Factory, and Strategy patterns.</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>

The Problem</h3>
While developing a mobile application, a specific API endpoint for fetching user profile data suddenly started failing. The mobile client was receiving a `405 Method Not Allowed</code> HTTP status code, and the data refused to load.</p>`

What Failed</h3>
I spent an hour looking at the backend logic, assuming the database query was failing or the routing was broken. None of this was the issue because the request wasn’t even reaching my controller method.</p>