Forem: Bhargav Patel

Part 3: Types of RAG

Bhargav Patel — Sun, 10 May 2026 17:51:58 +0000

Now that we understand what RAG is and how the ingestion and retrieval pipeline works, the next natural question is:

Is there only one type of RAG?

The answer is no.

In real-world systems, RAG is not a single fixed architecture. It is a family of approaches, and each one is designed for different levels of accuracy, complexity, and performance requirements.

Let’s go through the most important types of RAG used in production systems today.

1. Naive RAG (Basic RAG)

This is the simplest form of RAG.

It follows exactly the same pipeline we already discussed:

documents are chunked
embeddings are created
stored in a vector database
top matching chunks are retrieved
sent to the LLM for generation

Flow:

Query → Embedding → Vector Search → Context → LLM → Answer

Where it is used:

simple chatbots
basic document Q&A systems
prototypes and demos

Limitation:

Although it works, it is not very intelligent.

Common issues include:

irrelevant chunks sometimes get retrieved
no ranking refinement
weak handling of complex queries

2. Hybrid RAG

Hybrid RAG improves retrieval by combining two search methods:

keyword search (BM25)
vector search (semantic search)

Why this matters:

Sometimes keyword matching performs better than semantic search.

For example, if a user searches:

“GPT-4 pricing”

Keyword search can directly match exact terms more effectively.

Flow:

Query → Keyword Search + Vector Search → Merge Results → Rerank → LLM

Where it is used:

enterprise search systems
SaaS knowledge bases
large documentation platforms

Benefit:

It is significantly more reliable than naive RAG because it balances both exact and semantic matching.

3. Reranking RAG (Quality-Focused RAG)

This approach adds an extra intelligence layer after retrieval.

Instead of directly sending retrieved chunks to the LLM, the system first re-evaluates them using a reranker model.

The reranker assigns relevance scores and reorders the results.

Flow:

Query → Retrieval → Reranker → Best Context → LLM

Why this matters:

Vector search is fast, but it is not always precise in ranking results.

Reranking improves:

relevance quality
context filtering
removal of noisy chunks

Where it is used:

legal AI systems
enterprise copilots
high-accuracy assistants

4. Multi-Query RAG

Sometimes a single user query is not enough to capture intent.

So instead of retrieving once, the system generates multiple variations of the same query.

Example:

User query:

“How does refund work?”

System expands it into:

refund policy conditions
return process steps
money-back rules

Flow:

Query → Query Expansion → Multiple Searches → Merge → LLM

Benefit:

better coverage of information
higher recall
fewer missed results

5. Graph RAG (Knowledge Graph-Based RAG)

Graph RAG treats information as connected entities instead of isolated chunks.

Instead of independent documents, it builds relationships between concepts.

Example relationships:

product → policy → exception → user cases

Everything is connected in a structured graph.

Flow:

Query → Graph Traversal → Connected Context → LLM

Where it is used:

enterprise knowledge systems
research assistants
complex domain reasoning

Benefit:

stronger logical reasoning
better relationship understanding
more structured answers

6. Agentic RAG (Tool-Using RAG)

This is one of the most advanced modern approaches.

Here, the LLM behaves like an autonomous agent, not just a response generator.

It can:

plan how to answer a question
decide what to search
refine queries
call external tools or APIs
perform multiple retrieval steps

Flow:

Query → Plan → Retrieve → Reflect → Retrieve Again → Answer

Key idea:

Instead of a single retrieval step, it performs iterative reasoning.

Where it is used:

AI copilots
coding assistants
research automation systems

7. Self-RAG (Self-Checking RAG)

Self-RAG adds a verification layer after generation.

After producing an answer, the system checks:

Is this answer actually supported by retrieved context?

If not, it corrects itself by retrieving again or refining the response.

Flow:

Retrieve → Generate → Verify → Fix → Final Answer

Benefit:

reduces hallucinations further
improves factual accuracy
adds self-correction ability

Comparison of RAG Types

