DEV Community: Srikar Phani Kumar Marti

I built a backend platform that generates REST APIs from a schema — no code, no server setup

Srikar Phani Kumar Marti — Fri, 29 May 2026 04:09:40 +0000

Every side project I've shipped starts the same way: I have a frontend idea, and I immediately have to stop and go build a backend for it.

Not because the backend is hard. Because it's tedious. The same patterns, every time. Define a model. Wire up routes. Handle errors. Write docs nobody reads. Set up auth. Repeat.

At some point I stopped asking "how do I build this backend faster" and started asking "why am I building it at all?"

That question became Crudly.

What it actually does

You create a project, add a collection (think: a database table with a name and fields), and Crudly instantly gives you a live REST API at:

https://api.crudly.org/v1/{your-project}/{collection-name}

GET, POST, PUT, DELETE — all working, all authenticated, all documented. You didn't write a single line of backend code.

Here's what that looks like in practice. I created a project called sample, added a todos collection, and within about 30 seconds I had:

# List all todos
curl "https://api.crudly.org/v1/sample/todos" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Create a todo
curl -X POST "https://api.crudly.org/v1/sample/todos" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title": "Repair Watch", "done": false}'

That's it. No Express. No Postgres migrations. No deploy step.

The architecture decision that makes this possible

Crudly doesn't generate code. There's no Express app being scaffolded and deployed per user. That approach sounds appealing until you think about what it costs — cold starts, isolated infra per project, deployment latency, and a maintenance nightmare.

Instead, the API server uses dynamic runtime routing. Every request to api.crudly.org/v1/{project}/{collection} hits the same handler. At request time, it reads your schema configuration, validates the request against it, and serves or persists data accordingly.

The schema is the source of truth. The routes don't exist as code — they're resolved at runtime from what you defined in the dashboard.

This is the same pattern that makes tools like Hasura and PostgREST compelling, except Crudly's surface area is intentionally smaller. You're not writing GraphQL. You're not pointing it at your own Postgres instance. You create a collection, you get endpoints. That's the whole contract.

What ships with it

The thing I kept running into with minimal API tools is that they solve one problem and leave you to figure out everything adjacent. Crudly ships the full surface:

Playground — A browser-based HTTP client (Postman style) built into the dashboard. Select your collection, pick a method, fire a request. I built this because switching to Postman or Insomnia mid-flow kills momentum. The response comes back formatted, with status codes and timing.

Auto-generated docs — Every collection gets docs that reflect the actual schema. They update when the schema changes. The curl examples use your real endpoint URLs. No Swagger YAML to maintain.

Request logs — Real-time traffic visible from the dashboard, filterable by method, status, endpoint, and date. Useful enough that I've caught integration bugs in client apps just from watching the log stream.

Webhooks — POST callbacks on create, update, or delete events per collection. If you're integrating with n8n, Zapier, or your own service — this is how you wire it up without polling.

API key auth — Read-only and read-write keys per project. Generate and revoke from the dashboard. Keys go in the Authorization: Bearer header.

Admin Panel — A generated data dashboard. Browse records, create entries, edit, delete. Useful during development and for non-technical stakeholders who need to manage content.

What I didn't build (deliberately)

No custom logic. No middleware hooks. No computed fields. No joins across collections.

If you need those things, you need a real backend and you should build one. Crudly is not trying to be Firebase or Supabase. It targets a specific use case: you have a frontend, you need persistent data with a REST interface, and you want it running in under five minutes.

The constraint is the feature. Every time I was tempted to add "just a bit of custom logic support," I asked whether it would break that five-minute promise. Usually it would.

Where it actually fits

The use cases where Crudly earns its keep:

Prototyping and MVPs — Wire up a real API before you've decided whether the product is worth building a proper backend for.
Frontend demos and portfolios — Stop mocking data in JSON files. Ship something that actually persists.
Internal tools — A quick admin data store for a side dashboard, without standing up another service.
Hackathons — The entire backend setup takes less time than arguing about which framework to use.

Try it

Crudly is live at crudly.org. Free plan available. Create a project, add a collection, hit the endpoint — it takes about two minutes to get to a working API call.

If you run into anything broken or have a use case it doesn't handle, I'm interested. Still actively building this.

I Ran AI Models Directly in the Browser and Measured What It Did to Core Web Vitals

Srikar Phani Kumar Marti — Sun, 17 May 2026 07:37:49 +0000

Everyone is shipping AI features. Sentiment analysis on user input, speech recognition without sending audio to a server, image classification that never leaves the device. The privacy pitch is real, the latency pitch is real. But nobody's asking the obvious question:

What does running a neural network in the browser actually cost the user?

I decided to find out. I built a benchmark harness, ran four quantized models in Chrome stable, and measured the impact on Core Web Vitals — specifically INP, the metric Google now uses to rank your site.

Here's what I found.

The Setup

The test uses Transformers.js — the library that lets you run Hugging Face models directly in the browser via WebAssembly. All models were loaded in INT8 quantized format (q8) to reflect real production conditions.

Four models, chosen to cover different architectures and modalities:

Model	Params	Task	Architecture
DistilBERT	66M	Sentiment analysis	Encoder (6 layers)
BERT-base	110M	Feature extraction	Encoder (12 layers)
Whisper Tiny	39M	Speech recognition	Encoder-Decoder
MobileViT-S	5.7M	Image classification	Vision Transformer

