Running a periodic eligibility check across thousands of members involves some interesting tradeoffs: batching API calls, building O(n) lookup maps, and handling failures without crashing the whole task.
A contract state decision that started as nested conditionals turned into something that looks a lot like Redux. Here's why that pattern works well beyond the frontend.
Building a Ruby client for the Mindbody API involves more quirks than their documentation suggests. Duplicate clients, phantom contract records, CamelCase everywhere, and a fake credit card to complete a $0 purchase.
Most Rack::Attack tutorials assume you have Redis. I didn't want Redis. Here's how I wired it up with Solid Cache instead, and the one boot-order gotcha that tripped me up.
A pattern for making background jobs observable: track each attempt as a DB record with status, payload, and email alerts — no external monitoring service required.
A gym's membership migration kept failing intermittently. Here's the three-layer approach that made the integration actually reliable.
A stored token is not the same thing as a live session. This React app restored auth state by reading a token from localStorage, verifying it against the Rails API, and rebuilding the UI from that response.
The harder part of a search UI is not rendering results. It is keeping search terms, filters, pagination, and list updates from drifting out of sync. This React app used Redux thunks to keep those pieces moving together.
Scraped school data changes from page to page. I used PostgreSQL jsonb in a Rails API so the app could store uneven school details without constant schema changes, while keeping the response format simple for the frontend.
A fixed form is straightforward. A UI that lets people edit unknown key-value pairs is not. This React app sat on top of a schema-flexible Rails API, and the hard part was managing state while the shape of the data kept changing.