MoreRSS

site iconThe Practical DeveloperModify

A constructive and inclusive social network for software developers.
Please copy the RSS to your reader, or quickly subscribe to:

Inoreader Feedly Follow Feedbin Local Reader

Rss preview of Blog of The Practical Developer

Who Am I & What Do I Do? A Journey into Serverless Architecture & Full-Stack Engineering 🚀

2026-01-28 12:49:33

👋 Hello World!

If you're reading this, you've likely stumbled upon my corner of the internet. Let's skip the small talk and get straight to the core questions: Who am I? and What do I do?

I'm Abhay Prajapati, and I build the internet—specifically, the parts of it that don't crash when they go viral.

👨‍💻 Who Am I?

I am a Full-Stack Developer and Serverless Architect based in Surat, India.

But beyond the titles, I’m a problem solver. I don't just write code; I architect systems. My journey wasn't linear—it was a relentless pursuit of efficient, scalable, and cost-effective solutions. I realized early on that "it works on my machine" isn't good enough. It has to work for thousands of users, concurrently, without breaking the bank.

That realization led me down the rabbit hole of Cloud-Native Technologies and Serverless Architecture, and I haven't looked back since.

👉 See my work: abhay-prajapati.vercel.app

🛠 What Do I Do?

I bridge the gap between complex backend infrastructure and stunning frontend user experiences. My expertise lies in three core pillars:

1. ☁️ Serverless Architecture

I design systems where you don't pay for idle time. Using AWS Lambda, API Gateway, and DynamoDB, I build backends that are:

  • Infinitely Scalable: Handle 10 users or 10,000 without lifting a finger.
  • Cost-Optimized: Zero server management, zero wasted resources.
  • Event-Driven: Real-time processing that reacts to users instantly.

2. ⚛️ Modern Frontend Engineering

I don't just make things work; I make them feel instant. Using Next.js, React, and Tailwind CSS, I craft interfaces that are:

  • SEO-Ready: Ranking high on Google matters.
  • Accessible: Built for everyone.
  • Beautiful: Because aesthetics build trust.

3. 🚀 Full-Stack Innovation

I connect the dots. From setting up CI/CD pipelines to optimizing database queries, I handle the full lifecycle of application development. I treat infrastructure as code (IaC) and performance as a feature, not an afterthought.

🧩 My Philosophy

"Code is not just about instructions for machines; it's about solving human problems with elegance and efficiency."

I believe in:

  • Simplicity over Complexity: If you can't explain it simply, you don't understand it well enough.
  • User-Centricity: A powerful backend is useless if the frontend is frustrating.
  • Continuous Learning: The tech world moves fast. I move faster.

� What's Next?

I am currently working on scaling open-source tools and helping businesses transition to serverless infrastructures.

My goal is simple: To build software that empowers people and businesses to do more with less.

If you are looking for someone to:

  • Architect a scalable SaaS platform.
  • Optimize your existing cloud infrastructure.
  • Build a high-performance web application from scratch.

...then we should talk.

🤝 Let's Connect

I share my learnings, code snippets, and thoughts on the future of tech right here and on my social channels.

Thanks for reading! If you resonate with the serverless mindset or just want to say hi, drop a comment below! 👇

Published via Abhay's Portfolio

I’m building a small tool to help people understand relationship misunderstandings

2026-01-28 12:49:30

Hi DEV 👋

I’m currently building a small side project called DecodeYou.

The idea came from personal experience.
I’ve been in a long-distance relationship, and even when both people care a lot,
misunderstandings still happen — not because of bad intentions,
but because we interpret situations differently.

For example:
the same action can feel “reasonable” to one person,
and deeply hurtful to the other.

Instead of giving advice or labeling people,
DecodeYou focuses on helping users:

  • reflect before reacting
  • notice emotional and communication patterns
  • separate what actually happened from what we assumed it meant

Right now the project is very early.
I’ve open-sourced the repo to document the ideas and structure as I build.

👉 GitHub repo: https://github.com/cherryyan1987/cherryyan1987

I’d really appreciate any feedback, thoughts, or even skepticism.
Happy to learn from this community.

I built a global GLP-1 telehealth directory (and why it’s harder than it looks)

2026-01-28 12:45:09

GLP-1 medications (like semaglutide and tirzepatide) have exploded in demand, but finding legitimate, accessible telehealth providers is still surprisingly hard — especially outside the US.

So I built GLP-1 Patches, a global directory of GLP-1 telehealth providers.

What problem I was trying to solve

