Mohitt Chopra’s Post

Day 18. I was using @Transactional everywhere. Thinking I was writing safe code. I wasn’t. I was slowing my system down. Every time you add @Transactional, you open a database connection. And you hold it. Until the method finishes. I had it on everything. Read methods. Write methods. All of it. Under load — it broke. Connection pool exhausted. API slowed down. Then stopped responding. That’s when it clicked. @Transactional is not protection. It’s a cost. I had code like this: @Transactional public UserDTO getUser(Long id) { User user = repository.findById(id).orElseThrow(); return new UserDTO(user); } No writes. Still holding a transaction. Completely unnecessary. So I changed it. (see implementation below 👇) What I learned: → Not every method needs a transaction → Read operations usually don’t → Write operations always do The hard truth: → @Transactional is overused → Most developers don’t know why they added it → It only shows under load Adding @Transactional is easy. Knowing when NOT to add it is what makes you a backend developer. Are you using @Transactional everywhere? 👇 Drop it below #SpringBoot #Java #BackendDevelopment #JavaDeveloper #Performance

🚀 “Most developers use APIs every day… but very few actually understand how they work.” When I started with Spring Boot, I memorized things like: ✔ @RestController ✔ @GetMapping ✔ @RequestMapping I could build APIs. But if someone asked me: 👉 “What actually happens when a request hits your API?” …I didn’t have a clear answer. That’s when I realized: 👉 I was learning annotations 👉 But not understanding the flow 💡 Here’s the simple truth behind every REST API: It’s just a flow 👇 Client → Request → Mapping → Controller → Response 🧠 Let’s break it down simply: 🔹 @RequestMapping Routes the incoming request to the right method (Think: “Where should this go?”) 🔹 @RestController Handles the request and sends back response (Usually JSON — what frontend actually uses) 🔹 HTTP Methods • GET → Fetch data • POST → Create data • PUT → Update • DELETE → Remove 🔹 @PathVariable Takes value directly from URL Example: /users/101 🔹 @RequestParam Takes input from query Example: /search?keyword=phone ⚡ Why this matters (real world): When things break in production… Nobody cares if you know annotations. 👉 They care if you understand the flow 👉 They care if you can debug the request 👉 They care if you can fix it fast 💥 Big realization: > APIs are not about writing code. They’re about handling communication between systems. 📌 Simple shift that helps a lot: Don’t just ask: “How do I write this API?” Start asking: “Where does this request come from… and where does it go?” Because that’s where real backend thinking begins. 💬 Let’s test this: Can you clearly explain what happens from API request → response? Yes or still learning? 👇 #SpringBoot #Java #BackendDevelopment #RESTAPI #SoftwareEngineering #Developers #Coding #TechCareers #Programming #SystemDesign

Production called. It wasn't happy. Story time! Imagine this scenario... Two severe issues land simultaneously. Users can't preview data. Downstream systems are collecting duplicate records like they were loyalty points. Fun times... haha! Now here's what nobody tells you about prod incidents; the technical diagnosis is actually the easy part. A null pointer exception and a refactoring gone wrong? Painful, but fixable. Seen worse before coffee got cold ;) The harder part is what happens around the incident. Because in every high-pressure situation, developers split into two camps: 1. The ones who find the problem - own it, fix it, document it, and sleep fine that night knowing they made the system better. 2. The ones who find an explanation - technically accurate enough to sound credible, just conveniently pointed away from themselves. Both might fix the bug. Only one actually fixes the team. The mark of a truly great engineer isn't clean code... it's clean accountability. Anyone can write good code on a good day. It takes real skill and character to raise your hand on a bad one. That's the standard I hold myself to... whether I'm designing systems, writing Spring Boot services, building React interfaces, or just staring at a stack trace at 11pm wondering what I did to deserve this XD Accountability is a feature, not a bug. Ship it. Seniors and veterans! I'd love to hear your take. Ever been in a situation like this? What's your story? Drop it below :) #SoftwareEngineering #SystemDesign #Java #SpringBoot #ReactJS #Accountability #TechCulture #EngineeringExcellence #Developer #GrowthMindset