Type	Strength	Complexity
Naive RAG	Simple setup	Low
Hybrid RAG	Better retrieval	Medium
Reranking RAG	Higher accuracy	Medium
Multi-Query RAG	Better recall	Medium
Graph RAG	Strong reasoning	High
Agentic RAG	Autonomous workflows	Very High
Self-RAG	Self-correction	High

Key Insight

As we move from Naive RAG to Agentic RAG:

We are not just improving retrieval — we are improving reasoning ability.

That is the real evolution of RAG systems.

Final Mental Model

To simplify everything:

Naive RAG → basic retrieval
Hybrid RAG → smarter search
Reranking RAG → better ordering
Multi-Query RAG → better coverage
Graph RAG → connected knowledge
Agentic RAG → decision-making system
Self-RAG → self-correcting system

Final Thoughts

RAG is not a single architecture.

It is a complete ecosystem of retrieval-based AI systems, evolving based on:

accuracy requirements
data complexity
cost constraints
reasoning needs

But despite all variations, the foundation remains the same:

Retrieve relevant knowledge → provide it to the model → generate grounded answers

That is still the core idea behind every RAG system in production today.

Part 2: RAG Architecture: How Retrieval-Augmented Generation Actually Works

Bhargav Patel — Sun, 10 May 2026 17:47:59 +0000

Now that we understand what RAG is and why it is so popular, let’s understand how RAG actually works in real systems.

So now we will talk about the complete RAG pipeline.

RAG pipeline has two main components:

First is called the ingestion pipeline
Second is called the retrieval pipeline

These are very important concepts, but they are actually very simple once you understand them.

1. Ingestion Pipeline

Let’s first understand the ingestion pipeline.

Ingestion pipeline basically means how we prepare the data before giving it to the model.

You can think of it like preparing an open book before the exam.

We first prepare all the information in a structured format so that the model can later access it easily.

Step 1: Collect Data

First we collect all the data.

This data can be anything like:

PDF files
simple documents
Excel files
websites
or even an entire company’s internal database

So basically, we take all possible sources of information.

Step 2: Extract Useful Data

Once we collect the data, the next step is extraction.

We extract useful text from all these sources.

For example:

from PDFs we extract text
from websites we extract content
from databases we extract structured information

Now we have clean usable text.

Step 3: Split Data into Chunks

Now we split this data into small parts.

We do not process the whole document at once.

We divide it into small pieces called chunks.

For example, a document can be split into:

chunk 1
chunk 2
chunk 3
chunk 4

Each chunk contains a small meaningful portion of information.

Step 4: Convert Chunks into Embeddings

Now comes a very important step.

We convert each chunk into embeddings.

Now what are embeddings?

Basically, models cannot directly understand text. They only understand numbers.

So we convert text into numbers using embedding models.

Each chunk is converted into a vector of numbers, which represents its meaning.

Example:

"Refunds are allowed within 30 days"
→ [0.21, -0.67, 0.92, ...]

So now every chunk has:

its original text
and its embedding (vector representation)

Step 5: Store in Vector Database

Now we store all these embeddings in a vector database.

A vector database is different from a normal database.

Normal databases like MongoDB or MySQL use keyword-based search.

For example, if I search:

“heart attack symptoms”

I will only get documents that contain these exact words.

But vector databases work differently.

They use semantic search, which means meaning-based search.

So even if the exact words are not present, but the meaning is similar, it will still return results.

For example:

“heart attack symptoms”
“cardiac arrest signs”

Even if words are different, meaning is similar, so results will still be retrieved.

So this entire process of:

collecting data
extracting text
chunking
creating embeddings
storing in vector database

is called the data ingestion pipeline.

2. Retrieval Pipeline

Now let’s understand the second part, which is the retrieval pipeline.

This is the actual runtime system where user interacts with the model.

Step 1: User Query

First, the user asks a question.

For example:

“What are heart attack symptoms?”

This query enters the system.

Step 2: Convert Query into Embeddings

Just like we converted documents into embeddings, we also convert the user query into embeddings.

