DEV Community: Kris Chou

🚀 “GraphQL Is Faster Than REST” - Nope. Here’s Why.

Kris Chou — Wed, 08 Oct 2025 17:02:41 +0000

I keep hearing this over and over again:

“Bro, GraphQL is way faster than REST.”

But… that’s not actually true.
Both GraphQL and REST are just HTTP requests under the hood.
There’s nothing magical that makes GraphQL inherently faster.

Let’s break it down simply!

⚡ What People Think Makes GraphQL Faster

Fewer Network Calls

With REST, you often need to hit multiple endpoints:

GET /user/123
GET /user/123/posts
GET /user/123/followers

With GraphQL, you can do this in one query:

query {
  user(id: "123") {
    name
    posts { title }
    followers { name }
  }
}

✅ One request instead of three.
✅ Less network latency.
➡️ Feels faster to the client.

Smaller Payloads

REST endpoints usually return fixed responses, often with a bunch of fields you don’t need.
GraphQL lets you request only what you want.

✅ Less data over the wire
✅ Faster perceived load time
➡️ Again, it feels faster.

🐢 But Under the Hood…

GraphQL has to parse, validate, and resolve the query dynamically.
→ More CPU overhead on the server.

Complex nested queries can trigger multiple resolver calls.
→ Slower than a single optimized REST endpoint.

Caching is harder because each query can be unique.
→ You lose a big performance advantage of REST.

So in raw performance terms:
➡️ REST is often faster on the server side.
➡️ GraphQL feels faster on the client side.

In short, no magic that makes GraphQL faster.

🧠 When GraphQL Actually Shines

GraphQL isn’t about raw speed.
It’s about flexibility, data shaping, and developer experience.

Real use cases where GraphQL is a great fit:

Aggregating data from multiple sources in one request
Mobile or frontend teams that need flexible queries without backend changes
Rapid prototyping and evolving APIs without versioning endpoints
Complex relationships between entities (e.g., social graphs, nested structures)

If your data model is flat and predictable, REST is simpler and usually faster.

If your data is complex, fragmented, or constantly changing, GraphQL gives you superpowers.

Conclusion

GraphQL isn’t faster. It just gives the client what it needs more efficiently.
🚀 Use REST when simplicity and caching matter.
🧠 Use GraphQL when flexibility and complex data fetching matter.

👉 Your backend doesn’t need to pick sides. Many real-world systems use both: REST for simple endpoints, GraphQL for complex aggregation.

Building a Cost-Effective Product Recommendation System: An End-to-End Guide

Kris Chou — Mon, 01 Sep 2025 13:42:15 +0000

If you’ve ever browsed an e-commerce platform and felt that “this product was just right for me,” you were likely nudged by a recommendation engine. Today, startups and growing businesses want to deliver that same experience without the deep pockets of Amazon or Netflix. The good news? With the rapidly evolving AI ecosystem, you can now build a scalable, cost-effective recommendation system with thoughtful architectural choices.

In this post, we’ll explore how to design such a system—covering recommendation criteria, the choice of LLMs and embedding models, vector databases, hosting platforms, and optimization strategies—all while keeping costs under control.

1. Defining Recommendation Criteria: The Foundation
Before you write a single line of code, you need to define what your recommendation system optimizes for.

Some possible criteria:

Behavioral relevance: “people who bought X also considered Y.”
Content affinity: match product descriptions or reviews to a user’s intent/profile.
Context-aware suggestions: recommend based on season, location, or time.
Business objectives: boost high-margin products, clear inventory, or highlight new arrivals.

👉 Tip: Start with hybrid criteria (behavioral + content + business rules). You’ll achieve better relevance and flexibility without over-engineering.

2. Leveraging LLMs Strategically
Large Language Models (LLMs) are powerful, but using them naively can lead to ballooning costs. Instead of letting an LLM be the recommender, use it as an orchestrator.

LLM as a re-ranker: Precompute candidate recommendations using embeddings (cheap) and let the LLM refine them with natural language reasoning (targeted).
LLM as a context interpreter: Use it to parse user queries (e.g., “I need eco-friendly kitchenware under $50”) into structured filters.

