--- title: "A little progressive enhancement as a treat" url: https://daily.dev/posts/a-little-progressive-enhancement-as-a-treat-59ffmw2u5 source_url: https://piccalil.li/projects/personal-site/9 type: article source: "Piccalilli" published: 2026-08-13T12:14:41.671Z updated: 2026-08-13T12:15:36.734Z tags: ["architecture", "astro", "web-components"] reading_time: 11 upvotes: 1 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # A little progressive enhancement as a treat **[Piccalilli](https://daily.dev/sources/piccalilli)** · 11 min read · 1 upvotes · 0 comments ## Summary A personal music-collection site adds streaming platform links (Spotify, Apple Music, Bandcamp, etc.) to album pages by querying the MusicBrainz API. Because build-time queries would hit rate limits for 491 collection items, the data fetch happens client-side via a same-origin Astro API route, with results cached in memory for an hour. A custom web component progressively enhances a static list of Last.fm and Open Scrobbler links, appending the extra platform links only when JavaScript and the API call succeed, so the page still works without JS. The piece also briefly covers building near-identical Astro listing pages (like an all-time top 10) by filtering and sorting a content collection. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How can I avoid hitting the MusicBrainz API rate limit when generating links for hundreds of items at build time? Query the MusicBrainz API at request time instead of build time, using a per-visit fetch through a same-origin server API route rather than iterating every item during the build. Results can be cached in memory for an hour with a cache key based on artist and album to reduce repeated calls, avoiding the rate limiting MusicBrainz enforces on bulk build-time requests. _Developers wiring third-party APIs into static sites can find similar rate-limit workarounds on daily.dev._ ### How do I build a web component that progressively enhances a static list of links using data from an API? Render a static HTML list containing links that are always available (like Last.fm and Open Scrobbler), then define a custom element whose connectedCallback fetches additional data from an API route and appends new list items only if the fetch succeeds and returns data. This keeps the page functional without JavaScript while enhancing it when scripts and data are both available. _Anyone shipping resilient, JS-optional UI patterns can track more progressive enhancement techniques on daily.dev._ ### Why should an internal Astro API route check the request origin before responding? Checking that the request origin or referer matches the site's own origin prevents the endpoint from being used as an open public API, which matters because unrestricted endpoints attract unwanted traffic from bots, scrapers, and LLM-based agents. Returning a 403 for mismatched origins keeps the route usable only by the site's own web component. _Teams hardening internal API routes against scraper and agent traffic can follow similar patterns via daily.dev._ ## Similar posts on daily.dev - [Getting started with implementing my music collection](https://daily.dev/posts/getting-started-with-implementing-my-music-collection-55gzic2e2) · Piccalilli · 0 upvotes · 1 comments - [Spotify’s API Isn’t What It Used to Be, Here’s the Alternative I’m Using](https://daily.dev/posts/spotify-s-api-isn-t-what-it-used-to-be-here-s-the-alternative-i-m-using-ryshvlmhs) · Medium · 0 upvotes · 0 comments --- Tags: [#architecture](https://daily.dev/tags/architecture), [#astro](https://daily.dev/tags/astro), [#web-components](https://daily.dev/tags/web-components) [View this post on daily.dev](https://daily.dev/posts/a-little-progressive-enhancement-as-a-treat-59ffmw2u5)