We use the same embedding model that was used during ingestion.

This is important because both must exist in the same vector space.

Step 3: Search in Vector Database

Now we search the vector database.

We compare the query embedding with all stored embeddings.

This is called semantic search or similarity search.

So instead of matching keywords, we match meaning.

For example, if the query is about:

heart attack symptoms

We may retrieve documents about:

cardiac arrest
chest pain
emergency conditions

Even if exact words are not present, we still get relevant results.

Step 4: Retrieve Relevant Documents (Context)

Now we get the relevant documents from the vector database.

These retrieved pieces of information are called context.

This context contains useful information related to the user query.

Step 5: Augmentation (Create Prompt)

Now instead of directly sending the user query to the LLM, we create a full prompt.

This prompt contains:

the original user query
the retrieved context

So we are basically enhancing the prompt with external knowledge.

This is called augmentation.

Step 6: Generation

Finally, this augmented prompt is passed to the LLM.

Now the LLM generates the final answer based on:

user query
retrieved context

Then we return the response to the user.

So this entire process of:

taking a user query
converting it into embeddings
searching the vector database using semantic similarity
retrieving relevant documents as context
augmenting the prompt with query and context
generating the final answer using the LLM

is called the retrieval pipeline.

Why It is Called Retrieval Augmented Generation

Now let’s understand the naming clearly.

It is called Retrieval Augmented Generation because:

Retrieval → we first retrieve relevant documents from vector database
Augmented → we add that retrieved context into the prompt
Generation → the LLM generates the final response

So all three steps together form RAG.

Complete RAG Pipeline (Simple View)

Final Understanding

So now you should clearly understand:

Ingestion pipeline is where we prepare data
Retrieval pipeline is where we use that data at runtime
Vector databases help us search based on meaning
LLM generates answers using retrieved context

One Line Summary

RAG works by preparing data into embeddings during ingestion, storing it in a vector database, and retrieving relevant context at query time to help the LLM generate accurate answers.

Part 1: What is RAG?

Bhargav Patel — Sun, 10 May 2026 16:59:38 +0000

Artificial Intelligence changed dramatically after the rise of Large Language Models (LLMs) like GPT, Gemini, Claude, and Llama.

Suddenly, AI could:

write code
summarize documents
answer complex questions
generate reports
help with research
even solve reasoning problems

For a lot of people, it felt like AI became intelligent almost overnight.

But once developers started building real products with these models, a major issue became impossible to ignore.

LLMs are powerful, but they don’t actually know your data.

They only know what they learned during training.

And that limitation led to one of the most important ideas in modern AI engineering:

Retrieval-Augmented Generation (RAG)

Today, RAG is used almost everywhere in production AI systems, especially in:

AI assistants
enterprise search tools
customer support bots
research copilots
coding assistants

Before understanding how RAG works, it’s important to understand why it became necessary in the first place.

The Problem with Traditional LLMs

Traditional language models are trained on massive datasets collected from:

books
websites
articles
code repositories
public internet content

During training, the model learns patterns in language and stores that knowledge inside billions of parameters.

But after training finishes, the model’s knowledge becomes static.

That means:

it cannot automatically learn new information
it cannot access private company data
it does not know recent updates unless retrained

For example, imagine a model trained in 2024.

That model may have no idea about:

product updates released in 2025
new company policies
recently published research
live financial information

This became one of the biggest limitations of standard LLMs.

The Hallucination Problem

Another major issue is hallucination.

A hallucination happens when an LLM confidently generates information that is wrong, misleading, or completely fabricated.

For example, imagine asking a normal LLM:

"What is our company's latest refund policy?"

If the model has never seen your company’s internal documents, it may still produce an answer that sounds polished and believable.

But the response could easily be:

outdated
partially incorrect
or entirely made up

This happens because LLMs are not databases or search engines.

They are prediction systems.

Their job is not:

"Tell the truth"

Their actual job is:

"Predict the most likely next word"

That distinction is incredibly important.

