Subscribe to Hungry Minds Get smarter about Software and AI in 5 minutes. Save 50+ hours/week with deep dives, trends, and tools hand-picked from 100+ sources. Join 50,000+ engineers from big tech to startups for 1 free email every Monday. Click to read Hungry Minds, by Alexandre Zajac, a Substack publication.

If you enjoyed this thread:

1. Follow me @itsalexzajac for more content on Software and AI
2. Check out Hungry Minds: newsletter.hungryminds.dev
3. RT the tweet below to share this thread with your audience

What did I miss?

Pick the one that matches your constraints, and go build things!

Neither is "better."

Both are tools.

GraphQL works when clients need flexibility and you can handle the backend complexity.

REST works when your API serves many clients with similar needs.

Query depth can spiral.
Rate limiting gets messy.
Complexity moves to the client.
Caching becomes your problem.

The cost of this:

You grab exactly what you need.
One plate. One trip. One endpoint.

No overfetching. No wasted bandwidth.

GraphQL is a buffet.

Multiple endpoints. Standard HTTP methods. Predictable, simple, cacheable.

But you're stuck with what the kitchen sends.

You order the salmon, you get the salmon.
Plus rice. Plus vegetables. Plus garnish.

Even if you only wanted the fish.

That's overfetching.

REST is a menu.

They're solving the wrong problem.

The real question isn't which is better.

It's which solves YOUR problem.

Most developers waste hours debating REST vs GraphQL...

Hungry Minds Get smarter about Software and AI in 5 minutes. Save 50+ hours/week with deep dives, trends and tools hand-picked from 100+ sources. Join 50K+ engineers from big tech to startups for 1 free email every Monday.

If you enjoyed this thread:

1. Follow me @itsalexzajac for more content on Software and AI
2. Check out Hungry Minds: newsletter.hungryminds.dev
3. RT the tweet below to share this thread with your audience

What do you think?

Don't choose between traditional ML and LLMs.

Combine them strategically.

Use classical methods for filtering.
Use LLMs for nuanced ranking.

This is 10,000x cheaper than the naive LLM approach.

What can we learn from this?

Results:

→ LLM-as-judge validated offline quality
→ Order penetration improved in production
→ Hybrid approach unlocked LLM benefits without scale traps

4. Personalized scoring and online integration

Combine LLM rankings with real-time signals (location, time, preferences). Deploy with standard production infrastructure.

3. Targeted LLM mapping

Now the LLM only ranks 200 items, not millions. It maps filtered candidates to user preferences with full context and nuance.

2. RAG retrieval

Use vector similarity to pull ~200 relevant candidates from millions of items. Fast, cheap, and surprisingly effective at filtering.

1. Tagset grouping

Cluster similar tagsets together offline. This creates semantic neighborhoods that reduce the search space dramatically.

0. Data cleaning and tagging

Turn messy merchant data into clean, structured tags. Think "vegan options" or "quick delivery" instead of raw descriptions.

Most teams would either abandon LLMs or burn cash.

DoorDash found a third path.

They built a hybrid system:

→ Context bloat with millions of items
→ 200M+ users = seven-figure monthly costs
→ Raw text embeddings miss critical structure

Cold start recommendations seem perfect for LLMs.

But naive approaches fail at scale:

Recommendation systems with LLMs?

DoorDash's architecture:

What are you reading this week?