Most existing resources are:

  • US-only
  • SEO farms or affiliate-heavy
  • Opaque about pricing, prescriptions, or regions served

If you’re not in the US (or you’re comparing options), the information gap is huge.

What the directory includes

  • Telehealth providers offering GLP-1 medications
  • Regions served (US / international)
  • Prescription model (subscription vs one-time)
  • Transparency around eligibility and process

No prescriptions. No medical advice. Just structured, comparable information.

The hard parts (that I underestimated)

  • Regulatory differences across countries
  • Providers changing terms quietly
  • Avoiding becoming an affiliate spam site
  • Balancing “useful” vs “compliance-safe” content

Health + software is a very different beast.

Current state

The project is still early, but already useful for:

  • Users comparing GLP-1 access options
  • Builders researching the space
  • Anyone trying to understand how fragmented this market is

👉 Website: https://glp-1patches.org

Feedback welcome

If you’re building in healthtech, telemedicine, or regulated markets, I’d love feedback:

  • What would make this genuinely useful?
  • What would you absolutely avoid adding?
  • Any red flags you see immediately?

I got tired of spammy PDF Editing sites, so I built a simpler one

2026-01-28 12:44:17

Finding PDFs online is unnecessarily painful.

Most sites:
– overload ads
– hide real download buttons
– force signups

I didn’t want to “disrupt” anything.
I just wanted a place where PDFs are accessible without friction.

So I built PDFHubs.

Key decisions I made:
– No forced accounts
– No misleading UI
– Focus on usefulness, not clicks

Still early, still improving.

If you’ve dealt with the same problem, I’d appreciate honest feedback:
https://pdfhubs.site

Symfony UX: Single Directory Components (SDC) - The Path to Cleaner Architecture Without Tailwind

2026-01-28 12:39:00

Frontend development in Symfony has taken a huge leap forward in recent years. Thanks to Symfony UX and Twig Components, we've gained the ability to write reusable components much like in React or Vue. However, the more components you have, the more you encounter one annoying problem: files are scattered across the entire project.

A PHP class in src/Components, a Twig template in templates/components, CSS in assets/styles, and JavaScript somewhere else entirely. When you want to change the color of a button, you're looking at a trip through four different directories.

Some time ago, Hugo Alliaume published a great article A Better Architecture for Your Symfony UX Twig Components, where he proposed the concept of Single Directory Components (SDC). The idea is simple: let's have everything in one folder.

Today, we'll show you how to take this concept to the next level, completely get rid of manual configuration, and maybe even Tailwind.

Why Single Directory Components (SDC)?

If you've ever worked with Angular or Vue, you know that feeling of order. An Alert component is a single folder containing everything essential.

In the SDC approach, it looks like this:

src_component/
└── UI/
    └── Button/
        ├── Button.php           # Logic
        ├── Button.html.twig     # Template
        ├── Button.css           # Styles
        └── Button_controller.js # Interactions (Stimulus)

Main Advantages:

  1. Maintainability: When you no longer need a component, you just delete one folder.
  2. Developer Experience: No context switching between distant folders.
  3. Isolation: Styles and scripts belong only to that one component.

Is Tailwind Passé? The Power of Native CSS and Variables

Lately, there's more and more talk about how, with the arrival of modern CSS features (like CSS variables, nesting, @layer), the need for utility frameworks like Tailwind is decreasing. Articles like The Power of CSS Variables remind us that pure CSS is stronger today than ever before.

The SDC approach plays right into this trend. When you have a CSS file right next to your PHP class, you don't need to write 20 Tailwind classes in your HTML. You can define clean, semantic CSS that uses CSS variables linked directly to PHP logic.

Our Solution: UX SDC Bundle

Hugo's article showed how to set up SDC manually. However, it requires changes to composer.json, Twig configuration, AssetMapper, and Stimulus.

Our bundle tito10047/ux-sdc does it for you. It's a Zero Configuration solution. Just install the bundle and mark the class with an attribute.

#[AsSdcComponent('UI:Button')]
class Button {
    // The bundle automatically finds Button.html.twig, Button.css, and Button_controller.js
}

The "Magic" Inside (Without Performance Loss)

