DEV Community: Aarush Karak

A One-Command Pre-Flight Checklist for Developers: astro-tasks

Aarush Karak — Sat, 19 Sep 2026 01:24:36 +0000

Before starting work I used to open three tabs: GitHub notifications, the WakaTime dashboard, and a git status sweep across local repos. I built astro-tasks to put that in one terminal command.

pip install astro-tasks
astro check

That's GitHub notifications + open PRs (via the gh CLI), coding stats for the last 7 days (total, daily average, top projects, languages via WakaTime), and a local repo health scan (branch, dirty state, unpushed commits).

Subcommands cover the subsets: astro scan for repos only, astro log for coding stats, astro config for configuration. astro check --json emits the same data as machine-readable JSON, so you can pipe it into other tools.

Caveats, stated honestly: it shells out to gh, so you need gh auth login, and coding stats need a WakaTime config at ~/.wakatime.cfg. Python 3.8+, MIT licensed.

Repo: https://github.com/3ni8ma/astro-tasks — feedback welcome, especially on the JSON schema and multi-machine WakaTime setups.

I Ship Mobile Apps for $0: Vercel + Render + Supabase Free Tier

Aarush Karak — Sat, 12 Sep 2026 19:39:35 +0000

TL;DR: My entire mobile stack costs $0 a month. Expo builds the app. Supabase holds data and auth. Render runs background jobs. Vercel hosts the landing page. Free tiers cover all of it. The table below shows every piece, its limit, and the catch. Steal this setup.

My infrastructure bill is zero dollars. Not "free trial" zero. Not "first year" zero. Actual, ongoing, every-month zero. I ship a real mobile app with real users on free tiers. This post is the full receipt.

People assume shipping an app costs money. Servers. Databases. Auth. Hosting. It sounds like hundreds a month. It is not. The free tiers in 2026 are absurdly generous. You can go from idea to production without touching a credit card. I know because I did.

Here is the whole stack in one table:

Piece	Service	Free tier	The catch
Mobile app	Expo + EAS	Free builds, OTA updates	Build queues get slow at peak hours
Database + Auth	Supabase	500MB Postgres, 50k monthly users	Project pauses after 7 idle days
Background jobs	Render	750 free hours monthly	Spins down after 15 min idle, slow cold start
Landing page	Vercel	100GB bandwidth, auto SSL	Build minutes capped monthly
Code hosting + CI	GitHub	Unlimited public repos, 2000 CI minutes	Private repo minutes burn faster
Publishing pipeline	This repo	$0 forever	You write the posts yourself

Total: $0. Catches: manageable. Let me walk through each one.

Expo first. The app itself. Expo's free tier includes builds and over-the-air updates. OTA updates are the killer feature. I push JavaScript fixes and users get them instantly. No app store review. No waiting three days for Apple to approve a typo fix. Native changes still need a rebuild. JS changes just flow.

The catch: EAS build queues. Free builds wait in line. At peak US hours I have waited twenty minutes for a build to start. My solution is scheduling. I kick off builds before lunch. They are done after lunch. Patience is free too.

Development builds are the move. Build once to your phone. Then iterate over the local network. Fast refresh works. You only hit the queue for release builds. I do maybe three release builds a week. Totally fine on free.

Supabase second. The backend. Postgres database. Auth with GitHub login. Row-level security. Edge functions for webhooks. The free tier gives 500MB of database and 50,000 monthly active users. I have a tiny fraction of that. I could grow a hundred times over and still pay nothing.

The catch: idle projects pause. After seven days with no activity, Supabase parks your project. The next request wakes it up. That wake-up takes a few seconds. Users see one slow load. Then everything is fast.

My fix is simple. A scheduled ping. This very repo has a weekly cron in its GitHub Action. It hits the API on a schedule. The project never idles. The cron was built for publishing posts. It doubles as a keep-alive. Two birds, zero dollars.

Row-level security deserves its own praise. Every query is scoped to the logged-in user at the database level. Not in my code. In Postgres itself. Even if my app code has a bug, users cannot read each other's data. Security enforced below the application layer. Free. Built in. Wonderful.

Render third. Background jobs. The GitHub webhooks arrive. The AI summaries get generated. These run on Render's free tier. 750 hours a month covers one always-small service. The math works out. One service running full-time is about 720 hours. Just under the cap.

The catch: cold starts. Free Render services spin down after fifteen minutes idle. The next request waits while the service boots. Ten to thirty seconds of nothing. For a background job, nobody cares. The webhook arrives, the service yawns awake, the summary generates a few seconds later. No user is watching a spinner.

Do not put user-facing APIs on free Render. That is the rule. Background work only. User-facing reads go straight from the phone to Supabase. That path is always warm. Jobs can be sleepy. Users cannot.

If a job ever needs to be instant, the upgrade is seven dollars. Cheapest paid tier in the stack. I have not needed it yet. When I do, one coffee a month is fine.

Vercel fourth. The landing page and this blog. Static pages deploy from git pushes. SSL included. Global CDN included. 100GB of bandwidth free. My pages are tiny. I could get on the front page of everything and survive.