Why Fine-Tuning Wasn’t Enough

At first, many teams thought fine-tuning would solve these problems.

The idea sounded straightforward:

collect company data
retrain the model
deploy the updated version

But things became difficult very quickly.

Every time new information appeared, companies would need:

GPU resources
retraining pipelines
evaluation workflows
redeployment processes

And enterprise data changes constantly.

Policies get updated.

Products evolve.

Research grows daily.

Customer information changes every minute.

Retraining large models over and over again simply isn’t practical for most organizations.

That’s where RAG became the better solution.

So What Exactly is RAG?

Retrieval-Augmented Generation (RAG) is a technique that allows an AI system to retrieve external information before generating a response.

Instead of relying only on memorized training data, the system can:

search external knowledge sources
retrieve relevant information
use that information while answering

In simple terms:

RAG gives AI access to external memory.

And that single idea changed modern AI systems completely.

The Easiest Way to Understand RAG

Here’s the simplest analogy.

A traditional LLM is like a student taking a closed-book exam.

The student can only answer questions using memory.

If they forget something, they may:

guess
hallucinate
fail

A RAG system is like a student taking an open-book exam.

Now the student can:

search notes
check documents
read references
retrieve information in real time

Naturally, the second student gives:

more accurate answers
more updated responses
better context-aware explanations

That’s exactly what RAG enables for AI systems.

Why Modern AI Systems Need RAG

RAG became important because modern AI applications require:

fresh information
factual grounding
enterprise knowledge
private data access

without constantly retraining models.

Let’s break down the major reasons.

1. LLMs Have Outdated Knowledge

A normal LLM only knows the information it saw during training.

It does not automatically know:

today’s news
recent product launches
updated policies
newly uploaded documents

RAG solves this by retrieving the latest information dynamically.

Instead of retraining the entire model, you simply update the knowledge source.

2. RAG Reduces Hallucinations

Without retrieval, LLMs often guess.

With RAG, responses are grounded in:

retrieved documents
factual context
external knowledge sources

This dramatically improves reliability.

Instead of answering purely from memory, the model answers using actual information.

3. RAG Allows AI to Work with Private Data

Most enterprise knowledge is private.

Examples include:

HR documents
customer records
legal contracts
internal reports
engineering documentation

This data does not exist publicly on the internet.

RAG allows companies to connect private knowledge sources directly to AI systems without retraining the model itself.

That became one of the biggest reasons enterprises adopted RAG so quickly.

4. RAG is More Practical Than Constant Fine-Tuning

Continuously fine-tuning large models is expensive.

RAG is much more scalable because:

you only update documents
you refresh retrieval indexes
you avoid retraining massive models repeatedly

For real-world systems, this approach is faster, cheaper, and easier to maintain.

5. RAG Enables Real-Time AI Applications

Modern businesses need AI systems that understand constantly changing information.

Examples include:

stock market assistants
legal research systems
healthcare AI
customer support bots

These systems need access to live and updated knowledge.

RAG makes that possible.

A Real-World Example

Imagine building a customer support chatbot for an e-commerce company.

Without RAG, the chatbot might:

provide outdated refund policies
invent shipping details
hallucinate product information

With RAG, the chatbot can:

retrieve the latest support documents
access updated policies
answer using current company information

The result is:

better customer experience
fewer hallucinations
more trustworthy AI systems

How RAG Changed AI Systems

Before RAG, most LLMs behaved like:

Static Knowledge Systems

After RAG, AI systems became:

Dynamic Knowledge Systems

This was a massive shift in AI architecture.

Instead of forcing models to memorize everything, systems could now:

retrieve information on demand
access external memory
work with continuously updated knowledge

That fundamentally changed how AI applications are designed.

Where RAG is Used Today

Today, RAG powers many modern AI products and enterprise systems.

Some common examples include:

enterprise AI assistants
AI customer support systems
legal document search tools
healthcare assistants
coding copilots
financial research platforms
internal company search systems

At this point, almost every serious enterprise AI system uses some form of retrieval.