👉 Cost-saving trick: Instead of calling GPT-4 on every request, consider smaller open-source LLMs fine-tuned on your domain, or leverage distillation to train a cost-efficient model just for query rephrasing/re-ranking.

3. Choosing the Right Embedding Model
Embeddings are the workhorses of modern recommender systems. They allow you to capture semantic meaning in product data and user queries.

OpenAI’s text-embedding-3-small/large: Reliable, scalable, SaaS-managed.
Cohere or Voyage embeddings: Strong in domain-specific semantic matching.
Open-source embeddings (e.g., Instructor, MiniLM, BGE models): Great for cost savings with on-prem or self-hosted inference.

👉 Smart move: If budget is tight, host a small-but-strong embedding model on a GPU spot instance or use serverless inference (e.g., Modal, Replicate). For many e-commerce catalogs, 384–768 dimensional embeddings are enough—you don’t need 3000+ dims.

4. Picking the Right Vector Database
Your vector database is the backbone of similarity search. But not all vector DBs are equal for cost-efficiency.

Pinecone: Easy, fully managed, pay-as-you-go. Good for scaling quickly.
Weaviate: Open-source + hybrid search (vector + keyword). Can self-host.
Qdrant or Milvus: Open-source, resource-efficient, easy to run on Kubernetes.
pgvector (Postgres extension): Perfect if you want minimal complexity and are already using Postgres.

👉 Rule of thumb:

If you’re a startup on low budget → pgvector or Qdrant self-hosted.
If rapid scale and global latency tolerance matter → Pinecone or Weaviate managed.

5. Hosting and Infrastructure: Where Costs Hide
Your infrastructure decisions influence 50% of hidden costs.

Options:

Cloud AI PaaS (AWS Bedrock, Azure AI, GCP Vertex AI): Fast integrations, but lock-in + cost overhead.
Serverless platforms (Modal, Fly.io, Vercel Edge Functions): Great for unpredictable workloads.
Bare-metal or GPU spot instances: Best for ML-heavy workloads where cost/performance trade-offs are crucial.

👉 Balanced Approach:

Run embeddings in a batch mode (precompute for catalog and users).
Use serverless LLM hosting for low-latency inference when needed.
Cache aggressively: not every query requires recomputation.

6. Optimization Principles for Cost-Aware Systems
Here’s where innovative systems distinguish themselves:

Caching & Reuse: Cache user embeddings, and reuse LLM parsing for similar queries.
Multi-Stage Retrieval: Start with a low-cost retrieval (embedding similarity) → narrow down → high-cost refinement (LLM).
Hybrid Search: Combine vector + keyword filtering for precision and efficiency.
Model Right-Sizing: Don’t run a massive LLM when a smaller model + business logic can solve 80% of cases.

7. Putting It All Together: A Sample Architecture
Imagine building a recommendation system for a mid-sized online bookstore:

Data ingestion: Store product metadata, user profiles, and behavioral logs.
Embedding generation: Use MiniLM embeddings for books and user interests.
Vector storage: pgvector/Postgres for cost-efficient similarity search.
Candidate retrieval: Fetch top 50 similar books for a user.
Reranking with LLM: A fine-tuned LLaMA-3 8B reranks based on user’s latest query.
Business rule overlay: Promote seasonal books or publisher-specific promotions.
Serve via serverless API: Cost scales with traffic, not idle time.

This architecture balances relevance, scalability, and cost—using LLMs only where they shine, embeddings where they are cheap, and databases where they are efficient.

Final Thoughts
Building a product recommendation engine no longer requires million-dollar infrastructure. By carefully defining your criteria, selecting the right AI components, and using LLMs strategically rather than blindly, you can deliver Amazon-like personalization at a fraction of the cost.

The future lies in hybrid intelligence systems—blending embeddings, LLM reasoning, vector search, and efficient hosting. Companies that master this balance won’t just save costs; they’ll create products that feel magically personalized while staying lean and efficient.