The catch: build minutes. The free tier caps how long builds can run monthly. Static sites build in under a minute. I deploy maybe ten times a week. I use a fraction of the quota. If you add heavy image processing to builds, watch this number. I keep images pre-sized in the repo instead.

The monorepo trick: my landing page and blog live with the app code. One push deploys the site. Same git history. Same workflow. Fewer dashboards to check. I check enough dashboards already.

GitHub fifth. Code, CI, and project management. Unlimited public repos. 2,000 CI minutes a month on free. My publishing pipeline runs here. A few minutes a week. The budget barely notices.

Everything in this pipeline is public. The app. The site. The publishing scripts. Public repos get full CI minutes and free everything. Keeping the work public is a marketing strategy that pays for its own infrastructure. Funny how that works.

Now the honest section. What breaks. What I worry about. Free tiers are borrowed land. Limits change. Companies get acquired. Generosity shrinks. I have a plan for each piece.

If Supabase tightens free Postgres, my database is plain Postgres. I can dump it and move anywhere. No proprietary queries. No vendor extensions. Standard SQL in, standard SQL out. Portability is the exit strategy.

If Render kills free hours, background jobs move to Supabase Edge Functions. They have their own free allowance. The job code is small and stateless. It runs anywhere that runs JavaScript. Nothing is glued to Render.

If Expo ever paywalls builds, the app is React Native. Ejecting is painful but possible. EAS is convenience, not lock-in. The code is mine. The config is text. I could build locally with Xcode and Android Studio. It would hurt. It would work.

If Vercel caps bandwidth harder, the site is static files. Any host serves static files. Literally any. I could serve them from a free tier anywhere. Moving takes an afternoon.

The principle: own your code and your data, rent the plumbing. Every service here holds nothing irreplaceable. Code lives in git. Data dumps to SQL. Nothing proprietary. I can move any piece in a day. That is what makes free tiers safe to build on.

Cost so far, all time: $0. Users served: real ones. PRs reviewed from a bus: eleven. Regrets: none.

Start free. Stay free until revenue says otherwise. Then spend money on exactly one thing: the bottleneck. Not before. Premature infrastructure is just a hobby that sends invoices.

The demo is live. The repo is public. The pipeline that published this post cost nothing to run. That never gets old.

Follow the ok2merge-build-in-public series — next post Tue/Thu. Star github.com/3ni8ma/ok2merge · Try https://ok2merge.vercel.app

Expo + Supabase GitHub Auth Broke 3 Times — Here's the Fix

Aarush Karak — Sat, 12 Sep 2026 19:38:31 +0000

TL;DR: GitHub login in my Expo app broke three separate times. A deep link that went nowhere. A PKCE flow I wired backwards. A redirect URL with a typo. Each fix is copy-pasteable below. Total auth code is under a hundred lines. Steal it.

Auth is the worst part of every app. Nobody downloads your app for the login screen. They tolerate it. Every minute you spend on OAuth is a minute nobody will ever thank you for. I spent three days on it. Here are all three failures, so you spend thirty minutes.

The setup: Expo app, Supabase backend, GitHub as the login provider. Users tap "Sign in with GitHub." GitHub approves. Supabase mints a session. The app stores it. Standard stuff. Documented stuff. Stuff that still broke three times.

Failure one: the deep link went nowhere.

OAuth on mobile works like this. Your app opens a browser. The user approves on GitHub. GitHub redirects to a URL. That URL must reopen your app. That reopening is the deep link. If the link is wrong, the user approves your app and then stares at a browser tab. Approved. Stranded. Confused.

That is exactly what happened. Login looked successful on GitHub's side. My app sat there waiting. Forever. The approve button worked. The return trip did not exist.

The cause was my redirect URL. In Supabase, you register where OAuth is allowed to return. I registered the web URL of my landing page. On desktop that would be fine. On a phone, the browser does not know your app exists. The session landed on a web page. The app never heard about it.

The fix: use your app scheme as the redirect. My scheme is ok2merge://. So the redirect URL becomes ok2merge://auth/callback. Register that exact string in two places. First, in the Supabase dashboard under Authentication, URL Configuration, Redirect URLs. Second, in your GitHub OAuth app settings as the authorization callback URL. Both must match. Character for character.

In Expo, declare the scheme in your app config:

{
  "expo": {
    "scheme": "ok2merge",
    "ios": { "bundleIdentifier": "app.ok2merge.mobile" },
    "android": { "package": "app.ok2merge.mobile" }
  }
}

Then handle the return with expo-web-browser and expo-linking. Open the OAuth URL in a session. Wait for the redirect. Dismiss the browser when your scheme fires:

import * as WebBrowser from "expo-web-browser";
import * as Linking from "expo-linking";

WebBrowser.maybeCompleteAuthSession();

const redirectTo = Linking.createURL("auth/callback");

const { data } = await supabase.auth.signInWithOAuth({
  provider: "github",
  options: { redirectTo, skipBrowserRedirect: true },
});