One Important Thing to Remember

RAG is not a model.

It’s an architecture.

This is a very common interview question.

RAG combines:

retrieval systems
external knowledge sources
language models

to create smarter and more reliable AI applications.

Final Thoughts

Traditional LLMs alone are not enough for real-world AI systems.

Modern AI applications need:

current knowledge
factual grounding
private data access
reduced hallucinations
real-time updates

And RAG solves these problems extremely well.

That’s why Retrieval-Augmented Generation became one of the foundational building blocks of modern AI engineering.

The easiest way to remember RAG is this:

RAG allows LLMs to search for information before answering.

Angular State Management is Changing: Part 2 (And NgRx Isn’t What You Think Anymore)

Bhargav Patel — Fri, 08 May 2026 21:58:32 +0000

Let’s be honest, most Angular apps didn’t fail because of “bad state management”.

If you new to state management then revisit my part 1

They failed because we kept using NgRx for problems it was never meant to solve.

And now with Signals, that mistake is getting harder to justify.

Why NgRx Was Introduced

NgRx was introduced to solve architectural problems that services could not handle in large applications.

It brought a strict Redux-style model with a single source of truth and predictable state flow.

Every state change followed a defined path:

actions were dispatched, reducers updated state, selectors derived data, and components subscribed to changes.

This made state changes explicit, traceable, and easier to debug in large applications.

NgRx solved the problem of structure, predictability, and scalability.

The Problem with NgRx

While NgRx solved architectural issues, it also introduced complexity.

Even simple state updates required multiple steps: actions, reducers, selectors, and sometimes effects. This resulted in a lot of boilerplate code for simple features.

In many cases, developers were using NgRx even when the problem did not require that level of structure. This made small and medium applications unnecessarily complex.

NgRx solved structure, but often added overhead for simplicity.

Enter Signals and Signal-Based NgRx

With Signals and APIs like signalStore and selectSignal, Angular introduces a more direct way of handling state.

Instead of always going through actions and reducers, state can now be managed directly using signals inside a store. Components react automatically when state changes, without needing manual subscriptions or selector chains.

This significantly reduces boilerplate for simple and feature-level state.

At the same time, NgRx is not being removed. It is evolving to integrate Signals so both approaches can coexist.

State Flow Comparison

🟠 Old NgRx Flow (Redux Style)

Component
   ↓
Dispatch Action
   ↓
Action
   ↓
Reducer / Effect
   ↓
Store Updated
   ↓
Selector
   ↓
Observable Stream
   ↓
Component Subscription
   ↓
UI Update

🟢 New Signal-Based NgRx Flow

Component
   ↓
Call Store Method
   ↓
Signal State Update
   ↓
Computed Signals Recalculate
   ↓
UI Reacts Automatically

🟡 Hybrid Flow (Real-world Applications)

Component
   ↓
Dispatch Action
   ↓
Effect
   ↓
API / Async Logic
   ↓
Signal Store Update
   ↓
Signals
   ↓
Computed Signals
   ↓
UI Updates

Effects in a Signal-Based World

Effects remain an important part of NgRx, especially for:

API calls
Authentication flows
Complex async operations
Side effects

The difference is that effects can now directly update Signal-based state instead of always chaining actions.

This simplifies async flows while keeping structure where needed.

Selectors vs Signals

Selectors were previously used to derive and access state via observables.

Now, Signals reduce the need for selector subscriptions.

Instead of:

this.store.select(selectUsers)

You can use:

this.store.selectSignal(selectUsers)

Or directly consume signal state:

users = this.store.users();

This removes subscription management and simplifies component code.

When NgRx Is Less Necessary

With Signals, NgRx is no longer required for every type of state.

Simple UI state, feature-level state, and small shared state can now be handled using Signals or SignalStore without needing full Redux-style architecture.

This is one of the biggest practical changes in Angular state management.

When NgRx Still Matters

NgRx is still valuable for:

Large-scale applications
Complex state interactions
Multi-feature coordination
Strict debugging and traceability
Heavy asynchronous workflows

Signals do not replace these architectural needs because they focus on reactivity, not orchestration.

Why NgRx Is Moving Toward Signals

According to the official NgRx Signals approach, the goal is to reduce boilerplate, improve developer experience, and modernize state management with Angular’s reactive primitives.

NgRx is not being replaced — it is being evolved.

👉 https://ngrx.io/guide/signals

Final Thoughts

Angular state management is no longer about choosing one approach over another.

Services handled basic sharing.
NgRx introduced structure and predictability.
Signals introduce simplicity and reduce unnecessary complexity.

Now all three coexist, each solving a different level of problem.

Signals are not replacing NgRx. They are simply removing the need to use it everywhere.

Redux / NgRx State Management in Angular: Part 1

Bhargav Patel — Thu, 07 May 2026 23:50:44 +0000

Managing state in Angular applications becomes difficult as applications grow larger and more complex. Redux and NgRx provide a structured and predictable way to handle shared application state.

This article explains:

What Redux/NgRx solves
Core concepts
When to avoid it
When it becomes useful
Why established libraries are preferred

Understanding State in Angular

State in Angular applications can be anything like:

Router state
Component-local state
Shared state between components

In small applications, services are often enough for sharing data. However, as applications scale, several problems begin to appear:

Complex component relationships
Difficult state synchronization
Duplicate state across components
Unpredictable updates

Redux-style architecture solves this problem by introducing a centralized global store.

The store becomes the single source of truth for application state.

Core Redux / NgRx Concepts

Redux/NgRx is built around a few important concepts:

Store
Actions
Reducers
Effects
Selectors

Store

The store contains the entire application state in one centralized location.

Benefits of using a store:

Single source of truth
Predictable data flow
Easier debugging
Better state sharing

Components subscribe only to the state they need instead of maintaining separate copies.

Actions

Actions describe events that happen inside the application.

Actions are plain JavaScript objects that usually contain:

type
optional payload data

Example:

{
  type: 'LOAD_USERS',
  payload: users
}

Actions help create a clear and trackable update flow.

Reducers

Reducers are functions that receive:

Current state
Action

Reducers return a new updated state.

Important rules for reducers:

Must be pure functions
Must not contain side effects
Should not perform:
- API calls
- Local storage operations
- Async tasks

Reducers should only focus on transforming state.

Effects (NgRx)

Reducers should only update state and remain pure functions. They should not perform API calls, async operations, or side effects.

NgRx uses Effects to handle side effects separately.

Common use cases for effects:

API requests
Authentication
Local storage updates
Async operations
Notifications

Effects help keep components clean and business logic centralized.

Selectors

Selectors are functions used to read data from the store.

Instead of directly accessing store data inside components, selectors provide a reusable and organized way to retrieve state.

Benefits of Selectors:

Cleaner components
Reusable queries
Better maintainability
Derived/computed state
Improved performance through memoization

Selectors make store access predictable, reusable, and easier to maintain in large applications.

Example Flow of Redux / NgRx

Understanding Redux/NgRx becomes easier by following a simple flow.

Example scenario:
A user opens a page and clicks Load Users.

Step 1 — Component Dispatches Action

The component does not directly call the API.

Instead, it dispatches an action.

this.store.dispatch(loadUsers());

Action:

export const loadUsers = createAction('[Users] Load Users');

Purpose:

Describe what happened
Start the state update process

Step 2 — Effect Handles API Call

The effect listens for the dispatched action.

loadUsers$ = createEffect(() =>
  this.actions$.pipe(
    ofType(loadUsers),
    switchMap(() =>
      this.userService.getUsers().pipe(
        map(users => loadUsersSuccess({ users }))
      )
    )
  )
);

Purpose:

Perform async operations
Call APIs
Keep reducers pure

Step 3 — Success Action Is Dispatched

After data is received from the API, another action is dispatched.

export const loadUsersSuccess = createAction(
  '[Users] Load Users Success',
  props<{ users: User[] }>()
);