✨ Next Steps: If you’re considering building your own recommendation system, start small:

Run embeddings + pgvector locally.
Add an LLM re-ranker for 10% of traffic.
Measure improvements, then scale.

Your recommendation engine doesn’t need to start big, it just needs to start smart.

Making Bold Decisions: Letting Team Members Go Without Taking It Personally

Kris Chou — Thu, 26 Jun 2025 17:12:58 +0000

As leaders, we’re often called upon to make difficult choices—none more personally challenging than the decision to let someone go. It's a moment that tests not just our leadership but our humanity. Each time I’ve faced this situation, it has weighed heavily on me. I’ve struggled with the emotional toll, questioned myself, and taken it personally. And yet, each time, the outcome has been clear: the team grew stronger, the business moved forward, and the overall culture became healthier.

Over time, I’ve come to understand that bold leadership doesn’t mean acting without emotion—but rather, acting with purpose despite the emotion.

1. The Team Comes First
Every individual matters, but the collective health of the team must take priority. If a team member consistently misaligns with core expectations—whether it's performance, collaboration, or cultural fit—it can silently erode morale and momentum. Allowing a misalignment to linger can stall progress, confuse priorities, and breed frustration among those who are fully committed and performing well.

As difficult as it is, a decisive change can reinvigorate a team and unlock the potential that's been held back.

2. The Mistake: Taking It Too Personally
Early in my leadership journey, I took these decisions incredibly personally. I internalized the outcome as a failure on my part—believing I hadn’t coached well enough or supported enough. While that self-reflection was important, I later realized that I was carrying more than I should have. Leadership means offering support and clarity, but it also means accepting that not every match is right—and that doesn’t make it a personal failure.

By making the decision to move on from a misaligned team member, I eventually saw the positive results: improved morale, restored clarity, and regained momentum. In hindsight, those decisions—though painful—were necessary for the greater good.

3. Balancing Empathy and Accountability
Letting someone go is not an act of indifference. It should be done with empathy, transparency, and respect. At the same time, leaders must hold themselves accountable to the team and the mission. Avoiding tough decisions in the name of kindness can backfire, often hurting more people in the long run.

Empathy doesn’t mean avoiding discomfort; it means delivering truth with humanity.

4. Clarity Builds Trust
When a leader delays action, the team feels it. It creates ambiguity around performance expectations and cultural values. On the other hand, when decisions are made with clarity and communicated thoughtfully, it reinforces trust and sets a standard. People want to work in environments where excellence is expected and where leadership acts with integrity.

5. Grow from the Experience
After each of these experiences, I’ve taken time to reflect: Could I have set expectations better? Did I provide the right feedback at the right time? This self-inquiry has helped me evolve as a leader. It has also made me more confident in recognizing that making the hard call is sometimes the most respectful and necessary thing we can do—for everyone involved.

Conclusion

Letting someone go will never be easy—and it shouldn’t be. But as leaders, we must balance compassion with clarity, and empathy with action. I’ve learned—through difficult but necessary decisions—that what feels personal in the moment can ultimately be professional growth for all parties.

When done with care and conviction, these decisions not only protect the integrity of the team but also uphold the values we’re working to build. Leadership isn’t about avoiding the hard calls. It’s about making them—for the right reasons, and in the right way.

Answering the Interview Question: "How Do You Review Code as a Tech Lead?"

Kris Chou — Mon, 09 Jun 2025 13:42:30 +0000

Over the past 5+ years, I've worked as a Tech Lead and Lead Engineer across multiple startups and enterprise projects. Naturally, I’ve gone through several interview loops for leadership roles, and one question I keep encountering is:

“How do you approach code reviews as a tech lead?”

This question may seem tactical on the surface, but in reality, it reveals a lot about your engineering judgment, system thinking, and leadership philosophy.

Here's how I answer it, and how I actually approach code reviews in real-world teams.

1. Design Comes First
As a tech lead, I always prioritize design in every code review. Before diving into line-by-line details, I step back and ask:

Does this solution align with our overall system architecture?
Is it scalable, extensible, and testable?
Does it follow the design principles and patterns we agreed on as a team?

A PR that passes all tests and looks clean but solves the wrong problem or introduces architectural debt is a silent killer in the long run. That's why I often challenge or affirm the core design direction before touching anything else.

2. Then, Clean and Intentional Code
Once I’m confident the design is solid, I move on to reviewing the actual implementation. Here, I look for clarity, simplicity, and intent.

Some of the things I pay close attention to:

Readability & Naming: Is the code easy to follow? Do variable, function, and class names communicate purpose clearly?
Separation of Concerns: Are responsibilities well-defined across modules, functions, and classes?
Abstractions: Are there repeated patterns that can be abstracted meaningfully — or unnecessary abstractions adding cognitive load?
Error Handling & Edge Cases: Are errors and edge cases thoughtfully managed? Is there defensive coding where needed?
Testing: Are there meaningful unit or integration tests? Do tests assert behavior rather than implementation?
Performance & Security: Are there any red flags in terms of resource usage, blocking operations, or exposure of sensitive data?
Consistency with Team Conventions: Does the code follow agreed-upon linting rules, formatting, and architectural conventions?

Ultimately, clean code means little if it's built on poor design — but when great design meets well-crafted code, it sets the stage for long-term success.

To ensure consistency across the team, I rely on tool-based linting and formatting instead of IDE-specific plugins, since team members often use different editors and setups.

For Python, I commonly use:

Black and isort for formatting
flake8, Pylint, and mypy for linting and type checking
pre-commit to enforce checks before code enters the repo

For Node.js / JavaScript / TypeScript, I use:

ESLint and Prettier for linting and formatting
TypeScript (with strict mode) for static typing
Husky and lint-staged for pre-commit automation

This approach helps enforce a shared code quality baseline across the team, regardless of individual development environments.

Final Thoughts
As tech leads, we’re not just guardians of syntax or formatting, we’re stewards of quality, architecture, and team health. A thoughtful code review process is one of the most scalable ways to mentor, prevent future bugs, and shape the engineering culture.

If you’re prepping for a tech leadership interview, or mentoring others who are, I encourage you to think about code reviews not just as a gatekeeping function, but as a strategic tool.

P.S. I'm not claiming this is a perfect answer, even though this approach has worked well for me in interviews and on real teams.
If you think I’ve missed anything, or even completely missed the mark, I’d genuinely love to hear your perspective. Let's keep learning from each other.

🚀 Applied AI for Developers: Get Practical, Stay Relevant

Kris Chou — Thu, 29 May 2025 04:02:51 +0000

The rise of LLMs isn’t just hype-it’s changing the software development landscape. From chatbots to document Q&A, applied AI is now part of the core tech stack.

So, how can developers catch up and start building with it today?

💡 Here’s a practical approach:

Use LangChain to Orchestrate AI Workflows
LangChain makes it easy to chain LLM calls, tools, and memory into powerful applications—without reinventing the wheel. Whether it's document search, conversational agents, or code generation, it’s a game changer for rapid prototyping.

Leverage AstraDB for Scalable Vector Search
Combine LangChain with AstraDB to store and query your embeddings using built-in vector search capabilities. It's serverless, fast, and integrates smoothly with the LangChain ecosystem—ideal for deploying production-grade AI features.

Focus on Solving Real Problems
Don’t get lost in the math. Applied AI is about delivering value. Whether you're helping users search smarter, automate responses, or summarize content—start with the problem, not the model.

Build and Share
Use open-source tools and cloud services to build your own LLM-powered side project. Share your learnings. Contribute. The best way to master AI is to use it.

🔍 Being AI-savvy doesn’t mean becoming a researcher—it means being a builder who knows how to apply powerful tools like LangChain and AstraDB to real-world problems.

Curious how others are integrating LLMs into their workflow? Let’s talk 👇

LangChain #AstraDB #LLM #AI #AppliedAI #VectorSearch #SoftwareEngineering #DevLife #OpenAI #GenerativeAI