Lohnt sich dein eigenes HikerAPI?

Build a local, single-user Instagram data service in an empty folder. Stack: Python 3.11, FastAPI, uvicorn, instagrapi, SQLite via sqlite3 (no ORM), httpx only if needed.

Goal: a small REST API on localhost that returns Instagram profile, media, and follower data for personal research, with heavy caching so I never fetch the same thing twice.

Endpoints:
- GET /user/{username} : profile info (id, full name, bio, counts, is_private, profile pic url)
- GET /user/{username}/media?limit=N : recent posts (id, code, caption, like/comment counts, taken_at, media urls)
- GET /user/{username}/followers?limit=N : follower list, capped at 200 per call
- GET /hashtag/{tag}/top : top media for a hashtag
- GET /cache/stats : row counts and cache hit counters

Rules:
- Credentials and proxy come from .env: IG_USERNAME, IG_PASSWORD, IG_PROXY. Ship a .env.example, never commit secrets.
- Persist the instagrapi session to session.json and reuse it on boot. Only re-login if the session is dead.
- One global request queue with a single worker. Sleep a random 4 to 12 seconds between platform calls. No concurrency, ever.
- Cache every response in SQLite keyed by endpoint plus params, with a fetched_at timestamp and a TTL of 24 hours for profiles and 6 hours for media. Serve cache on hit and mark the response with a "cached": true field.
- On login challenge, 429, or ChallengeRequired, return HTTP 503 with a clear message telling me to log in manually in a browser on the same proxy. Do not retry in a loop.
- Log every platform call to a requests table so I can see exactly how much I hammered them.

Out of scope: no posting, liking, following, or DMs. No web UI beyond FastAPI's built-in docs. No account rotation, no proxy pool, no cloud deploy, no telemetry.

Deliverables: main.py, db.py, client.py, .env.example, requirements.txt, and a README that says plainly that this account will probably get banned and that the TTLs and sleeps are the only thing keeping it alive.