The benchmark harness is live at benchmark.mspk.me and open source at github.com/srikarphanikumar/cwv-ai-benchmark. Run it yourself.

What Is INP and Why Does It Matter?

INP (Interaction to Next Paint) replaced First Input Delay as Google's interactivity metric in March 2024. It measures how long it takes for the browser to respond to a user interaction — a click, a tap, a keypress — and paint the result.

Google's thresholds:

✅ Good: under 200ms
⚠️ Needs Improvement: 200–500ms
❌ Poor: over 500ms

INP affects your search ranking. More importantly, it affects whether users feel your app is responsive or broken.

When you run neural network inference on the browser's main thread, you're blocking it. That means if a user clicks something while inference is running, their click won't be processed until the model finishes. That delay IS your INP.

The Results

Here's the full table from Chrome stable on an Apple M-series MacBook Pro, 16GB RAM:

Model	Load Time	Avg Inference	INP	INP Class	Mem Δ	Mem Pressure
DistilBERT	7.85s	25.1ms ±0.5	27.8ms	✅ Good	+59.6MB	2.5%
BERT-base	6.07s	83.3ms ±1.5	85.0ms	⚠️ Needs Improvement	+65.3MB	4.1%
Whisper Tiny	6.71s	496.9ms ±6.2	540.3ms	❌ Poor	+123.9MB	7.1%
MobileViT-S	1.15s	66.7ms ±1.0	75.6ms	⚠️ Needs Improvement	+37.0MB	8.0%

The Surprising Findings

1. Parameter count doesn't predict INP

Whisper Tiny has only 39M parameters — the fewest of any model tested. It also produces the worst INP at 540.3ms, more than 19x worse than DistilBERT which has 66M parameters.

The culprit is architecture, not size. Whisper is an encoder-decoder model. It doesn't process the full input in a single forward pass — it runs an autoregressive decode loop, generating output tokens one at a time. Each iteration blocks the main thread. The total blocking time accumulates regardless of how aggressively you quantize the weights.

This means no amount of quantization will fix Whisper's INP on the main thread. It's an architectural constraint, not a tuning problem.

2. MobileViT-S loads 6x faster but still misses "Good"

MobileViT-S loads in 1.15s compared to 6–8 seconds for the text models. That's a huge UX win for initial load. But its INP of 75.6ms puts it in "Needs Improvement" territory despite having only 5.7M parameters.

Vision transformer inference carries disproportionate cost relative to parameter count in WASM environments. Something to watch if you're building image classification features.

3. Memory pressure ≠ memory delta

MobileViT-S has the lowest absolute memory consumption (+37MB) but the highest memory pressure at 8.0%. That 37MB represents a larger fraction of the available JS heap than you'd expect — with implications for mid-range Android devices where heap limits are much tighter.

What This Means for Your Architecture

If you're building with encoder-only text models (DistilBERT class):
You're fine on the main thread. 27.8ms INP is negligible. Trigger inference directly on user interactions without worrying about CWV degradation.

If you're using larger encoder models (BERT-base class):
Don't trigger inference synchronously on interactions. At 85ms, stacking this with other main thread work risks crossing 200ms. Move it to a post-interaction background step — run inference after you've already painted the response.

If you're using any encoder-decoder model (Whisper, T5, BART, etc.):
You must offload to a Web Worker. This isn't an optimization — it's a requirement. The main thread will be blocked for hundreds of milliseconds no matter what you do. Transformers.js supports Web Worker execution natively:

import { pipeline } from '@xenova/transformers';

// Run in a Web Worker to avoid blocking main thread
const transcriber = await pipeline('automatic-speech-recognition', 'Xenova/whisper-tiny', {
  worker: true
});

If you're using vision transformers:
Test on actual mobile hardware before shipping. The memory pressure numbers on an M-series Mac will look very different on a mid-range Android.

Limitations to Know

TBT couldn't be captured in the deployed environment. The Long Tasks API isn't available in cross-origin deployed contexts — only in locally-served or Chrome DevTools Protocol environments. The INP measurements are real, but the full main thread blocking profile requires a different setup to measure properly.

All numbers are from high-end hardware. An Apple M-series Mac is not the median global web user's device. INP values on mid-range Android will be significantly higher — potentially 3–5x. The relative ordering of models should hold, but don't use these absolute numbers as production thresholds for mobile.

Try It Yourself

The benchmark is live and open source. Run it on your device, your network conditions, your hardware profile. Export the results as JSON or CSV.

Live benchmark: benchmark.mspk.me
Source code: github.com/srikarphanikumar/cwv-ai-benchmark
Full paper: arXiv link coming soon

If you run it on a mid-range Android or a low-end device and want to share the numbers, I'd love to see them — that's exactly the follow-on data this research needs.

TL;DR

DistilBERT is the only model that stays in Google's "Good" INP range on the main thread
Whisper Tiny is "Poor" despite being the smallest model — architecture beats quantization
Encoder-decoder models require Web Worker offloading — no exceptions
Parameter count is a bad proxy for browser inference cost
Memory pressure on mobile is a separate concern from memory consumption

The era of client-side AI is here. Now we need to measure what it actually costs.