The bundle solves technical challenges that you would have to patch yourself with a manual approach:

  • Asset Orchestration: CSS and JS files are injected into the page only when the component is actually rendered.
  • No More "Phantom" Controllers: You don't have to create an empty Stimulus controller just so AssetMapper knows about your CSS. The bundle handles it for you.
  • HTTP Preload & FOUC: We automatically generate Link headers for HTTP preload. The browser starts downloading CSS even before it starts parsing HTML. This eliminates the annoying flash of unstyled content (FOUC).
  • Production Performance: Thanks to a compiler pass, no disk scanning happens in production. Everything is pre-prepared in the cache.

Real-world Example: Project "Formalitka"

What does it look like in the real world? Take a look at the project formalitka.mostka.sk. The entire UI kit is built on SDC without a single line of Tailwind.

Let's take their Button component. The PHP class defines properties like color or size. The CSS then processes these properties using variables:

/* Button.css */
@layer components {
    .button {
        background: var(--color-primary);
        color: var(--color-on-primary);
        transition: var(--transition);

        &.button--secondary {
            background: var(--color-secondary);
        }
    }
}

Thanks to SDC, this complex component (containing seal animations, sounds, and special effects) is contained within one directory and is easy to maintain.

How to Get Started?

Installation is lightning fast:

composer require tito10047/ux-sdc

Register the bundle and in config/packages/ux_sdc.yaml, set where your components reside:

ux_sdc:
    ux_components_dir: '%kernel.project_dir%/src_component'
    component_namespace: 'App\Component'

And add the asset placeholder to your base.html.twig:

<head>
    {{ render_component_assets() }}
</head>

That's it. From this moment on, just create directories and write code.

Performance Under the Microscope: Proof Instead of Promises

When automation and "magic" come into play, the question often arises: What about performance? We put the SDC approach to a stress test with 500 unique components. Here are the key findings from our benchmarks:

Scenario Classic Approach SDC Approach Difference
Warmup (Prod) 583.1 ms 586.2 ms +3.1 ms
Render (Prod Runtime) 26.5 ms 31.6 ms +5.1 ms
Render (Dev Runtime) 26.5 ms 88.4 ms +61.9 ms

What does this mean in practice?

  • In production, the overhead is almost zero. Thanks to the compiler pass, no disk scanning happens at runtime. Rendering a single component has an overhead of only about 8.8µs, a negligible price for fully automated asset and Stimulus management.
  • Dev mode is optimized for DX. Instead of having to clear the cache every time a file changes, the bundle in dev mode uses runtime autodiscovery. It scans the disk only for those components that are currently being rendered. This means that if you add a new CSS file or change a Twig template, you see the changes immediately. Thanks to internal metadata caching within a single request, repeated rendering of the same component remains very fast.
  • Memory Footprint: With 500 components, the bundle consumes about 8MB more memory during container compilation, which is perfectly fine for modern applications.

You can find the full report in our benchmark.md.

The Future and Your Feedback (Version 0.0.1)

This bundle is currently in version 0.0.1. It's an early stage where we're looking for the right path. I wrote this article not only to share our solution but mainly to get feedback from you, the community.

We're interested in:

  • What do you think about the proposed API?
  • Is there anything missing that you would expect in an SDC approach?
  • Do you see any pitfalls in this approach that we've overlooked?

We want this bundle to be built on solid foundations and real developer needs from the first stable version. Every GitHub issue, discussion, or comment moves us forward.

Conclusion

Single Directory Components combined with modern CSS are changing the way we think about Symfony UX. We're getting rid of unnecessary boilerplate code, cleaning up our project structure, and increasing our performance as developers.

Try the UX SDC Bundle and say goodbye to scattered files. The future of Symfony UX is in order and clarity.

Snapping Visualization Enhancement

2026-01-28 12:28:11

Overview

Enhanced the shape snapping system with prominent glowing visual guides that clearly show when and where shapes snap to canvas edges, canvas center, or other shapes.

What Was Enhanced

Previous State

  • Snapping guides were extremely subtle (1px lines)
  • Minimal glow effect (4px shadow)
  • Low opacity (0.8)
  • Hard to see during editing

Enhanced State

  • Prominent guide lines: 2-3px thick (yellow guides are 3px, orange are 2px)
  • Multi-layer glow effect: Triple-shadow system creates strong luminous appearance
  • Full opacity: Lines are now completely visible (opacity: 1)
  • Pulsing animation: Smooth breathing effect that draws attention without being distracting

Visual Feedback System

Color Coding