if (data?.url) {
  const result = await WebBrowser.openAuthSessionAsync(
    data.url,
    redirectTo
  );
  if (result.type === "success" && result.url) {
    const params = Linking.parse(result.url);
    // exchange the code for a session below
  }
}

The skipBrowserRedirect: true part matters. You want the OAuth URL back as data, not an automatic redirect. You open it yourself in the auth session. That way you control the return.

Failure two: I wired PKCE backwards.

Supabase uses PKCE for mobile OAuth. The short version: your app creates a secret verifier. It sends a challenge derived from it. GitHub holds the challenge. When the callback returns a code, your app sends the code plus the original verifier. Supabase checks they match. This proves the app that started the login is the app that finished it. No stolen codes.

My bug: I generated the verifier, then threw it away. I treated the flow like web OAuth, where the server holds state. On mobile there is no server holding state. There is just your app. I launched the browser, got the code back, and tried to exchange it with no verifier. Supabase said no. Correctly.

The fix is to let the Supabase client own the whole flow. Do not hand-roll the code exchange. When the deep link returns, pull the code param out of the URL and call exchangeCodeForSession:

import { makeRedirectUri } from "expo-auth-session";

const params = new URLSearchParams(result.url.split("?")[1] ?? "");
const code = params.get("code");

if (code) {
  const { error } = await supabase.auth.exchangeCodeForSession(code);
  if (error) throw error;
}

One call. The client kept the verifier in storage from signInWithOAuth. It attaches it automatically. My hand-rolled exchange was the entire bug. Deleting code fixed auth. My favorite kind of fix.

Lesson: never split an OAuth flow across two libraries. One library starts it, the same library finishes it. The moment two libraries share custody of a code verifier, you will lose it. I lost it. In production. In front of a user. That user was me, but still.

Failure three: one dumb redirect URL typo.

After fixing one and two, login worked on my phone. Then I built the Android APK. Login broke again. Same code. Same backend. Different platform, different failure. Classic.

Android needs the redirect registered in its own way. The scheme works, but Android verifies app links against your package name. I had renamed the package halfway through the project. The config said one thing. The Supabase redirect list said another. Off by a suffix. A typo I introduced myself, weeks earlier, that only detonated on Android.

Debugging this took an hour. The fix took ten seconds. Add the exact redirect string to Supabase. Rebuild. Done.

Here is my checklist so you skip all three failures:

One, use your app scheme as the redirect everywhere. yourapp://auth/callback. In Supabase redirect URLs. In the GitHub OAuth app callback. In your code. All three identical.

Two, one library owns the flow. signInWithOAuth starts it. exchangeCodeForSession finishes it. Nothing custom in between except opening the browser.

Three, after renaming anything, grep the whole project for the old name. Package names. Bundle IDs. Schemes. Redirect URLs. Renames are where typos hide. They wait for the worst moment.

Four, test on a real device early. The iOS simulator and Android emulator handle deep links differently from real phones. My failure one passed in the simulator. It failed on hardware. Simulators lie about links. Phones do not.

Here is the full login function, all together, under a hundred lines with imports:

import * as WebBrowser from "expo-web-browser";
import * as Linking from "expo-linking";
import { supabase } from "./supabase";

WebBrowser.maybeCompleteAuthSession();

export async function signInWithGitHub() {
  const redirectTo = Linking.createURL("auth/callback");

  const { data, error } = await supabase.auth.signInWithOAuth({
    provider: "github",
    options: { redirectTo, skipBrowserRedirect: true },
  });
  if (error) throw error;

  const result = await WebBrowser.openAuthSessionAsync(
    data.url,
    redirectTo
  );
  if (result.type !== "success" || !result.url) return null;

  const code = new URLSearchParams(
    result.url.split("?")[1] ?? ""
  ).get("code");
  if (!code) throw new Error("No auth code in callback");

  const { error: exError } =
    await supabase.auth.exchangeCodeForSession(code);
  if (exError) throw exError;
  return true;
}

Sign out is one line. Do not forget to test it. Untested sign-out is how you get a user permanently logged in as someone else on a shared device. Ask me how I know. Actually do not. Moving on.

await supabase.auth.signOut();

Auth broke three times. Each break taught me the same lesson. Mobile OAuth is a chain of exact strings. Scheme. Redirect. Package. Verifier. One wrong character anywhere breaks everything silently. The fix is always the same: line up every string, let one library hold the secrets, test on hardware.

Total auth code: under a hundred lines. Total debugging: three days. Ratio is bad. Hopefully this post fixes your ratio.

Next post in the series: the full $0 stack. Vercel, Render, Supabase free tiers. With a table. Everyone loves a table.

Follow the ok2merge-build-in-public series — next post Tue/Thu. Star github.com/3ni8ma/ok2merge · Try https://ok2merge.vercel.app

I Built a PR Inbox for My Phone So I Stop Being the Bottleneck

Aarush Karak — Sat, 12 Sep 2026 19:38:30 +0000

TL;DR: I was the bottleneck on every pull request. Reviews waited days for me. So I built a PR inbox for my phone. AI summarizes each diff. I swipe right to approve. Built with Expo and Supabase. Costs $0. This is post one of the build-in-public series.