Purpose:

Notify application that data was loaded successfully

Step 4 — Reducer Updates Store

Reducer receives:

Current state
Action

Then returns updated state.

on(loadUsersSuccess, (state, { users }) => ({
  ...state,
  users
}))

Purpose:

Update application state
Keep state immutable and predictable

Step 5 — Selector Reads Data

Selectors provide clean access to store data.

export const selectUsers = createSelector(
  selectUserState,
  state => state.users
);

Purpose:

Read state
Reuse state queries
Keep components clean

Step 6 — Component Receives Updated Data

Component subscribes to selector data.

users$ = this.store.select(selectUsers);

Purpose:

Automatically receive updated state
Keep UI reactive

Complete Redux / NgRx Flow

Component
   ↓
Dispatch Action
   ↓
Effect Handles API Call
   ↓
Success Action
   ↓
Reducer Updates Store
   ↓
Selector Reads State
   ↓
Component Updates UI

This predictable flow is one of the biggest advantages of Redux/NgRx in large Angular applications.

When NOT to Use Redux / NgRx

Redux/NgRx is not always the right solution.

In many projects, it can introduce unnecessary complexity and slow development.

1. Small Projects or Prototypes

Avoid Redux/NgRx when:

Applications are small
Requirements change frequently
Features are experimental

Reasons:

Too much boilerplate
Slower development
Architecture overhead is unnecessary

2. Shared UI or Component Libraries

Avoid embedding Redux inside reusable component libraries.

Reasons:

Forces every consuming project to use Redux
Different projects may not require global state management
Reduces flexibility

3. Teams Without Redux Experience

Avoid Redux/NgRx in important projects if the team lacks experience.

Possible issues:

Difficult debugging
Poor architecture decisions
Hard-to-maintain code
Incorrect implementation patterns

State management libraries require strong architectural understanding.

4. Applications Already Using Apollo Client

Apollo Client already provides state management for GraphQL applications.

Using Redux together with Apollo may create:

Multiple sources of truth
Synchronization issues
Extra complexity

In many GraphQL applications, Apollo alone is enough.

Common Drawbacks of Redux / NgRx

Even small features may require:

Actions
Reducers
Effects
Selectors
Store updates

This increases:

Boilerplate
Development time
Learning curve

For simple applications, this overhead may not be worth it.

When Redux / NgRx Makes Sense

Redux/NgRx becomes valuable in large and state-heavy applications.

1. Large Applications

Good fit for applications with:

Hundreds of components
Deep component trees
Complex shared state

Benefits:

Centralized architecture
Predictable updates
Easier debugging
Better maintainability

2. Undo / Redo Functionality

Redux works well for applications requiring:

Undo functionality
Redo functionality
Reverting changes
Optimistic UI updates

Reason:

State history can be tracked and restored easily

3. State Persistence

Redux is useful when applications need to:

Save application state
Restore sessions
Synchronize state across clients
Store state in local storage

Redux naturally supports state serialization.

4. Large Legacy System Migrations

Redux can help when:

Migrating large systems
Scaling existing applications
Replacing fragile custom state patterns

Using a structured architecture early helps reduce long-term complexity.

Signs That Redux May Be Needed

Redux/NgRx becomes worth considering when:

Multiple services start coordinating state manually
State synchronization becomes difficult
Custom state patterns begin appearing
Debugging shared data becomes painful

These are common indicators that application complexity is increasing.

Why Established Libraries Are Better

Using mature libraries like Redux/NgRx provides:

Community support
Better documentation
Standardized architecture
Easier onboarding
Long-term maintainability

Custom in-house state solutions often become:

Poorly documented
Difficult to scale
Hard for new developers to understand

Established libraries reduce long-term architectural risk.

Final Thoughts

Redux/NgRx should be treated as an architectural decision rather than a default choice.

Avoid Redux/NgRx When

Applications are small
Rapid development is important
Requirements change frequently
Apollo Client already manages state