⚖️ The hardest part of backend development isn’t coding… it’s deciding what not to build. While working on a feature, I initially thought: 👉 “Let’s make this more scalable, more flexible, more generic…” But then I paused. Did we really need: Extra abstraction layers? Multiple services? Over-engineered design? 👉 The answer was NO. We simplified: ✔ Kept the API straightforward ✔ Avoided unnecessary complexity ✔ Built only what was needed for the current use case Result? ✔ Faster development ✔ Easier debugging ✔ Better maintainability 💡 Lesson: Good engineering is not about adding more — It’s about making the right trade-offs. Sometimes, the simplest solution is the most scalable one. Curious — have you ever over-engineered something and later simplified it? #BackendEngineering #Java #SpringBoot #Microservices #SoftwareDesign #CleanCode

Earlier today I asked our Year Up instructor Matthew C. a simple question. I told him I wanted explore into Fullstack and DevOps as a career. What should I be exploring? He pointed me toward exploring JavaFX as we are still in Week 2 of Java base on my previous experience working with React and the Next framework in web development and he gave me great insights into why companies may choose electron for their uses. But before I even got there, we had an assignment. A theater reservation system. The program takes a guest's name, a date, and a ticket count and outputs a formatted confirmation message. Simple enough on the surface. The name had to come out as Last, First. The date had to reformat from MM/DD/YYYY to YYYY-MM-DD etc". Small things but it forced me to actually think about how data flows and how you format it for real output in a real world application Once I had that working in the terminal I thought, what if I can turned this into something you could actually see and use. Like one of those kiosks at the airport or a point of sale machine like Toast. So after class I opened IntelliJ and just started experimenting with JavaFX. It did not go smoothly. Version mismatches, null pointers, wrong field names. Every time I thought I was done something else broke. The window opened once. Crashed. Opened again, figure out whats wrong with the code. Until finally it just worked. It looked like something a real business would use. That eureka moment was great honestly and felt satisfying after hours of figuring out "What the heck is wrong now" Thank you Matthew C. for answering my question in a way that sent me down a rabbit hole that taught me more in one day than I expected. #Java #YearUpUnited #SoftwareDevelopment #ApplicationDevelopment #BuildingInPublic

🚀 From Code to Real-World Impact: My Open Source Journey on Maven Central Over the past few months, I’ve been quietly building and publishing Java libraries to solve real engineering problems. Today, I paused to look at the numbers… and they tell a meaningful story: 📦 4.7K+ downloads in the last 3 months 🌍 100+ unique sources (actual projects using the libraries) 🏢 40+ companies adopting these libraries This isn’t just about downloads. It means code I wrote is now running in systems I’ve never seen, solving problems for teams I’ve never met. That’s the real power of open source. 💡 What I focused on while building: Clean, reusable API design Production-ready packaging (Maven Central) Solving practical backend problems (not just demos) Keeping things simple for developers to adopt 📉 I also noticed a spike in March and a drop in April. That reminded me: building is one part, but consistency, visibility, and developer experience matter just as much. 🔜 Next focus: Better documentation & real-world examples Spring Boot integrations More frequent releases Scaling adoption to 50K+ downloads If you’re building libraries or thinking about open source, my biggest takeaway is simple: 👉 Don’t just write code. Build something others can actually use. I’d love to connect with folks working on Java, backend systems, or open source. #Java #OpenSource #Maven #BackendEngineering #SoftwareEngineering #TechLeadership #BuildInPublic