I am the problem. Let me say that first.

Every PR on my projects waited for me. Contributors opened good work. Then silence. For days. Not because the code was bad. Because reviewing code on a laptop feels like homework. And I kept not doing my homework.

The pattern was embarrassing. Someone opens a PR on Monday. I tell myself I will review it after dinner. Dinner becomes a show. The show becomes sleep. Tuesday looks exactly like Monday. By Friday the contributor has moved on with their life. The PR has merge conflicts. Everyone loses.

I tried to fix this with discipline. That lasted four days. Discipline is a terrible dependency. It has no SLA. It goes down on weekends.

So I fixed it with software instead. I built a PR inbox for my phone. The idea is stupidly simple. Your email has an inbox. Your texts have an inbox. Your code reviews deserve one too. Open the app. See every PR waiting on you. Swipe right to approve. Swipe left to request changes. Done from the couch.

The trick is the summary. Nobody wants to read a raw diff on a phone. Raw diffs on a five-inch screen are a punishment. So each PR gets a plain-language summary. What changed. Why it changed. What could break. You read three sentences instead of three hundred lines. Then you decide.

AI writes the summary. You make the call. That division of labor matters to me. The model explains. The human decides. I never wanted auto-merge. Auto-merge is how you deploy a disaster at 2am. I wanted faster understanding, not zero judgment.

Here is how a review goes now. Phone buzzes. New PR from a contributor. I open it while waiting for coffee. The summary says it refactors the auth callback and touches two files. Risk looks low. I glance at the actual diff for the risky hunk. Looks fine. Swipe right. Merged before my coffee is ready.

Total time: ninety seconds. Old way: three days of guilt plus twenty minutes of context-switching. This is not a small improvement. This is a different life.

Let me talk about the stack. Because the stack is the other point of this post. The whole thing costs zero dollars. Expo for the app. Supabase for auth and database. GitHub webhooks for PR events. Vercel for the landing page. Every tier is free. My monthly infrastructure bill is the price of nothing.

Expo gets mocked a lot. I used to mock it. Then I shipped with it. Over-the-air updates alone are worth it. I push a fix and users get it without an app store review. When your QA team is you, that speed is everything.

Supabase handles the boring parts. Auth. Postgres. Row-level security. I did not want to run a server. I have run servers before. They page you at night. Supabase pages someone else. That someone else is not me. Perfect arrangement.

The architecture is boring on purpose. GitHub sends a webhook when a PR opens. A small function stores the PR metadata in Supabase. Another function asks a model to summarize the diff. The phone app reads from Supabase and shows the inbox. Approve or request-changes goes back through the GitHub API. No magic. Just plumbing.

Boring architecture is a feature. Every clever system I have ever built became a second job. This one has been running for weeks. I barely think about it. It just buzzes when someone needs me.

The hardest part was not the code. It was the summary quality. Early summaries were useless. They said things like "this PR modifies code to improve functionality." Thanks. Very helpful. I could have guessed that.

I fixed it with structure. The summarizer now answers four questions. What changed. Why it probably changed. Riskiest hunk. What to check before approving. Forcing that shape killed the vague filler. A summary that names the riskiest file is worth ten generic ones.

The second hardest part was auth. GitHub OAuth on mobile broke three times. That story is its own post. It is literally the next post in this series. Spoiler: deep links, PKCE, and one very dumb redirect URL.

Let me share the numbers. Since I started using the inbox, my median review time went from three days to under four hours. Most of that is still me being slow. The app did its part instantly. I merged eleven PRs from a bus. I merged one from a wedding. Do not tell the bride.

Contributors noticed. One told me reviews got "weirdly fast." That is the best review my review tool ever got. Weirdly fast. I want that on a sticker.

There is a real lesson here. Bottlenecks are usually interface problems. I did not review PRs because the interface for reviewing was a laptop, a quiet room, and forty free minutes. I never have all three at once. The phone interface needs ninety seconds and a couch. Same human. Same brain. Different friction.

Find your friction. That is the whole post, really. Where is the task you keep avoiding? What does it demand from you? A desk? An hour? Silence? Shrink the demand. The motivation was never the problem. The setup cost was.

What is next. The inbox works for my repos. Now I am opening it up. Multi-repo support. Team inboxes. Smarter risk scoring. A demo is live at the link below. Star the repo if you want to follow along. Real code, real bugs, real numbers. Every Tuesday and Thursday.

I built this so I stop being the bottleneck. It worked. Now help me break it in new and interesting ways.

Follow the ok2merge-build-in-public series — next post Tue/Thu. Star github.com/3ni8ma/ok2merge · Try https://ok2merge.vercel.app

Algorithmic Trading Signals: From Indicators to Backtests

Aarush Karak — Tue, 08 Sep 2026 16:51:48 +0000

The Signal Vocabulary

The core indicators: RSI (14-period, 70/30 thresholds) for momentum exhaustion, MACD (12/26/9) for trend shifts, and moving-average crossovers for regime changes. Each is a lagging function of price — the signal fires after the move starts. Combining uncorrelated signals is the start of an edge; stacking correlated ones is just noise.

