Alexey Lizurchik’s Post

Ever wondered why React + Docker sometimes feels like a fight between your node_modules and your hot reload? I was setting up a React dev environment in Docker and ran this command: docker run -p 5173:5173 \ -v "$(pwd):/app" \ -v /app/node_modules \ react-docker Here’s what it does: -p 5173:5173 → maps the container port to my machine so I can open http://localhost:5173 -v "$(pwd):/app" → mounts my project folder into the container, so code changes update instantly -v /app/node_modules → saves the container’s node_modules separately, so they don’t get wiped out by my local environment Result: I get hot reload while keeping dependencies consistent inside the container. Takeaway: When running frontend dev in Docker, don’t blindly mount your whole project. Protect your node_modules and you’ll save yourself a lot of debugging time. What’s your frontend dev workflow — bare metal, Docker, or WSL?

7 API Best Practices Every Backend Developer Must Know APIs are the backbone of modern applications. But messy APIs lead to bugs, security issues, and frustrated developers. Here’s a cheat sheet of 7 API best practices every backend developer should follow 👇 ✅ 7 API Best Practices 1. Use RESTful Principles — Stick to predictable resource-based endpoints with correct HTTP verbs. 2. Version Your API — Ensure backward compatibility (/api/v1, /api/v2). 3. Consistent Naming & Structure — Use plural resources & consistent JSON key styles. 4. Authentication & Authorization — Implement JWT/OAuth2, never pass credentials in query params. 5. Meaningful Error Handling — Use standard HTTP status codes & JSON error objects. 6. Rate Limiting & Throttling — Prevent abuse, add headers like X-RateLimit-Limit. 7. Documentation & Testing — Use Swagger/OpenAPI + automated integration tests. By following these practices, you’ll build APIs that are secure, scalable, and developer-friendly. 👉 I’ve broken down each of these steps with real-world examples and code snippets in my full article here: https://lnkd.in/d6ym93CA #API #BackendDevelopment #WebDevelopment #Programming #SoftwareEngineering #Developers #RESTAPI #CodeTips

Deployed a Flask E-mail Api with render. This project allows users to send emails via a simple API endpoint using Flask-Mail. Along the way, I got hands-on experience with: Structuring Flask apps with blueprints Managing environment variables securely with .env Running production-ready servers with Gunicorn Testing APIs with Postman This marks a big step in building real-world, deployable backend applications. 💡 Curious to see it in action? Check out the Postman demo and repo here: https://lnkd.in/deB6MRQf

💡 Split it. Connect it. Run it. That’s how I built BlueWave Tracker. With 𝐃𝐨𝐜𝐤𝐞𝐫 𝐂𝐨𝐦𝐩𝐨𝐬𝐞, I turned a simple Flask project into a connected system of three services: 𝐅𝐥𝐚𝐬𝐤 → backend web server  𝐑𝐞𝐝𝐢𝐬 → stores visits (with Docker volumes for persistence) 𝐍𝐆𝐈𝐍𝐗 → reverse proxy + load balancer   Each runs in its own container, but together they act like one seamless app.   A small build — but a big step toward understanding real-world orchestration. Github repo in the comments below 👇 #Docker #DevOps #Containers #LearningInPublic 

⚡️ Spring Boot DevTools – the hidden productivity booster Ever get tired of: - Changing code - Stopping the server - Rebuilding - Restarting ...just to test a small change? 🥲 That’s where Spring Boot DevTools comes in. ✨ Add this dependency: <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <optional>true</optional> </dependency> What you get: - Auto-restart → app restarts automatically on code changes - Live reload → refreshes browser instantly (with plugin) - Dev-only → automatically disabled in production - Faster restart time → because it caches stuff smartly This tiny trick can save hours of time if you’re developing daily in Spring Boot. #SpringBoot #Java #BackendDevelopment #SpringFramework #SoftwareDevelopment

This week: Diving deeper into backend fundamentals and security practices Spent this week learning things that seem small but have big impact on production code quality and user experience. 1. 🔧 Error handling: axios vs fetch axios auto-throws on 4xx/5xx → handle in catch blocks fetch treats all HTTP responses as "successful" → must check response.ok manually Debugged for hours before realizing my 400 error was in .then(), not .catch() 2.⏱️ Request timeouts with AbortController fetch() has no built-in timeout—users wait indefinitely if APIs don't respond AbortController lets you cancel requests after X seconds It is critical for third-party APIs, slow backends, and file uploads. I'm adding to my implementation list for better UX 3.📝 Git commits: Conventional Commits Upgraded from "Added feature" to feat: Add feature Format: <type>: <description> (feat, fix, docs) Some of the best practices are imperative mood, <50 chars, capitalize, no period Clean Git history = easier collaboration and debugging 4. 🔒 Authorization isn't optional: IDOR prevention Almost shipped a critical bug in my finance manager v1 Without ownership verification middleware, any user could manipulate URLs to delete others' data Authentication (who are you?) ≠ Authorization (can you access THIS?) Ownership checks are mandatory, not "extra" security These aren't just theory—implementing timeout handling now and already using Conventional Commits + ownership middleware in my projects. What's one "small" thing you learned recently that had a bigger impact than expected? #BackendDevelopment #WebSecurity #LearningInPublic #NodeJS #CleanCode