Yellow Guides (#FFD700)

Used for center alignment snapping:

  • Canvas center (horizontal)
  • Canvas center (vertical)
  • Element center-to-center alignment

Visual Properties:

  • 3px line width
  • Triple glow effect:
    • Inner glow: 12px spread
    • Medium glow: 20px spread
    • Outer glow: 30px spread with transparency

Orange Guides (#FF8C00)

Used for edge snapping:

  • Canvas edges (top, bottom, left, right)
  • Element edges (all sides)
  • Element-to-element edge alignment (stacking and side-by-side)

Visual Properties:

  • 2px line width
  • Double glow effect:
    • Inner glow: 8px spread
    • Outer glow: 16px spread

Animation

Custom pulse animation that:

  • Cycles every 0.8 seconds
  • Smoothly transitions between 100% and 70% opacity
  • Adds brightness variation (1.0 to 1.3x)
  • Creates a subtle "breathing" effect that catches the eye

Snapping Behavior

Canvas Snapping

The system automatically detects and shows guides when shapes align with:

  1. Canvas Center

    • Horizontal center line (yellow, vertical guide)
    • Vertical center line (yellow, horizontal guide)
    • Shows when shape center aligns with canvas center
  2. Canvas Edges

    • Top edge (orange, horizontal guide)
    • Bottom edge (orange, horizontal guide)
    • Left edge (orange, vertical guide)
    • Right edge (orange, vertical guide)

Element-to-Element Snapping

Shows guides when shapes align with other shapes:

  1. Edge Alignment

    • Left-to-left
    • Right-to-right
    • Top-to-top
    • Bottom-to-bottom
  2. Stacking

    • Top edge to bottom edge (vertical stacking)
    • Bottom edge to top edge (vertical stacking)
  3. Side-by-Side

    • Left edge to right edge (horizontal placement)
    • Right edge to left edge (horizontal placement)
  4. Center Alignment

    • Center X-to-center X (yellow, vertical guide)
    • Center Y-to-center Y (yellow, horizontal guide)

Technical Implementation

Files Modified

/src/components/design-tool/SnapGuides.tsx

  • Enhanced line thickness (1px → 2-3px)
  • Implemented multi-layer glow effects
  • Added custom pulse animation
  • Differentiated between yellow and orange guides
  • Increased opacity to maximum visibility

Key Features

  1. Adaptive Line Width
   const lineWidth = isYellowGuide ? 3 : 2;

Yellow center guides are slightly thicker to emphasize importance

  1. Layered Glow Effect
   boxShadow: `0 0 12px 3px color, 0 0 20px 6px color, 0 0 30px 9px rgba(..., 0.3)`

Creates deep, luminous glow that's visible against any background

  1. Smooth Animation
   @keyframes snapPulse {
     0%, 100% { opacity: 1; filter: brightness(1); }
     50% { opacity: 0.7; filter: brightness(1.3); }
   }

Breathing effect that maintains visibility while providing motion feedback

  1. Precise Positioning
    • Lines are centered on snap points using transform
    • translateX(-${lineWidth/2}px) for vertical guides
    • translateY(-${lineWidth/2}px) for horizontal guides

User Experience

When Snapping Occurs

  1. User drags a shape near a snap point
  2. Shape automatically aligns when within threshold (8px / zoom)
  3. Glowing guide line appears instantly
  4. Guide pulses gently to confirm snapping
  5. Guide disappears when drag ends or shape moves away

Visual Clarity

  • High contrast: Bright colors stand out against dark canvas
  • Motion feedback: Pulsing animation confirms active snapping
  • Color meaning: Yellow = center alignment, Orange = edge alignment
  • Non-intrusive: Guides are semi-transparent and positioned behind elements

Snap Threshold

  • Default: 8 pixels
  • Zoom-adjusted: SNAP_THRESHOLD / zoom
  • Ensures consistent snap feel regardless of zoom level

Performance Considerations

  • Guides render only when actively snapping
  • Minimal DOM elements (one div per active guide)
  • CSS animations (hardware accelerated)
  • Automatic cleanup when snapping ends

Usage Tips for Users

  1. Enable Snapping: Use the magnet icon in toolbar or press Ctrl + ;
  2. Drag Shapes: Move shapes near edges or centers to see guides
  3. Color Meaning:
    • Yellow = You're at the center of something
    • Orange = You're at an edge
  4. Multiple Guides: Can snap horizontally and vertically simultaneously
  5. Disable When Needed: Toggle snapping off for free-form placement

Future Enhancement Possibilities

  1. Distance indicators showing pixel spacing
  2. Snap strength visualization
  3. Custom snap point creation
  4. Snap-to-grid visualization
  5. Keyboard modifier for temporary snap disable
  6. Snap sound effects