Signal Construction, Not Indicator Collection

A strategy is a decision rule: entry conditions, exit conditions, position sizing. The discipline: define signals as boolean predicates over indicator state, and define exits as first-class (stop-loss, take-profit, time-based) rather than as afterthoughts. A strategy without explicit exits is a strategy without risk control.

Backtesting Without Lying to Yourself

The backtest mechanics that matter: no lookahead (indicators must use only data available at decision time), realistic slippage and fees, and bar-close execution instead of magic fills. The classic failure: a backtest that assumes you bought at the intraday low — every strategy wins on paper with hindsight fills.

Overfitting and the Parameter Lottery

Grid-searching 200 parameter combinations on one ticker and reporting the best produces a strategy optimized for history, not markets. The guardrails: walk-forward validation (rolling train/test windows), out-of-sample holdouts, and parameter stability — a strategy whose edge vanishes when RSI(12) becomes RSI(14) has no edge.

From Backtest to Paper Trading

The gap between backtest and live is regime change. Paper trading the strategy against live data for weeks reveals execution reality: fills, latency, data gaps. The promotion criteria: paper performance within a tolerance of backtest expectations, and behavior in a down-market window.

The Honest Limits

Retail quant trading is a statistics exercise against professionals with better data and execution. The realistic goals: disciplined exits, systematic entries, and risk management that caps losses — an edge that compounds slowly beats a lottery ticket. Treat the strategy as a system to operate, not a prediction to trust.

NOTE: The bank-driven fallback wrote this post because the LLM proxy was unreachable — structure and facts come from the topic outline, and the next regeneration will enrich it.

Key Takeaways

The Signal Vocabulary
Signal Construction, Not Indicator Collection
Backtesting Without Lying to Yourself
Overfitting and the Parameter Lottery
From Backtest to Paper Trading
The Honest Limits

FAQ

Q: What is the key idea in the signal vocabulary?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Q: What is the key idea in signal construction, not indicator collection?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Q: What is the key idea in backtesting without lying to yourself?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Conclusion

A trading signal is only as good as the discipline around it: explicit exits, honest backtests, walk-forward validation, and paper trading before capital. The system — not the indicator — is the product, and its edge must survive the test of time out of sample.

View the project on GitHub