# 🧩 Next.js 16 Simplified: Understanding the `.next/dev` Folder 🏁 TL;DR Next.js 16 brings a small but powerful improvement — it separates development and build files inside a new folder .next/dev. This means you can safely run next dev and next build together without breaking your local server. In this blog, we’ll cover the problem, what changed, a hands-on demo, and a quick recap — all in simple terms. Before Next.js 16, both next dev and next build wrote data inside the same .next folder. This caused a problem — when you built your app \(next build\) while the dev server was running, the build would overwrite files that your server was using. That often crashed the app or broke your local environment. .next/ ├── cache/ ├── server/ ├── static/ └── build-manifest.json When next build ran, it modified some of these files — and your next dev session would suddenly break. Not fun! Next.js 16 introduces a clean fix: .next/dev folder. Now, development and build artifacts are stored separately. .next/ ├── cache/ ├── dev/ │ ├── build-manifest.json │ https://lnkd.in/d6Z4nej8

Your Next.js production build might be 20× bigger than necessary. I keep noticing a significant mistake in production deployments that results in unnecessarily large applications. Most developers run next build and then deploy: 1. Their full source code 2. The entire node_modules folder 3. The .next folder Even for a small app, this can lead to over 200 MB bloating on your server. A better approach is to enable the standalone build in your next.config.js with one simple setting: ```javascript // next.config.js module.exports = { output: 'standalone' } ``` This change will: 1. Tree-shake unused code 2. Bundle only what's actually used 3. Produce a .next/standalone folder that is typically just 5-10 MB, depending on your libraries No need to upload the full node_modules. Just deploy the .next/standalone folder to your server for impressive results, including: - Dramatically smaller deployments - Lightning-fast startup times - Clean servers Have you tried standalone builds with Next.js? Share your experience in the comments Follow Asif Ali Quraishi ♞

🚀 New article published! This week, I dove into one of Go’s most powerful built-in tools — the net/http package — and wrote about how to build a simple RESTful API in Go using nothing but the standard library. In the article, I break down: How routing works with http.NewServeMux RESTful principles and endpoint design Using in-memory storage for quick prototyping Managing concurrency safely with sync.Mutex This project helped me understand the foundations of backend development in Go — without relying on any frameworks. If you’re starting your own Go journey or just curious about how Go handles web servers, check it out here 👇 📝 Read: https://lnkd.in/dFiZgZ5p 📂 My repo with all Go projects: https://lnkd.in/dnKBjdNF Let’s keep learning and building in public 💪 #Golang #BackendDevelopment #RESTAPI #LearningInPublic #MLOps #OpenSource

🚀 From Circular Dependency to Smooth Google OAuth2 + JWT Integration in LifeSpring Ever faced a circular dependency nightmare in Spring Boot? 😵 That’s what I ran into while implementing Google login + JWT auth in my project LifeSpring. Here’s how the journey went 👇 1️⃣ Circular Dependency ⚡GoogleOAuth2SuccessHandler needed UserService. ⚡AuthController also needed UserService. ⚡Result → Spring threw a cycle error. 2️⃣ The Fix 🪄 ⚡Used @Lazy on the dependency: @Autowired @Lazy private UserService userService; ✅ App started smoothly, cycle broken. 3️⃣ Handling Google Login Success 🔑 I needed JWT + user info + refresh token in a JSON response. Controller didn’t work (redirect issues). So I moved the response to onAuthenticationSuccess using ObjectMapper. Now → Client gets JWT + user info + refresh token directly 🎉 4️⃣ Key Lessons 📚 ⚡@Lazy fixes cycles, but refactor if possible. ⚡OAuth2 login can skip controllers, so success handlers are powerful. ⚡Always test with multiple Google accounts for hidden bugs. 💡 Takeaway: Spring Boot can frustrate you, but every roadblock deepens your understanding of dependency injection. 👉 Have you ever faced a circular dependency in Spring Boot? How did you solve it—@Lazy or refactoring? #SpringBoot #OAuth2 #JWT #DevCommunity #LifeSpring #100DaysOfCode #JavaDeveloper