COINPULSE

What it is, and what it is not

Three pages. The home page shows Bitcoin on a candlestick chart with a table of trending coins beside it and the top categories underneath — which sector is up, which coins led it. A second page lists every coin, ranked and paginated. The third is one coin in detail: price today and over thirty days, a chart you can switch between a day and a year, a currency converter, and the numbers that describe it — market cap, rank, volume.

It is worth saying plainly what this does not have, because the interesting part is not where you would look for it. There is no login, no database, no writes, no test suite. It reads a public API and shows you what came back. Nobody's data is in it and nothing can be broken by using it.

So the work is not in the domain, it is in the plumbing: how the data is fetched, what is cached and for how long, what happens when one endpoint is slow, and what happens when one fails. That is what the rest of this page is about.

What I did

Every request to the market API goes through one function. It is a server-only module holding a single generic fetcher, typed by the caller, and nothing else in the app talks to the API directly. That is what keeps the key out of the browser — there is exactly one place it could leak from, and it never runs there.

The key is on a demo tier with a rate limit, which decides the caching. Each fetch declares how long its answer stays good for, so the dashboard is live-ish rather than live: fresh enough that the numbers mean something, cheap enough that a visitor does not cost a call. The configuration is checked when the module loads rather than when a request arrives, so a missing key stops the app at startup instead of failing halfway through somebody's page.

The home page streams. Each section fetches its own data behind its own boundary with its own skeleton, so the trending table can be on screen while the categories are still in flight. One slow endpoint delays its own section and nothing else. On the coin page the two calls it needs — the coin and its price history — go out together rather than one after the other.

The things that can go wrong are handled where they happen. The pool lookup has two routes to the same answer and takes the second when the first has nothing to work with, and returns a fallback rather than throwing if neither works: a missing panel is a worse page, an exception is no page. Pagination lives in the URL, so a page of the list can be linked, shared and survive a refresh.