I Built a Microservice in 10 Minutes with GoFr (and Didn't Touch YAML)

Aarush Karak — Sat, 05 Sep 2026 20:36:59 +0000

I've built enough Express and Flask APIs to know the drill: router, DB client, logger, metrics, health endpoint, Dockerfile, then three hours of glue. I wanted to see if Go's GoFr framework actually removes that.

Short answer: mostly yes.

What is GoFr?

GoFr (https://gofr.dev) is an opinionated microservice framework for Go. CNCF-listed, 20k+ stars. The pitch: REST standards by default, config management, auth middleware, DB migrations, cron, websockets, Swagger, plus logs/traces/metrics out of the box. K8s-first thinking.

I liked that it doesn't try to be minimal. It tries to be complete.

Hello World in 5 lines

Prereq: Go 1.24+.

go get -u gofr.dev/pkg/gofr

main.go:

package main
import "gofr.dev/pkg/gofr"
func main() {
  app := gofr.New()
  app.GET("/greet", func(ctx *gofr.Context) (any, error) {
    return "Hello World!", nil
  })
  app.Run() // localhost:8000
}

go run main.go, open localhost:8000/greet. Done. No router setup, no server boilerplate.

What surprised me: observability

Terminal logs are pretty-printed with units. JSON logs have the same fields but no time unit on response_time — I hit exactly what issue #2480 discusses. Metrics buckets cap at 30s, so anything above shows as 30s. It's a small papercut, but it shows the project cares about log parity.

Health checks for datasources, built-in tracing, and Swagger rendering are all one-liners in the docs. I didn't need Prometheus client code for basic RED metrics.

What's next: porting my real project

I maintain astro-tasks — a Python CLI dev dashboard on PyPI with GitHub CLI integration and git health checks — and Finance-Hub (live market monitoring + AI predictions).

Both currently poll APIs on a loop and I hand-roll logging. Next step: port Finance-Hub's market poller to GoFr:

GET /markets with built-in observability instead of my Python logger
GoFr cron for the polling interval instead of while True + sleep
Health check for the data source instead of my custom check

Same for my Rust static file server in rust-projects — GoFr's abstracted file systems + Swagger would kill half that code.

If you're a Python/TS dev curious about Go, GoFr is the lowest-friction entry I've found. No YAML hell, just code.

What would you build? I'm thinking URL shortener next.

Built with GoFr, Go 1.24. Repo: https://github.com/gofr-dev/gofr Docs: https://gofr.dev/docs My projects: https://github.com/3ni8ma

Design Tokens and Theme Systems with Tailwind

Aarush Karak — Sat, 05 Sep 2026 16:41:07 +0000

Three Layers of Tokens

Primitive tokens are the raw materials (a color ramp, a type scale); semantic tokens map to intent (background, surface, text-accent); component tokens bind semantics to components (button-bg, card-border). The rule that keeps themes sane: components reference semantic tokens only — never primitives directly.

CSS Variables as the Runtime

Tokens as CSS custom properties on :root, overridden by scoped selectors. Theme switching via data-theme attributes: html[data-theme='dark'] { --surface: ... }. The tradeoff: CSS variables resolve at runtime (instant theming, no rebuild) at the cost of not being static values.

The Pitfalls of Variables in Gradients

var(--x) inside radial-gradient() stops and some background-image url() contexts fails to resolve in several browsers. The workarounds: hardcoded values in gradient stops, or html[data-mode] selector overrides that swap entire gradient declarations instead of referencing variables.

Dark Mode Without Duplication

The mode-agnostic design: semantic tokens stay the same; only surface-layer tokens flip with data-mode. Body backgrounds, text colors, and glass effects swap; accent palettes remain identical across modes. One component stylesheet, two modes, zero dark: prefixes.

Extending Tailwind with a Plugin

A Tailwind plugin adds utilities and theme values from your tokens: theme.extend.colors from semantic tokens, custom utilities via addUtilities, and component classes via addComponents. The payoff: bg-surface, text-accent, glass — your design language becomes the utility vocabulary.

Shipping a Token Package

Tokens as code: a TypeScript/JSON source of truth, build scripts generating the CSS variables and the Tailwind config, and versioning for consumers. A token change propagates to every consumer through the build — the theme is a dependency, not a find-and-replace.

NOTE: The bank-driven fallback wrote this post because the LLM proxy was unreachable — structure and facts come from the topic outline, and the next regeneration will enrich it.

Key Takeaways

Three Layers of Tokens
CSS Variables as the Runtime
The Pitfalls of Variables in Gradients
Dark Mode Without Duplication
Extending Tailwind with a Plugin
Shipping a Token Package

FAQ

Q: What is the key idea in three layers of tokens?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Q: What is the key idea in css variables as the runtime?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Q: What is the key idea in the pitfalls of variables in gradients?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Conclusion

A theme system is architecture: primitive, semantic, and component layers that keep design intent stable while visuals evolve. With CSS variables as the runtime and Tailwind as the vocabulary, a redesign becomes a token update instead of a rewrite.

View the project on GitHub

Crawling at Scale: Scheduling, Deduplication, and Storage

Aarush Karak — Thu, 03 Sep 2026 16:01:48 +0000

The Frontier: What to Fetch Next

The crawl frontier is a priority queue of URLs, not a set. Rules that matter: scope filtering (stay on allowed hosts/paths), freshness (when to re-fetch a page), and prioritization (document pages over index pages). A frontier without priorities degenerates into hammering the same section.

Politeness as a Hard Requirement

The politeness policy: delay between requests per host (configurable, generous defaults), retry with exponential backoff on 429/5xx, and Last-Modified/ETag conditional fetches. A crawler that respects politeness is tolerated; one that doesn't gets blocked — and burns the IP for everything else.

Content Deduplication

Crawled pages are full of near-duplicates: pagination, boilerplate, template variants. The patterns: canonical URL detection, normalized-content hashing (strip whitespace and boilerplate before hashing), and similarity thresholds for near-dupes. Dedup before storage — every duplicate stored is noise in the dataset.

Incremental Re-Crawl

Re-crawling everything every time is wasteful. The design: a crawl manifest keyed by URL with last-fetched time and content hash; re-crawl decisions based on freshness TTLs and change signals (headers, sitemap modtime). The dataset stays current at a fraction of the full-crawl cost.

Storage: Raw, Extracted, Derived

The three-layer store: raw HTML in object storage (cheap, immutable), extracted content in a queryable database (documents, metadata, full text), and derived artifacts (indexes, embeddings) in purpose-built stores. The pipeline is idempotent at every layer — re-running a stage must never corrupt the layers below.

The System Architecture

A crawler as a service: scheduler (cron or queue) → fetcher workers (bounded concurrency per host) → extractor → dedup → storage. Observability: per-host stats, error rates, and crawl coverage reports. A crawler you can't see into is a crawler you can't trust.

NOTE: The bank-driven fallback wrote this post because the LLM proxy was unreachable — structure and facts come from the topic outline, and the next regeneration will enrich it.

Key Takeaways

The Frontier: What to Fetch Next
Politeness as a Hard Requirement
Content Deduplication
Incremental Re-Crawl
Storage: Raw, Extracted, Derived
The System Architecture

FAQ

Q: What is the key idea in the frontier: what to fetch next?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Q: What is the key idea in politeness as a hard requirement?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Q: What is the key idea in content deduplication?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Conclusion

Scaling a crawler is an exercise in discipline: priorities, politeness, deduplication, and storage separation. The pipeline that respects those four constraints scales to thousands of pages without drama — and produces a dataset you can actually trust.

View the project on GitHub

GitHub Automation with the gh CLI: Triage, PRs, and Workflows

Aarush Karak — Tue, 01 Sep 2026 16:38:29 +0000

gh as the Complete API Client

gh api exposes the entire REST and GraphQL surface with auth built in. The pattern that unlocks everything: gh api repos/{owner}/{repo}/issues piped to jq, and gh run watch for workflow observability. The CLI is a thin wrapper over the API — everything the website can do, a script can do.

Automated Issue Triage

The triage loop: fetch unlabeled issues, classify by keywords and titles, apply labels, assign priorities, and route to the right maintainer. A nightly script keeps a backlog organized without anyone touching the web UI. The discipline: classification must be conservative — an untriaged issue is better than a wrong label.

PR Review Automation

The reviewer's checklist as code: check CI status, verify the diff touches only declared files, confirm the description matches the change, and comment when something fails the check. gh pr view --json + gh pr diff make the review scriptable; the script comments, a human decides.

Workflow Lifecycle Management

Beyond triggering: gh workflow disable for flaky jobs, gh run rerun for transient failures, and gh api to approve protected-branch runs. The automation pattern: a cron that checks for failed runs older than a threshold and either reruns them once or files an issue — flaky CI stops being noise.

Cross-Repo Coordination

One script, many repos: a loop over gh repo list runs the same triage or release check everywhere, and gh issue create --repo files findings in each. For the 3-4 repos one person actually maintains, cross-repo automation collapses hours of manual clicking into one scheduled pass.

Identity and Safety

Automated actions run as a bot user or a PAT — the audit trail must show who did what. The safety patterns: --dry-run flags everywhere, confirmation prompts for destructive ops (deletes, force-pushes, label removal), and rate-limit awareness (gh api rate_limit).

NOTE: The bank-driven fallback wrote this post because the LLM proxy was unreachable — structure and facts come from the topic outline, and the next regeneration will enrich it.

Key Takeaways

gh as the Complete API Client
Automated Issue Triage
PR Review Automation
Workflow Lifecycle Management
Cross-Repo Coordination
Identity and Safety

FAQ

Q: What is the key idea in gh as the complete api client?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Q: What is the key idea in automated issue triage?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Q: What is the key idea in pr review automation?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Conclusion

The gh CLI makes GitHub a scripting surface: triage, review checks, workflow hygiene, and cross-repo maintenance all become scheduled, testable, and reviewable. The discipline — conservative classification, dry runs, honest audit trails — is what keeps the automation trusted.

View the project on GitHub

Running a Local LLM Proxy: OpenAI-Compatible Gateways

Aarush Karak — Sat, 29 Aug 2026 16:01:46 +0000

Why a Gateway

Every AI tool — editors, agents, scripts — speaks the OpenAI chat-completions dialect. A local gateway that speaks that dialect and forwards to whatever model you actually run makes every tool plug into local inference with zero code changes. One port, many consumers.

The Compatibility Contract

The surface that must match: /v1/chat/completions with messages, model, temperature, max_tokens; SSE streaming via stream: true; and error responses shaped like OpenAI's. Tools that validate models (a hardcoded model list) will reject your endpoint — accept any model name and map it, or report it honestly.

Streaming Without Breaking Clients

Clients that expect streaming fail on buffered responses. The implementation: read the upstream stream chunk-by-chunk, re-emit as SSE data: frames, flush on each token, and terminate with data: [DONE]. Timeouts are the silent killer — an idle upstream must send keep-alive comments or the client hangs forever.

Caching as the Cost Killer

Identical prompts are common across sessions (system prompts, templates, retries). A prompt-hash cache with TTL serves repeated requests instantly and cuts provider spend. The design decision: cache exact matches only — semantic caching of LLM output is where correctness dies.

Routing and Fallback

A gateway that routes by model name, cost budget, or availability. The fallback ladder: local model → free tier → paid provider, with health checks that demote a failing upstream. The pattern: retry with backoff on 429/5xx, fail over on repeated failures, and never silently return a different model than requested.

Operational Details That Matter

launchd or systemd supervision, structured logs with per-request latency, and a health endpoint (/v1/models) for uptime monitoring. The gateway becomes the single place where model behavior — version, temperature caps, token limits — is controlled for the whole machine.

NOTE: The bank-driven fallback wrote this post because the LLM proxy was unreachable — structure and facts come from the topic outline, and the next regeneration will enrich it.

Key Takeaways

Why a Gateway
The Compatibility Contract
Streaming Without Breaking Clients
Caching as the Cost Killer
Routing and Fallback
Operational Details That Matter

FAQ

Q: What is the key idea in why a gateway?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Q: What is the key idea in the compatibility contract?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Q: What is the key idea in streaming without breaking clients?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Conclusion

A local LLM proxy is the quiet infrastructure that makes local AI practical: one compatible endpoint, streaming done right, caching for cost, and honest routing. It turns 'AI tools need APIs' into 'everything already works, it's just local now.'

View the project on GitHub

Vite Plugin Development: Hooks, Transforms, and Virtual Modules

Aarush Karak — Thu, 27 Aug 2026 16:01:55 +0000

The Plugin Container Model

A Vite plugin is an object with hooks, layered over Rollup. The phases: config (adjust Vite config), configResolved (read final config), buildStart (initialize), transform (rewrite module source), generateBundle (write output files), closeBundle. Understanding when each runs — dev vs build — is half the API.

Transforms: Rewriting Modules Safely

A transform hook receives code + id and returns modified code. The discipline: only touch files you own (check id patterns), return null to pass through untouched, and never rely on textual assumptions about frameworks — use the loaders' ASTs or the module graph instead.

Virtual Modules for Injected Code

Virtual modules let a plugin provide modules that don't exist on disk: virtual:my-plugin-data. Intercept in resolveId, emit in load. This is how plugins inject runtime data (config, asset manifests, environment) without touching the user's source tree — and how sitemap plugins feed route lists to components.

Build-Time Asset Generation

The generateBundle hook writes files into the output: sitemaps, robots, feeds, OG images. The pattern: collect data during earlier hooks (routes from the module graph, page metadata from transforms), then emit this.emitFile({ type: 'asset', fileName, source }). Assets emitted here are hashed, deployed, and cacheable like any other build output.

Dev Mode: Middleware and HMR

In dev, plugins get an HTTP middleware (configureServer) and HMR hooks. A sitemap plugin doesn't need it, but a plugin serving mock APIs or proxying websockets lives here. The rule: dev features must not leak into the production bundle — gate everything on config.command.

Publishing and Testing Plugins

A Vite plugin is a library: vite-plugin-* naming, ESM-first, exports map, and a test suite that runs the real Vite build against a fixture project. The buildTest pattern: a temp project, build(), and assertions on output files — faster and more honest than unit-testing hooks in isolation.

NOTE: The bank-driven fallback wrote this post because the LLM proxy was unreachable — structure and facts come from the topic outline, and the next regeneration will enrich it.

Key Takeaways

The Plugin Container Model
Transforms: Rewriting Modules Safely
Virtual Modules for Injected Code
Build-Time Asset Generation
Dev Mode: Middleware and HMR
Publishing and Testing Plugins

FAQ

Q: What is the key idea in the plugin container model?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Q: What is the key idea in transforms: rewriting modules safely?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Q: What is the key idea in virtual modules for injected code?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Conclusion

Vite plugins are the cleanest expression of the bundler-as-platform idea. Hook order, transform discipline, and virtual modules cover most real needs — and a plugin that generates build artifacts (sitemaps, feeds) is one of the highest-leverage integrations a site can have.

View the project on GitHub

Browser Automation That Looks Human

Aarush Karak — Tue, 25 Aug 2026 16:02:07 +0000

What Detection Systems Measure

A fingerprint is a vector: user agent, WebGL vendor and renderer strings, canvas hash, audio context, screen metrics, fonts, timezone, and navigator property consistency. Bot detectors score the vector for anomalies — a headless Chromium with navigator.webdriver=true fails instantly; the game is scoring like a real device.

Patching the Leaky Surface

The leaks: navigator.webdriver, missing window.chrome, the --headless UA, and iframe parent attributes. The fixes: CDP session to override properties before any script runs, spoofed WebGL strings, and a realistic UA/fingerprint pair. The rule: every override must be consistent — a Chrome UA with a Safari canvas hash is worse than no spoofing.

Input That Reads as Human

Automated typing is instant and perfectly regular; humans type with variable inter-key latency, occasional corrections, and pauses. The pattern: randomized per-character delays with log-normal distribution, jittered mouse movement along bezier curves, and scroll speeds that vary. Timing consistency across a session matters more than any single delay.

Session Persistence: The Cookie Jar That Matters

Sites trust continuity: a fresh context with no cookies, no localStorage, and a first-seen IP screams automation. The pattern: persistent browser profiles stored between runs, realistic storage state, and reusing the same context for related tasks. Trust compounds over time.

Orchestrating Multi-Context Automation

Different tasks need different identities. The architecture: a context manager that provisions profiles, health-checks them (does this context still pass a fingerprint test?), and rotates on failure. A context that gets flagged is retired, not reused — one burned context can poison everything it touched.

The Ethics of Blending In

Human-like automation exists on a spectrum: scraping public data with throttling is defensible; impersonating a user or evading explicit blocks is not. The operational rules that keep a project defensible: rate limits well under human capacity, respect robots.txt and ToS, and never automate account creation or payment flows.

NOTE: The bank-driven fallback wrote this post because the LLM proxy was unreachable — structure and facts come from the topic outline, and the next regeneration will enrich it.

Key Takeaways

What Detection Systems Measure
Patching the Leaky Surface
Input That Reads as Human
Session Persistence: The Cookie Jar That Matters
Orchestrating Multi-Context Automation
The Ethics of Blending In

FAQ

Q: What is the key idea in what detection systems measure?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Q: What is the key idea in patching the leaky surface?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Q: What is the key idea in input that reads as human?
A: It is one of the core decisions that shape this topic. The section above walks through the reasoning, the tradeoffs, and the practical takeaway in context.

Conclusion

Human-like browser automation is a fingerprint consistency problem, not a feature list. Every patched leak must be coherent with the identity you're projecting — and the engineering discipline matters less than the boundaries you refuse to cross.

View the project on GitHub