InStock

Building an accessible custom dropdown input.

I built a custom dropdown input from scratch that supports screen readers, keyboard navigation, and intuitive focus management.

Each option uses role='radio', aria-checked, and tabIndex='0' to communicate state to screen readers, while keyboard events handle navigation and selection.

To support keyboard navigation, I manage focus with a handler that responds to ArrowUp, ArrowDown, and Escape.

This was my first deep dive into accessibility, and it gave me a stronger appreciation for the work that goes into building inclusive UI components.

Formatting the phone number while a user types.

Continuing with the theme of custom inputs, I also built a phone number field that formats the value in real time as the user types.

Everything was working smoothly until I ran into an issue when editing a number in the middle of the input. Because controlled inputs re-render on each keystroke, the cursor kept jumping to the end of the string which is not ideal.

To fix this, I wrote a function to save the cursor position for each keystroke, then used useLayoutEffect to restore the selection position immediately after each update.

This ended up being one of those deceptively simple features that taught me how much thought it takes to get small UX details feeling smooth and intuitive.

Building a scalable backend.

I built the backend based on provided API specs by setting up routes, request handlers, and database queries to match the defined structure.

To keep things organized, I followed an MVC style pattern: routes handle incoming requests and pass them to controllers, which manage the business logic and communicate with models. The models run raw SQL queries directly against the database. This setup helped me get a clearer sense of how data flows through the app and where different responsibilities should live.

Centralizing error handling and implementing logging with Winston.

To make the backend feel more 'production-ready', I added centralized error handling middleware and integrated Winston for logging.

Since both were new to me, I spent some time digging into the docs to understand how they work and what problems they solve. The errorHandler middleware now catches errors across the app, and either logs information or returns user-friendly messages, depending on the environment.

Adding logging was a great experience and even helped me optimize my frontend API calls. While testing, I noticed frontend API calls we being triggered (even when the first one failed). Thinking this was odd, I looked into what was happening and cleaned up the logic so the second call only fired if the first one succeeded. Catching that in the logs helped me spot and fix a bug I might’ve missed otherwise!

Keeping the database clean with scheduled reseeds.

In an attempt to keep the demo data clean, I set up a scheduled reseed that runs every three days using node-cron.

Setting this up led me to explore how database connections are managed across scheduled scripts and the main application, which gave me a deeper understanding how of background tasks interact with a live system.

After deployment, I made a small update to account for server sleep behaviour by adding a startup check: if the last reseed was over 24 hours ago, the database refreshes automatically when the server wakes up.

Protecting the API with rate limiting

To protect the API from abuse, I added rate-limiting that allows 20 write operations per IP every 15 minutes. This helps protect the demo site from being flooded with requests without requiring users to sign in.

GET requests are excluded from this limit so users can explore freely.