I'm 1.5 years into backend development. Here are 3 Spring Boot lessons college never taught me. I learned them the hard way — through bugs, broken  deployments, and production support calls at 2 AM. Sharing them so you don't have to. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1. @Transactional is deceptively simple. Reading docs: "Just annotate your method." Reality: Propagation, isolation, rollback rules,  self-invocation — the moment you get it wrong, your  data is corrupted and you don't know why. Lesson: Read the Spring Transaction docs. Twice. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2. Kafka > REST for inter-service communication. I used to make services call each other with  RestTemplate like it was a REST phone chain. Then Service B went down. Service A hung. Service C  timed out. Domino effect. Event-driven with Kafka = decoupled, resilient,  scalable. Just learn it. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3. Spring Security feels impossible on Day 1. Every tutorial seems to disagree. Every Stack Overflow  answer is from 2019. Stick with it. By Day 30, you're shipping JWT +  role-based auth like it's second nature. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ What's one lesson YOU wish someone had told you  earlier as a Java dev? Drop it in the comments 👇 Let's make this thread a  survival guide for every Java dev who's about to  learn the hard way. #Java #SpringBoot #BackendDeveloper #Microservices  #Kafka #SoftwareEngineering #SpringFramework

Day 9 – Making Sense of My Tech Stack (Not Chasing Every New Tool) 🧭 When you’re in tech, it’s easy to feel FOMO: Java, Node, Spring, React, Next.js, MongoDB, PostgreSQL, Docker, Kubernetes… it never ends. For a while, I was trying to “learn everything” and ended up with 10 open tutorials and 0 deep skills. Now I’m approaching my tech stack with more clarity: My current focus stack looks like this: Frontend: HTML, CSS, modern JavaScript + one framework (React) Backend: Java + Spring Boot (APIs, auth, business logic) Database: SQL + basics of NoSQL (e.g., MongoDB) Extras: Git/GitHub, basic deployment & APIs The rule I’m following now: Go wide enough to ship a full‑stack project, then go deep where it matters. Instead of jumping stacks every month, I want to really understand: How data flows from UI → API → DB and back How to design clean APIs and handle errors How to apply fundamentals (DSA, OOP, DB design) inside this stack If you’re confused about “which stack to choose”: Pick one realistic combo that lets you build full‑stack apps, commit to it for a few months, and learn by shipping. Clarity in stack → clarity in learning → faster growth. 🚀 #Day9 #TechStack #FullStackDeveloper #JavaDeveloper #LearningInPublic #Consistency

I used to hit NullPointerExceptions a lot in my early days… and it was frustrating. While working on backend features, I kept running into these issues. I would fix one case, and another would show up somewhere else. After a point, I realized it wasn’t just a bug, it was how I was writing code. Most of the time, I was assuming values would always be present. But in real scenarios, that’s not always true. So I started changing my approach: - Validating inputs instead of assuming - Using Optional where it made sense - Adding null checks at critical points - Returning proper responses instead of letting it fail Over time, things became much more stable. Fewer unexpected errors, and debugging became easier. It made me understand - handling nulls properly is not just about avoiding exceptions, it’s about writing safer and more reliable code. Don’t assume data will always be there. Handle it like it might not be. #Java #BackendDevelopment #SpringBoot #CleanCode #LearningInPublic #SoftwareDevelopment

Day 90 of My 9-Month Coding Challenge 🎯 Error Handling & API Stability in Backend ⚙️ Today, I focused on making my backend more robust by implementing proper error handling—because a secure system is not just about preventing attacks, but also about handling failures gracefully. 🛠️ What I Worked On: ✔ Implemented centralized error handling middleware in Express ✔ Created custom error classes for consistent error responses ✔ Handled async errors using wrapper functions (avoid try-catch repetition) ✔ Managed validation, authentication, and server errors separately ✔ Sent structured error responses (status code + message + details) 📚 Key Learnings: ✅ Unhandled errors can crash your server or expose sensitive data ✅ Centralized error handling improves maintainability ✅ Consistent error responses make APIs easier to debug and consume ✅ Never leak internal error details in production ✅ Proper logging is essential for debugging real-world issues 🧠 Core Concept: Stable Backend = Proper Error Handling + Controlled Responses + Safe Logging 💡 Insight: Users don’t trust systems that fail unpredictably. Handling errors well is just as important as writing correct logic. Still learning. Still improving. Still consistent. 💯 #Day90 #9MonthChallenge #NodeJS #ExpressJS #BackendDevelopment #ErrorHandling #WebDevelopment #MERN #BuildInPublic #Consistency