Consider Redux/NgRx When

Applications are large and complex
Shared state becomes difficult to manage
Predictability is important
Undo/restore features are required
Long-term scalability matters

The additional complexity of Redux/NgRx is justified only when application scale and state management needs become significant.

Edit: POV based on signal

Resolving the "0308010C: Digital Envelope Routines::Unsupported" Error in Angular Apps with Node.js 17+

Bhargav Patel — Tue, 19 Dec 2023 21:28:30 +0000

Deploying Angular applications is typically a smooth process, but encountering errors like "0308010C: digital envelope routines::unsupported" can be a source of frustration. In this blog post, we'll delve into the causes of this error and provide comprehensive solutions to address it, ensuring a seamless deployment of your Angular app with Node.js 17+.

This is the whole error,

Error: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:71:19)
    at Object.createHash (node:crypto:133:10)
    at module.exports (/vercel/path0/node_modules/webpack/lib/util/createHash.js:135:53)
    at NormalModule._initBuildHash (/vercel/path0/node_modules/webpack/lib/NormalModule.js:417:16)
    at handleParseError (/vercel/path0/node_modules/webpack/lib/NormalModule.js:471:10)
    at /vercel/path0/node_modules/webpack/lib/NormalModule.js:503:5
    at /vercel/path0/node_modules/webpack/lib/NormalModule.js:358:12
    at /vercel/path0/node_modules/webpack/node_modules/loader-runner/lib/LoaderRunner.js:373:3
    at iterateNormalLoaders (/vercel/path0/node_modules/webpack/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
    at Array.<anonymous> (/vercel/path0/node_modules/webpack/node_modules/loader-runner/lib/LoaderRunner.js:205:4)
    at Storage.finished (/vercel/path0/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:55:16)
    at /vercel/path0/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:91:9
    at /vercel/path0/node_modules/graceful-fs/graceful-fs.js:123:16
    at FSReqCallback.readFileAfterClose [as oncomplete] (node:internal/fs/read_file_context:68:3) {
  opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
  library: 'digital envelope routines',
  reason: 'unsupported',
  code: 'ERR_OSSL_EVP_UNSUPPORTED'
}
Node.js v18.12.1

Causes of the "0308010C: Digital Envelope Routines::Unsupported" Error

The error message you're facing originates from changes introduced in Node.js 17 and OpenSSL3, affecting the initialization context of the md family, including md4. This discrepancy may lead to the manifestation of the "0308010C: Digital Envelope Routines::Unsupported" error.

Also, Refer to the OpenSSL 3.0 upgrade guide for further insights.

Solutions to Resolve the Error

Solution 1: Upgrade NPM Packages

To address the error, consider upgrading Node.js packages causing the issue to the latest version. Run the following commands in your terminal:

npm audit fix

or, if needed:

npm audit fix --force

This will automatically identify and fix packages using outdated OpenSSL versions. Be cautious with the --force option, as it may introduce breaking changes.

Solution 2: Update Webpack

Upgrade Webpack to version 5 (specifically v5.61.0) using the following commands:

npm i webpack@latest

or, for Yarn users:

yarn add webpack@latest

Alternatively, update your webpack.config.js with the provided code snippet.

const path = require("path");
const crypto = require("crypto");
const crypto_orig_createHash = crypto.createHash;
crypto.createHash = algorithm => crypto_orig_createHash(algorithm == "md4" ? "sha256" : algorithm);

module.exports = {
  entry: "./src/index.js",
  output: {
    filename: "app.js",
    hashFunction: "sha256",
    path: path.resolve(__dirname, "dist")
  },
  devServer: {
    contentBase: path.join(__dirname, "dist"),
    port: 9000
  },
  mode: "development"
};

Conclusion

By following these solutions, you can overcome the "0308010C: digital envelope routines::unsupported" error and successfully deploy your Angular app with Node.js 17+. Ensure your Node.js version is LTS, upgrade relevant packages, and make necessary adjustments to your Webpack configuration. Happy coding!