DEV Community: bytebantz

The Most Confused Concepts in Agentic AI

bytebantz — Mon, 26 Oct 2026 15:46:49 +0000

Originally published on Medium.

In this article we are going to cover 4 commonly confused concepts in agentic AI.

Understanding these distinctions will help you avoid confusing LLM-powered workflows with AI agents.

1. Using an LLM doesn’t make a system an AI Agent.

What makes a system an AI Agent is the LLM’s role in deciding and directing the execution process, not simply whether the system uses an LLM.

To understand why, we are going to distinguish between an agentic workflow and an AI agent.

Both fall under Agentic AI.

The difference is how much control the LLM has over the execution process.

1. Agentic Workflow

An agentic workflow is an AI system where the developer defines the execution path in advance, and the LLM cannot modify or redesign that path.

However, the LLM may make decisions within the execution process, such as classifying user intent or generating a response, but the surrounding code controls how those steps are connected and executed.

Example: “What is the price of an iPhone 15?”

User message
     ↓
Classify intent        ← LLM identifies "get_product_price"
     ↓
Price node             ← Code retrieves the price
     ↓
Response node          ← LLM generates the reply
     ↓
"The iPhone 15 costs $1000."

2. AI Agent

An AI agent is an AI system where the LLM dynamically decides which steps to take, which tools to use, and whether to continue, based on the task and the results it observes.

Unlike a workflow, the LLM can determine and adjust its own execution path.

Example: “I want the black iPhone, the newer one, if it’s in stock.”

User message
     ↓
Agent (LLM) decides to search for the product
     ↓
Calls search_products("black iPhone")
     ↓
Receives: iPhone 14, iPhone 15, iPhone 15 Pro
     ↓
Agent decides to check the latest model first
     ↓
Calls check_stock("iPhone 15 Pro", color="black")
     ↓
Receives: Out of stock
     ↓
Agent decides to check another suitable model
     ↓
Calls check_stock("iPhone 15", color="black")
     ↓
Receives: 12 in stock
     ↓
Agent decides it has enough information
     ↓
Responds to the user

In the above example, the LLM determines which tool to call next based on the user’s request and the results returned by previous tool calls.

2. All agents are agentic AI, but not all agentic AI systems are agents.

The word agentic AI sounds like it means “has an agent in it.”

So people assume any agentic AI system is an agent.

An agentic AI system is a system where an LLM’s decisions influence what the system does, either within steps defined by the developer (a workflow) or by dynamically directing the steps itself (an agent).

There are two common ways to design an agentic AI system:

Agentic Workflow: The developer defines the execution path.
AI Agent: The LLM dynamically decides which actions to take next based on the task and the results of previous actions.

Both can be considered agentic AI systems under this broad definition, although terminology varies across sources.

For example, a LangGraph workflow that uses an LLM to classify a request and routes it through developer-defined steps is an agentic AI system, but not necessarily an AI agent.

A LangGraph agent that uses an LLM to dynamically choose tools, observe their results, and decide what to do next is both an AI agent and an agentic AI system.

3. An agent is a loop, not a single call

An AI agent doesn’t simply call an LLM once and finish.

It repeatedly makes decisions, takes actions, observes the results, and decides what to do next until it considers the task complete.

An agent uses the result of one step to determine its next step.

The loop is what allows an agent to handle tasks that require multiple actions, respond to unexpected results, and correct its approach along the way.

Basic agent loop

Press enter or click to view image in full size

Decide: The LLM looks at the request and everything it knows so far, and picks the next action.
Act: The agent uses a tool to carry out that action.
Observe: The tool’s result is added to the agent’s context as new information.
Decide again: The LLM uses the new information to determine what should happen next. It might call another tool, repeat an earlier action, or conclude that the task is finished.

The loop ends when the LLM gives a final answer instead of calling a tool, or when it hits a limit you set, like a maximum number of turns or an error it can’t recover from.

4. Tool calling alone doesn’t make a system an agent.

Tool calling is a capability that allows an LLM to call an external function or API to perform an action.

What determines whether the system behaves as an agent is what or who controls the decisions surrounding that tool call.

If the developer decides when a tool runs and what happens after, it’s still a workflow.

It becomes an agent when the LLM decides whether to call the tool, which tool to call, and what to do with the result.

Conclusion

In conclusion, understanding the difference between AI agents and agentic workflows comes down to who controls execution.

Mastering Datadog AI Agent Observability: A Beginners Guide

bytebantz — Fri, 23 Oct 2026 06:21:05 +0000

Agent Observability Is a Must-Have for LLM Applications

Originally published on Medium.

When something goes wrong, identifying the actual cause isn’t always straightforward due to non-deterministic nature of LLM applications.

Adding logs helps, but logs alone often aren’t enough for LLM applications.

You might have no visibility of the complete workflow if you are using logs alone.

This is where Datadog Agent Observability comes in.

Datadog gives you end-to-end visibility into your AI application’s execution.

Instead of guessing what happened, you can trace a user’s request through out the complete execution flow.

Implementing Datadog agent observability involves 3 core components:

⚪ Traces — shows the complete journey of a single request.

⚪🟡 Spans — represent individual operations within a trace.

⚪🟡⚪ Instrumentation is the process of capturing this information automatically or manually and sending it to Datadog for analysis.

Press enter or click to view image in full size

1. TRACE

A trace represents the complete execution path of a single request handled by the LLM application.

A trace captures everything that happens while the application processes that request, including LLM calls, agent decisions, tool calls, and other operations.

A trace can contain multiple spans, where each span represents an individual operation within the overall request.

LLM Agent workflow

An agent trace groups together all workflows and contextual operations such as the tool calls and reasoning steps executed by an agent to complete a user request.

For example, a user asks:

"What's the weather in Nairobi?"

The AI agent might:

Receive the user’s request.
Call an LLM to determine what to do.
Call a weather tool.
Send the weather data back to the LLM.
Generate the final response.

All of these operations can be represented within the same trace.

Trace Structure Example:

Press enter or click to view image in full size

TRACE
────────────────────────────────
trace_id: trace_001
────────────────────────────────

Agent / Workflow Span
span_id: span_001
trace_id: trace_001
│
├── LLM Span
│   span_id: span_002
│   trace_id: trace_001
│
│   Input:
│   "What's the weather in Nairobi?"
│
│   Output:
│   "I need to check the weather."
│
├── Tool Span
│   span_id: span_003
│   trace_id: trace_001
│
│   Input:
│   {
│     "location": "Nairobi"
│   }
│
│   Output:
│   {
│     "temperature": 23,
│     "condition": "Partly cloudy"
│   }
│
└── LLM Span
    span_id: span_004
    trace_id: trace_001

    Input:
    Weather data from tool

    Output:
    "It's 23°C and partly cloudy in Nairobi."

────────────────────────────────

TRACE SAMPLING

Trace Sampling is a method datadog uses to determine the number of traces to retain for observability.

Agent Observability billing is based on the volume of spans sent.

Setting a sample rate is a direct way to control the cost for agent obervability.

Example:

Suppose your application receives:
10,000 agent requests


And each request generates approximately:
10 spans

You could therefore send to DataDog approximately:
10,000 × 10 = 100,000 spans

Since Agent Observability billing is based on the volume of spans sent, this can become expensive at scale.

This is where trace sampling comes in.

You can configure the sample rate (a float between 0.0 and 1.0)

SETTING A SAMPLE RATE

Suppose we configure:

sample rate = 0.5

The above sample rate means approximately 50% of traces (50,000) will be retained instead of 100,000.

While trace sampling allows you to control the ingestion volume and storage costs for your individual traces and spans, it does not impact these operational metrics

Such metrics includes:

🟡 Token metrics

🟡🟡 Cost metrics

🟡🟡🟡 Performance metrics

Press enter or click to view image in full size

2. SPAN

A span represents a single operation in a trace.

A span serves as the fundamental building block of a trace

Press enter or click to view image in full size

1. SPAN ATTRIBUTES

A span attribute describes the operation represented by the span.

Span attributes represent the content of the work being done within the span

For example:
Suppose the span represents this operation:

SELECT * FROM users WHERE id = 123;

The span could contain the following span attributes:

@db.system:postgres
@db.operation:SELECT
@db.table:users

WHERE DO SPAN ATTRIBUTES COME FROM?

Automatic instrumentation

Datadog’s APM libraries can automatically collect information.

This means there is no need to write code to record values for such fields.

For example, your application makes an HTTP request:

GET /products

The instrumentation may automatically record things like:

@http.method:GET
@http.route:/products

2. Manual/custom instrumentation

This means we have to explicitly specify the fields to record.

This is useful because it allows you to put business-specific information into your traces.

For example:
Suppose your application calculates the shopping cart value:

cart_total = 1299.99

You might instrument your application so the span contains:

@cart.total:1299.99

Example:

from ddtrace import tracer

# Get the current active span
span = tracer.current_span()
if span:
    # Manually set a custom attribute
    span.set_tag('cart.total', 1299.99)

RESERVED SPAN ATTRIBUTES

Datadog has certain reserved span attributes

Reserved span attributes are automatically instrumented and are available on every span.

You do not need to perform any manual setup to ensure these attributes are collected for your traces:

env: environment name (e.g. production) where the service is running.

service: The name of the service that generated the span.

operation_name: The specific name of the operation being performed.

resource_name: A human-readable name for the resource associated with the operation (e.g., an endpoint path or a database query).

status: The operational status of the span (e.g., ok or error).

span_id: The unique identifier for that specific span.

trace_id: The unique identifier that groups all spans belonging to the same request or workflow.

timestamp: The exact time the span occurred.

type: The category of operation (e.g., web, db, or cache).

link: References connecting the span to other spans or traces.

ingestion_reason: The reason why the trace or span was retained by the Datadog ingestion pipeline.

When working with reserved attributes, don’t put @ in front.

For example:

service:checkout
env:production
status:error

rather than:

@service:checkout
@env:production

2. SPAN TAGS

Span tags are contextual information about where the span came from for example infrastructure/environment context.

Tags don’t require @.

For example:

hostname:web-server-17
availability-zone:us-east-1a
cluster-name:production-cluster
container_name:api-frontend

These tags provide context about the infrastructure or orchestration environment where the service is running

3. ANNOTATIONS

Annotations are additional pieces of context that you can attach to a span to make the trace more useful for analysis.

Annotations describe business-specific context about an operation.

This helps explain operations from a business perspective.

Example:

A checkout span could have annotations like customer_tier=premium or order_type=subscription.

Spans automatically capture common information such as: duration, status, errors, input, output

But sometimes you want to add your own context.

Example:
Suppose you’re building a customer-support AI.

You may want to know additional information about each request, such as:

In Datadog, annotations are filtered using attribute search syntax, where attributes are prefixed with an @ symbol.

@customer_tier:premium 
@language:en 
@ticket_category:refund 
@department:electronics

Using ddtrace, you can attach this business context to the current span with LLMObs.annotate():

from ddtrace.llmobs import LLMObs
from ddtrace.llmobs.decorators import tool
@tool
def handle_support_request(message, customer_id):
    response = process_support_request(message, customer_id)
    LLMObs.annotate(
        tags={
            "customer_tier": "premium",
            "language": "en",
            "ticket_category": "refund",
            "department": "electronics"
        }
    )
    return response

The resulting span now contains both its normal observability information and your additional business context:

Tool Span: handle_support_request
────────────────────────────────────────
Duration:
    4.2 sec
Status:
    OK
Input:
    "I want a refund for my headphones."
Output:
    "I'll help you process your refund..."
Annotations:
    customer_tier:   premium
    language:        en
    ticket_category: refund
    department:      electronics
────────────────────────────────────────

Using annotations, allow you to filter, group, and analyze traces based on your application’s specific business context.

For example, you could filter traces where:

@customer_tier:premium

to investigate premium-customer requests.

SPANS CATEGORIZATION

Datadog allows spans to be categorized according to the type of operation they represent.

Instead of representing every operation as a generic span (Span), Datadog allows spans to be categorized according to the type of operation they represent:

Categorizing spans makes your traces:

🟢- Easier to understand

🟢🟢- Easier to troubleshoot

🟢🟢🟢- Easier to analyze

Press enter or click to view image in full size

TYPES OF SPANS

Press enter or click to view image in full size

1. Agent Span

An Agent is an AI system that can decide what actions it needs to take and in what order to accomplish a goal.

An Agent span represents the complete execution of an AI agent.

Example:
Consider a travel-planning agent that helps a user plan a trip.

The agent can be implemented as:

from ddtrace.llmobs.decorators import agent
from openai import OpenAI

llm = OpenAI()

# Define tools
def search_flights(destination):
    # Tool execution logic
    pass

def search_hotels(destination):
    # Tool execution logic
    pass

def check_weather(destination):
    # Tool execution logic
    pass

@agent
def plan_trip(customer_query):
    # The LLM analyzes the request and decides which tools to use
    llm_response = llm.chat.completions.create(
        model="gpt-4",
        messages=[{"role": "user", "content": customer_query}],
        tools=[
            search_flights,
            search_hotels,
            check_weather
        ]
    )

    return llm_response.choices[0].message.content

2. Root Span

A root span is defined by its position in the trace hierarchy.

A span is considered a root span, if it is the span at the very top, with no parent span.

An agent span may be the root span, particularly when the agent execution is the top-level operation you’re tracing.

But if the agent is itself invoked by another operation — such as a workflow — it can be a child span.

Example:

def travel_workflow(customer_query):
    validate_request(customer_query)

    plan_trip(customer_query)

    save_itinerary()
    return "Workflow complete"

Conceptually, the trace looks like this:

ROOT SPAN: travel_workflow
│
├── Span: validate_request
│
├── Agent Span: plan_trip
│   │
│   ├── LLM Span: understand_requirements
│   │
│   ├── Tool Span: search_flights
│   │
│   ├── Tool Span: search_hotels
│   │
│   ├── LLM Span: compare_options
│   │
│   ├── Tool Span: check_weather
│   │
│   └── LLM Span: generate_itinerary
│
└── Span: save_itinerary

3. Workflow Span

A workflow span represents the execution of a complete, high-level process within an application.

A workflow in Agents Observability is a predefined sequence of operations that may include LLM calls, tool calls, data processing, and other steps required to complete a task.

A Workflow Span represents the complete execution of the workflow.

Unlike an Agent, which can autonomously decide which actions to take, a workflow generally follows a predefined sequence of operations defined by the application.

Example:
Consider a customer support ticket workflow:

The workflow can be implemented using the @workflow decorator:

from ddtrace.llmobs.decorators import workflow, llm, tool, retrieval, task

@tool
def retrieve_customer_data(customer_id):
    # Logic to fetch customer information from an external database
    pass

@llm
def classify_ticket(ticket):
    # LLM call to categorize the support ticket
    pass

@retrieval
def search_knowledge_base(category):
    # Logic to search a vector database or external KB
    pass

@llm
def generate_response(ticket, customer_data, knowledge):
    # LLM call to generate the ticket response
    pass

@task
def send_response(response):
    # Logic to format/send the response (no external call)
    pass

@workflow
def process_support_ticket(ticket):
    customer_data = retrieve_customer_data(ticket.customer_id)
    ticket_category = classify_ticket(ticket)
    knowledge = search_knowledge_base(ticket_category)
    response = generate_response(ticket, customer_data, knowledge)
    send_response(response)

    return response

4. Task Span

A task span represents an individual processing operation performed by an application that don’t call an external service.

It is typically used for application-level logic that happens within the application itself, rather than an operation that calls an external service.

Example:
Consider an application that calculates a discount for a customer.

The task can be implemented using the @task decorator:

from ddtrace.llmobs.decorators import task

@task
def calculate_discount(price, customer_type):
    if customer_type == "premium":
        return price * 0.80
    return price

5. LLM Span

An LLM span represents an LLM call.

It captures the model invocation, including the model used, input, output, token usage, latency, and status.

For example:

from ddtrace.llmobs.decorators import llm

@llm(model_name="gpt-4")  # model_name is optional
def generate_product_description(product_data):
    response = llm.complete(
        prompt=f"Generate description for: {product_data['name']}"
    )
    return response.text

The above example could be represented as:

6. Tool Span

A tool represents calls to external services like databases, APIs made by an AI application.

A tool span represents the details of the external operation, such as what tool was called, the input provided, the result returned, and how long the operation took.

Example:
Consider an AI customer-support assistant, that calls an external API to fetch order details:

from ddtrace.llmobs.decorators import tool

@tool
def fetch_inventory_status(product_id):
    inventory = database.query(
        "SELECT quantity, location FROM inventory WHERE product_id = ?",
        product_id
    )
    return inventory

7. Embedding span

An Embedding Span represents the operation of converting text or other data into an embedding vector using an embedding model.

Example:

from ddtrace.llmobs.decorators import embedding

@embedding(model_name="text-embedding-ada-002")  # model_name is required, model_provider is optional
def generate_product_embedding(product_text):
    vector = embedding_model.encode(product_text)
    return vector.tolist()

8. Retrieval Span

A retrieval span represents the operation of searching for and retrieving relevant information from a data source, such as a vector database.

The retrieval span captures the search operation and the information returned by it.

Example:

For example, in an AI shopping assistant, a user might ask:

“Find me a black running shoe under $100.”

The retrieval operation can be instrumented using:

from ddtrace.llmobs.decorators import retrieval

@retrieval
def search_product_catalog(query):
    query_vector = generate_embedding(query)
    results = vector_db.similarity_search(query_vector, top_k=5)
    return results

Conclusion

Agent observability helps you see what happens inside your AI application when it processes a request.

Datadog uses traces, spans, and instrumentation to help you follow a request from beginning to end, inspect individual steps, and find out why something failed or took too long.

Logs are useful, but observability gives you a clearer picture of how the different parts of your application work together.

Full Jev Tutorial for Beginners

bytebantz — Fri, 23 Oct 2026 06:17:27 +0000

Originally published on Medium.

Jev is an AI model created by Diogo Almeida who co-invented ChatGPT.

Jev is apparently 200x faster and 400x cheaper than regular AI models.

But what makes Jev interesting isn’t just its speed or cost. It’s how it approaches AI.

Jev is built for software, not humans.

This means Jev is designed to return decisions that an application can act on directly, rather than text responses written for a person to read.

A general-purpose LLM can understand language, extract information, reason about problems, generate content, and transform unstructured input into structured output.

But in most cases, your application might only need a specific decision.

Imagine a customer support system that needs to determine which team should handle a complaint.

With a conventional LLM, you might prompt it to return JSON containing the team name. Your application then parses the response and extracts the decision.

Jev approaches the task differently.

You define the decisions your application needs, the accepted answer types, and the criteria for evaluating each answer.

Jev then returns structured decision results that your application can act on directly.

Instead of generating text that describes a decision, Jev is designed to return the decision itself.

Use Case Example:

Imagine you work at an online shop. Customers send complaints like these:

Press enter or click to view image in full size

You don’t want an employee to read every complaint and decide what happens next.

Jev helps your application do some of that work automatically and make decisions from the customer’s message.

Instead of writing a text response like most general LLMs explaining the complaint, Jev returns structured decisions that your application can use.

Press enter or click to view image in full size

When making a decision with Jev, you are required to provide 2 things:

🟡 State — the information Jev should evaluate.

🟡 🟡 Questions — the decisions you want Jev to make about that information.

Each question has 3 main parts:

type: the kind of answer you expect.
instructions: what you want Jev to determine.
criteria: how to interpret the possible answers.

"questions": {
    "is_bug": {
        "type": "noul",
        "instructions": "Is the customer reporting a software defect?",
        "criteria": {
            "true": "The customer describes broken or unexpected product behavior.",
            "false": "The customer is asking a question or requesting a feature."
        }
    }
}

Step 1: Give Jev the customer’s complaint

"state": {
  "customer_tier": "enterprise",
  "ticket": "My checkout page shows a blank screen after I click Pay. I have tried two browsers."
}

Think of state as a box containing information about the problem.

Step 2: Ask Jev the first question — is it a bug?

Your application needs to know whether the customer is reporting a software defect.

To help Jev determine exactly counts as a bug, you provide criteria:

"criteria": {
  "true": "The customer describes broken or unexpected product behavior.",
  "false": "The customer is asking a question or requesting a feature."
}

Step 3: Ask Jev the second question — which team should handle it?

Knowing that something is broken isn’t enough.

Your company may have different teams:

🔴Payments team

🟠Frontend team

🟡Account team

You need Jev to select one of them.

"criteria": {
  "payments": "Checkout, billing, or payment processing issues.",
  "frontend": "Rendering, layout, or browser compatibility issues.",
  "account": "Login, permissions, or profile issues."
}

Complete implementation

You don’t need to make one request to determine whether the complaint describes a bug and another to identify the responsible team.

Both questions can be sent in the same request.

Files:

jev-demo/
├── triage.py          the demo
├── requirements.txt   one dependency: requests

Setup

You need Python 3.9 or newer and an OpenRouter API key from https://openrouter.ai/settings/keys.

Create a virtual environment and install the dependency

macOS / Linux

cd jev-demo
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Windows (PowerShell):

cd jev-demo
python -m venv .venv
.venv\Scripts\Activate.ps1
pip install -r requirements.txt

Set your API key

macOS / Linux:

export OPENROUTER_API_KEY=sk-or-...

Windows (PowerShell):

$env:OPENROUTER_API_KEY = "sk-or-..."

Run ▶

python triage.py

What Jev might return:

Bug probability: 0.96
Team: payments (confidence 0.72)
  payments: 0.81
  frontend: 0.19
  account: 0.00
Decision: bug -> route to the payments team

Types in Jev

Types Supported by Jev

A type tells Jev what kind of answer you want it to produce.

Press enter or click to view image in full size

⚪ Noul — Yes or no

Use it when your question requires a boolean response.

Example: Is this complaint reporting a software bug?

⚪ 🟡 Choice — Select an option

Use it when your question has several possible answers and you want one selected.

Example: Which team should handle the complaint?

⚪ 🟡⚪ Score — An ordered scale

Use it when your question asks for a position on a scale with ordered criteria.

Example: How urgent is the complaint?

Knowledge Check

Press enter or click to view image in full size

LLM + Jev NOT LLM vs Jev

In an e-commerce AI agent, when an LLM is the reasoning engine of your agent, one call usually does two jobs.

It extracts the entities, and it decides what the user wants (intent).

In the following example we ask for both entities and intent in one JSON response:

system_prompt = """
...
Return ONLY JSON matching this exact structure:
{
  "reasoning": "Short explanation of what was detected.",
  "entities": {
    "product_names":   ["item name 1", "item name 2"],
    "quantity":        3 | null,
    "color":           "red" | null,
    "size":            "10" | null,
    "cart_action":     "add" | "modify" | "view" | null,
    "list_categories": false,
    "list_orders":     false,
    "checkout_intent": false,
  }
}
"""

Using an LLM alone for both jobs is prone to errors.

For example the model might return:

{
  "product_names": ["Nike shoes"],
  "quantity": 2,
  "cart_action": "add_to_cart"
}

Your application expects “add”, but the model returns “add_to_cart”.

The meaning is clear to a human, but your code might reject the value because it is not the expected value.

Instead, use the LLM for entity extraction and Jev for decision-making.

Instead of asking the LLM to extract entities and decide the user’s intent in one JSON response, let it extract only the entities:

However you still parse and validate the LLM’s JSON, but it is now a smaller response that holds only entities.

{
  "product_names": ["item name 1", "item name 2"],
  "quantity":      3 | null,
  "color":         "red" | null,
  "size":          "10" | null
}

Jev then handles the decisions by evaluating the message against predefined options and returning probabilities for each choice.

"questions": {
  "intent": {
    "type": "choice",
    "instructions": "What does the shopper want to do?",
    "criteria": {
      "add_to_cart":     "Wants to add a product to the cart.",
      "modify_cart":     "Wants to change or remove something in the cart.",
      "view_cart":       "Wants to see the cart.",
      "checkout":        "Wants to check out or pay.",
      "list_orders":     "Wants to see past orders.",
      "list_categories": "Wants to see the product categories."
    }
  }
}

Press enter or click to view image in full size

If Jev runs first and identifies an intent that requires no entity extraction, such as view_cart, checkout, or list_orders, you can skip the LLM call entirely for that turn.

This means you save on:

🟡LLM API costs: No charge for an unnecessary model call.

🟡Latency: The user doesn’t have to wait for the LLM to extract entities that are not needed.

🟡Token usage: No input or output tokens spent on that LLM call.

Jev vs. ML Classifiers (Random Forest)

A classifier basically is a system that takes something as input and assigns it to a category.

A random forest and Jev can both look at a customer’s message and pick an intent: add_to_cart, view_cart, checkout or list_orders.

Both choose from a fixed set of answers, both return probabilities, and neither writes text.

Press enter or click to view image in full size

For Random Forest, you have to provide examples and answers, train the model, and use the resulting model for its learned task.

For instance, if you provide many messages labeled checkout. The model learns patterns from those examples and uses them to classify new messages.

However, if the task changes substantially, you may need to train another model.

For Jev, TypeSafe has already trained the general model.

You just have to describe the task and its possible answers in plain English when you make a request.

If the task changes, you can usually change the question and options instead of training a new model.

Conclusion

JEV is not trying to replace general LLM models such as GPT, Gemini or Claude.

JEV is built to generate decisions.

Use JEV when your app needs to choose and LLMs when you need to generate text responses.

PHP Got Hacked by AI

bytebantz — Fri, 23 Oct 2026 06:01:41 +0000

Originally published on Medium.

At 9:55 p.m. on Wednesday, October 21, 2026, in Tokyo, Japan, the prime minister Sanae Takaichi urged website owners to check whether they ran PHP and apply a security fix as soon as it became available.

If they couldn’t patch, she advised temporarily disabling parts of their sites.

About an hour later, PHP released fixes for two critical vulnerabilities.

The US National Security Agency issued an even drastic warning: if you couldn’t patch, take your systems OFFLINE.

The story so far

To see why, you need to understand the whole incident, and it starts long before AI.

In 2004, security researcher Stefan Esser found the first remote flaw in how PHP handles its memory limit.

In 2020, someone filed PHP bug #78876, noting that long form variables could make PHP run out of memory.

It was treated as harmless.

In 2024, an audit by OSTIF and Quarkslab rediscovered the same out-of-memory problem.

No one could prove it was exploitable, so it stayed unfixed (Calif).

What the bugs actually are.

PHP stops a request when it runs out of memory.

If that happens halfway through building an internal data structure, PHP skips its cleanup.

The memory is freed, but pointers to it survive.

The next request handled by the same worker then trusts that freed memory, which an attacker has filled with their own data.

Calif showed that one crafted upload, under PHP’s default 8 MiB upload limit, can exhaust its default 128 MiB memory limit.

No login is needed, and no bug in the website’s own code.

PHP filed the flaws as two CVEs: CVE-2026–109618 (out-of-memory corruption) and CVE-2026–109619 (stale state that survives into the next request).

Both are rated 9.2 out of 10 (php.net).

The discovery.

On 30 July 2026, OpenAI invited the security firm Calif into Patch the Planet, its program to help open-source maintainers.

Calif’s Ryan Austin picked PHP.

On 1 August, working with OpenAI’s GPT-5.6 Sol, he had a working remote code execution against WordPress.

Calif reported the first bug to PHP on 11 August and sent a working exploit on 14 August.

On 19 August, Wiz Research independently found the same family of bugs using Gemini 4 Argon, GPT-5.6 Sol and its own Wiz Atlas tool, and reported its variants on 24 August (Wiz).

The quiet window.

For about 11 weeks, PHP’s maintainers built the fix while OpenAI coordinated a coalition.

Linux distributions received patches early.

Cloudflare, AWS, Google, Microsoft, Fastly, Akamai and others prepared firewall rules.

OpenAI briefed the White House’s Super Intelligence Force, the Office of the National Cyber Director and CISA (OpenAI).

The break.

The plan was to disclose on 22 October.

On 20 October, an anonymous Hacker News post claimed the bugs were real.

It was deleted, but screenshots spread to X and Mastodon, along with images and a short video of Calif’s private exploit tool, named PHP2Shell (Alexandre Daubois).

PHP brought the release forward to 21 October at 14:00 UTC.

watchTowr also confirmed the flaws were genuine.

Cloudflare saw the first attacks at 07:43 UTC, more than six hours before any patch existed (Sansec).

The patch.

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 shipped on schedule.

The NSA, the FBI, CISA, the UK’s National Cyber Security Centre and CERT-EU all issued alerts.

In the Netherlands, DigiD, MijnOverheid, the House of Representatives’ site and the Dutch National Cyber Security Centre’s own site went offline (Patchstack, citing NOS).

Cloudflare’s shares rose about 5% that day (Investing.com).

Finding the bug is no longer the hard part

Calif’s account is the clearest.

Austin started from a theory, that ‘siblings’ of Esser’s 2004 bug still lurked in the code.

He asked his model to look for ways to trigger a controllable out-of-memory error, then for code that could be interrupted mid-task.

The model spotted that PHP counts a new table entry as live before it finishes building it.

Austin then had it turn that one finding into a reusable search pattern, which led straight to more variants (Calif).

Calif says it used no special harness and no models unavailable to the public.

Its lesson is that knowing your target still matters. The expert supplied the direction. The model supplied the speed.

Wiz tells the same story from the exploitation side.

Building working attacks meant chaining several bugs and adapting to each target’s memory layout.

With frontier models it adapted exploits across applications in hours, and a single researcher did in a week what Wiz says would once have taken a world-class team months (Wiz).

AI can find vulnerabilities faster than maintainers can fix them.

If finding was the whole problem, PHP2Shell would have been fixed in 2020 or 2024.

It wasn’t, and the PHP Foundation has said why.

After the release, the Foundation explained that a possible exploit had been theorized as early as 2024.

No concrete attack path was found, and other issues with clearer impact took priority.

The experts who could fix it had many other responsibilities, so work on a fix stalled and restarted repeatedly over months (ABC News).

OpenAI says these bugs are among several significant ones it has already found, and it expects such findings to “increase sharply” in the coming months.

A fix in PHP’s source code protects nobody until it runs on a server.

That last step belongs to the people who operate websites, and PHP2Shell showed how unevenly it happens.

After disclosure, Cloudflare says exploit attempts jumped from thousands to millions (Yahoo Finance).

On 20 October, the security company Mallory counted about 884,000 internet-facing hosts reporting PHP 8.1 or older (The Hacker News).

PHP no longer releases fixes for those versions.

That is why the NSA’s advice included taking unpatchable systems offline, and why Japan’s Prime Minister suggested switching site features off (NSA).

The Dutch government sites that went dark show that even well-resourced organizations reached for it.

The next PHP2Shell

A Prime Minister asking a country to patch a programming language overnight sounds like a one-off but it probably isn’t.

OpenAI expects findings like this to keep coming, and attackers already run AI campaigns for a few thousand dollars.

Web Components in Angular: The Good and Bad of Web Components

bytebantz — Mon, 08 Sep 2025 07:26:47 +0000

Normally, Angular components work only inside Angular applications. But Angular createCustomElement() allows you to turn an Angular component into a custom HTML element (also called a web component) that can be used anywhere, even outside an Angular app while still keeping all of Angular’s features.

What Are Web Components?

Web components are a set of standards that allow developers to create custom HTML elements using JavaScript

For example, in normal HTML, you have built-in elements like < button > or < input >. But what if you want a new type of element, like < cool-button >? You can create it using JavaScript.

Web Components allow you to mix and match different UI components from various sources. However, just because you can doesn’t mean you should.

If one Web Component uses React, another Vue, and another Angular, the browser has to load separate runtimes, which:

❌Makes the page slower (more JavaScript to download and execute).

❌Increases file size (bad for performance).

❌Creates maintenance headaches (hard to manage different technologies).

Advantages of using Web Components:

✅Reusability: Custom elements allow for code sharing across different projects.

✅Flexibility: They can be used in any web application regardless of the framework.

✅Easy Integration: They can be seamlessly added to existing web applications to introduce new functionality.

✅Future-Proofing — Based on web standards, reducing framework dependency.

Challenges involved in using Web Components:

❌Browser Support: Not all browsers support web components, which can limit usage in older browsers.

❌Complexity: Creating custom elements can be challenging.

❌Debugging: Debugging custom elements, especially in complex applications, can be difficult.

Angular provides support for Web Components through Angular Elements, allowing developers to create Web Components from Angular components.

How it works

The createCustomElement() function takes an Angular component and turns it into a JavaScript class

const coolButtonElement = createCustomElement(CoolButtonComponent, { injector });

This JavaScript class can then be registered with the browser as a custom element using the browser’s built-in customElements.define() function.

customElements.define('cool-button', coolButtonElement);

The browser keeps track of all custom elements using something called the CustomElementRegistry, which links each tag (like < cool-button >) to its JavaScript class (CoolButton).

⚠️ Important Note
Avoid using your Angular component’s selector as the Web Component tag name.

For example, if your component’s selector is app-alert, and you use it as the custom element tag < app-alert >< /app-alert >, it can cause issues.

Why?

Angular might try to create two instances of the component for the same DOM element:

One instance using the regular Angular component system.
Another instance using the custom element registration.

Once you register this class with the browser’s custom element registry, it becomes a special HTML tag that you can use just like any built-in HTML element (e.g., < cool-button >< /cool-button >).

Handling Inputs & Outputs in Web Components

Handling Inputs
When you convert an Angular component into a custom element, the process automatically handles the input properties and converts them into attributes for the custom element.

Custom elements require attributes to use dash-separated lowercase names, and they don’t recognize camelCase which Angular uses for property names.

Angular automatically changes the input property names from camelCase (like myInputProp) to dash-separated lowercase (like my-input-prop) so that it fits the custom element requirements.

Handling Outputs
Angular automatically converts output events to Custom Events and uses either the original output name or the alias you provide as the event name for the custom element.

Example 1: No alias

If you have a component with this output:

@Output() valueChanged = new EventEmitter();

When the event valueChanged is triggered, it becomes a Custom Event in the DOM, and you can listen to it like this in HTML:

<my-element (valueChanged)="handleValueChanged($event)"></my-element>

Example 2: With alias

If you use an alias with the @Output():

@Output('myClick') clicks = new EventEmitter();

Then, the custom event name becomes myClick instead of clicks. You can listen to it like this:

<my-element (myClick)="handleClick($event)"></my-element>

Shadow DOM and Encapsulation

Web Components are rendered in the shadow DOM

Key Terms

Shadow Host 🏠: The regular DOM element to which a shadow DOM is attached
Shadow Tree 🌳: The DOM structure inside the shadow DOM. This tree is encapsulated, meaning styles and scripts from the main document won’t affect it unless explicitly allowed.
Shadow Boundary ✋: The invisible boundary separating the shadow DOM from the main DOM. Anything outside this boundary can’t directly style or interact with shadow DOM elements
Shadow Root 🌱: The root of the shadow tree. It’s where all shadow content starts.

Shadow DOM is a way to encapsulate styles and behavior within a web component. This means that elements inside a Shadow DOM behave as if they are in a separate, isolated world. The styles outside don’t affect them, and their styles don’t affect the rest of the page.

Why is this useful?

✅It prevents conflicts between styles and scripts from different parts of a website.

✅It allows developers to create reusable components without worrying about breaking the rest of the page.

But This Encapsulation Also Brings Challenges!
Because the Shadow DOM is isolated, certain normal browser behaviors don’t work as expected. Some events don’t bubble out of the Shadow DOM, certain form elements don’t behave normally, and even CSS has limitations.

What Are the Key Challenges?

1. Events Might Not Bubble

Normally, when you click an element, the event “bubbles up” to parent elements.
But inside the Shadow DOM, some events (like focusin) stop at the Shadow boundary and don’t continue to the outer document.

2. Some Events Behave Differently

Events like focusin and mouseenter don’t behave as expected because the Shadow DOM treats the entire component as a single unit.
A child element inside the Shadow DOM might gain focus, but the event reports that the focus is on the whole component instead.

3. CSS Encapsulation

Styles inside a Shadow DOM don’t affect elements outside it, and vice versa.
This is great for preventing unwanted style conflicts but can cause issues if you need to apply global styles to Shadow DOM elements.

Web Components and SSR

Web Components rely on browser APIs like customElements.define(), shadow DOM, and HTML templates.

These APIs don’t exist on the server, which means Web Components don’t naturally work in a server-side rendering (SSR) environment.

Developers need to create extra wrappers or tricks to make Web Components generate server-side HTML before hydration (the process of making server-rendered HTML interactive).

This adds complexity and performance overhead.

Shadow DOM and Hydration Issues

Since Web Components rely on Shadow DOM, they don’t naturally fit into modern hydration strategies.

For example, Incremental hydration depends on event delegation, meaning Angular places global event listeners on the or a parent component to capture interactions before hydrating a component.

However, Shadow DOM blocks event delegation because:

Events do not bubble past the shadow root.
Global event listeners in Angular cannot detect interactions inside a Web Component using Shadow DOM.

What this means:

If a Web Component inside an SSR-rendered Angular app is not hydrated, clicks inside it won’t trigger Angular’s hydration logic.
Angular will never detect interactions inside a Shadow DOM unless explicitly re-dispatched.

Web Components and Angular Routing

When trying to host a second Angular app as a Web Component within another Angular application, routing often doesn’t work for the hosted app because each Angular application typically has its own isolated router instance; essentially, the parent application’s router doesn’t recognize routes defined within the child web component

Web Components Use Cases

1️⃣ Simplifying Dynamic Component Loading
Previously, if you wanted to add a component to a page dynamically (meaning you load it at runtime, not when the page is initially loaded), you had to do things like:

Create the component.
Add it to the DOM manually (the HTML structure).
Manually set up dependency injection (services, data) and change detection (keep the view updated).
Manually wire up events (like clicking buttons, etc.). This required a lot of code and was pretty complex.

With Custom Elements:

Using Angular Custom Elements makes this process much simpler. Here’s how:

Create the Angular component as usual (with your template and logic).
Convert it to a custom element using Angular’s built-in tools.
Use it in your HTML as if it were a regular HTML element (like < app-dynamic-component >< /app-dynamic-component >), and Angular takes care of all the setup, dependency injection, and event handling for you.

This results in a simplified and streamlined process for dynamically loading components, reducing the amount of code you need to write and making your app easier to maintain.

Example
Step 1: Create a New Angular Project

Run the following command in your terminal:

ng new web-components-demo

Step 2: Install the @angular/elements package:

Run the following command in your terminal:

npm install @angular/elements --save

Step 3: Create a Dynamic Component

Run the following command in your terminal:

ng generate component dynamic

Edit the dynamic.component.ts file to include some basic logic:

import { Component, input } from '@angular/core';

@Component({
  selector: 'app-dynamic',
  imports: [],
  template: `<div>{{ text() }}</div>`,
})
export class DynamicComponent {
  text = input<string>('Default dynamic message!');

Step 4: Register the Web Component

In your main.ts, register the DynamicComponent as a web component using Angular Elements:

import { bootstrapApplication } from '@angular/platform-browser';
import { appConfig } from './app/app.config';
import { AppComponent } from './app/app.component';
import { createCustomElement } from '@angular/elements';
import { DynamicComponent } from './app/dynamic/dynamic.component';

// Bootstrap the application
bootstrapApplication(AppComponent, appConfig)
  .then((app) => {
    const dynamicElement = createCustomElement(DynamicComponent, {
      injector: app.injector
    });
    customElements.define('dynamic-component', dynamicElement); // Register the web component
  })
  .catch((err) => console.error(err));

Step 5: Dynamically Load the Web Component

In your app.component.ts, create and insert the web component directly into the DOM:

import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  template: `
    <button (click)="createComponent()">Create Dynamic Component</button>
    <button (click)="destroyComponent()">Destroy Dynamic Component</button>
    <div id="container"></div>
  `,
  styleUrls: ['./app.component.css'],
})
export class AppComponent {
  createComponent() {
    const dynamicComponent = document.createElement('dynamic-component'); // Use the registered tag name
    dynamicComponent.setAttribute(
      'text',
      'Hello, this is a dynamic web component!'
    );
    document.querySelector('#container')?.appendChild(dynamicComponent);
  }

  destroyComponent() {
    const container = document.querySelector('#container');
    if (container) {
      container.innerHTML = ''; // Clear the container to remove all dynamic components
    }
  }
}

Shared Design System

Web Components are great when you need reusable UI elements that work across different frameworks or projects.

Imagine you’re building a large-scale application that has multiple teams working on different sections of the UI. One team uses Angular, another uses React, and a third one uses Vue.

Instead of each team recreating buttons, modals, and form elements in their own framework, you can build a set of Web Components that work everywhere.

How This Helps

✅ Framework-Agnostic: A Web Component like can be used in React, Vue, Angular, or even plain HTML.
✅ Single Source of Truth: Instead of maintaining separate versions of the same button in different frameworks, you maintain one component.
✅ Consistent UI: The design stays the same no matter where it’s used.

Example
Step 1: Create a new Angular project

Run the following command:

ng new shared-design-system

Step 2: Generate a new Angular element (Web Component)

ng generate component my-button

Step 3: Modify my-button.component.ts

import { Component, input } from '@angular/core';

@Component({
  selector: 'app-my-button',
  imports: [],
  template: `<button class="my-button">{{ label() }}</button>`,
  styles: [
    `.my-button {
      background-color: #007bff;
      color: white;
      padding: 10px 20px;
      border: none;
      border-radius: 5px;
      cursor: pointer;
      font-size: 16px;
    }`
  ]
})
export class MyButtonComponent {
  label = input<string>('Click Me');
}

Step 4: Convert it into a Web Component

Modify main.ts:

import { createApplication } from '@angular/platform-browser';
import { appConfig } from './app/app.config';
import { createCustomElement } from '@angular/elements';
import { MyButtonComponent } from './app/my-button/my-button.component';


// Bootstrap the application
createApplication(appConfig)
  .then((app) => {
    const myButtonElement = createCustomElement(MyButtonComponent, {
      injector: app.injector
    });
    customElements.define('my-button', myButtonElement); // Register the web component
  })
  .catch((err) => console.error(err));

The key reason createApplication is better for pure Web Components is that it does not automatically render a root component in Angular, unlike bootstrapApplication. Instead, it only initializes the Angular injector and allows you to register custom elements manually.

Step 5: Build the Angular Web Component

Run:

ng build --output-hashing=none

Step 6: Test the Web Component

To support older browsers, polyfills may be needed to provide support for web components.

If you import polyfills in main.ts, they become part of your main JavaScript bundle. This is fine if you’re only using one Angular web component.

If you embed multiple custom elements (Angular web components) on a page, each one might load the same polyfills multiple times. This can slow down your app or cause errors.

Instead of importing polyfills inside main.ts, you can load them separately using a < script > tag in your HTML. This way, they are loaded only once for all components.

Create a simple index.html:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <title>Web Component Demo</title>
    <meta name="viewport" content="width=device-width, initial-scale=1" />
  </head>
  <body>
    <my-button></my-button>

    <script src="polyfills.js" type="module"></script>
    <script src="main.js" type="module"></script>
  </body>
</html>

How to make your custom elements type-safe

In standard DOM methods like document.createElement() or document.querySelector(), TypeScript infers the type of the element returned based on the argument you provide.

For example:

document.createElement(‘a’) returns an HTMLAnchorElement with specific properties like href.
document.createElement(‘div’) returns an HTMLDivElement, which doesn’t have an href property.

However, when using custom elements, TypeScript can’t automatically infer the type because it doesn’t know the specific properties of that element.

It just thinks it’s a basic HTMLElement (a generic HTML element). For example, it doesn’t know your my-dialog element has a content property.

You have two ways to get TypeScript to understand the properties of your custom elements:
1. Casting the Type Manually

When you create the custom element, you can cast it to a more specific type that knows about the properties it has.

For example:

const dialog = document.createElement('my-dialog') as NgElement & WithProperties<{ content: string }>;
dialog.content = 'Hello, world!';  // Now TypeScript knows 'content' is a string

This way, TypeScript will now know that dialog.content should be a string and give you features like type checking and autocomplete.

The downside:

You have to write this casting (as NgElement & WithProperties) every time you create a custom element.

2. Augmenting TypeScript’s Default Knowledge of Elements

Instead of casting every time, you can tell TypeScript about your custom elements once by adding a special definition.

This is done by extending the HTMLElementTagNameMap which is how TypeScript knows what properties different HTML tags should have.

For example, you can add this globally:

declare global {
  interface HTMLElementTagNameMap {
    'my-dialog': NgElement & WithProperties<{ content: string }>;
  }
}

Now, you don’t need to cast the element manually every time:

const dialog = document.createElement('my-dialog');
dialog.content = 'Hello, world!';  // TypeScript knows 'content' is a string automatically

Using augmentation is simpler and avoids repetitive code. It ensures TypeScript automatically knows the properties of your custom elements, making your code cleaner.

Conclusion

Web Components provide a powerful way to create reusable UI elements that can work across different frameworks. By using Angular Elements, you can easily create and manage these components while maintaining the benefits of Angular’s architecture.

Say Goodbye to EventEmitter: Switch to output() for Custom Events in Angular

bytebantz — Wed, 03 Sep 2025 09:52:41 +0000

In Angular, components can communicate with each other by raising events. For example, when a user clicks a button inside a component, you might want to notify its parent component about that action.

To do that, Angular allows us to define custom events using the @Output decorator and EventEmitter (old way) or the output() function (new way).

This enables you to create events that can be emitted and handled by parent components, similar to native DOM events.

Old Way: Using @Output and EventEmitter

The traditional approach is as follows:

You define an event using the @Output decorator and an instance of EventEmitter.
You emit the event using .emit().

New Way: Using the output Function

Now, Angular introduces a simplified syntax to define custom events without needing EventEmitter.

Instead of using @Output() and EventEmitter, you can use the output() function directly.

The newer approach eliminates the need to explicitly instantiate an EventEmitter, which simplifies code and reduces boilerplate.

Even though the syntax is different, the behavior is exactly the same as the old approach. You still emit events, pass data with them, and listen for them from the parent component.

Basic Setup

To create a custom event, you define a property in your component using the output function, which returns an OutputEmitterRef.

import { Component, output } from '@angular/core';

@Component({
  selector: 'child-component',
  template: `<button (click)="sendData()">Click Me</button>`,
})
export class ChildComponent {
  dataSent = output<string>(); // No need to import EventEmitter

  sendData() {
    this.dataSent.emit('Hello, Parent!');
  }
}

In this case, the output function does exactly what EventEmitter did, but in a more compact form.

Whether you’re using the old or new way, the way you listen for the event in the parent component is the same.

In the parent component, you can listen for the dataSent event using the regular event binding syntax (eventName) and call a method when the event is triggered.

import { Component } from '@angular/core';

@Component({
  selector: 'app-parent',
  template: `
    <h1>Parent Component</h1>
    <child-component (dataSent)="receiveData($event)"></child-component>
    <p>{{ receivedMessage }}</p>
  `,
})
export class ParentComponent {
  receivedMessage: string = '';

  // Method to handle the received data from the child component
  receiveData(message: string) {
    this.receivedMessage = message; // Store the message received from the child
  }
}

Customizing Output Names

You can specify a custom name for the event in the template using the alias option

changed = output({alias: 'valueChanged'});

· The alias option only affects how the event is referenced in the template, not in TypeScript code.

· In the TypeScript code, the original name of the output property is used (in this case, changed).

· In the template, the alias name valueChanged is used to listen for the event.

Subscribing to Outputs Programmatically

When dynamically creating components in Angular, you might want to listen for events emitted by the component, for example, when a button inside the dynamically created component is clicked.

You can do this by subscribing to their output events programmatically using subscribe.

After creating the dynamic component in the parent component, we can subscribe to its event property to listen for it.

When the event is emitted, the subscription in the parent component’s code will receive the emitted data and can take an action based on it, such as logging it to the console, updating the UI, or performing some other logic.

const componentRef = viewContainerRef.createComponent(SomeComponent);

// Subscribe to the dynamically created component's output event
componentRef.instance.someEventProperty.subscribe((eventData) => {
  console.log(eventData); 
});

You can also unsubscribe manually:

const eventSubscription = componentRef.instance.someEventProperty.subscribe(eventData => {
  console.log(eventData);
});

eventSubscription.unsubscribe();

Key Points about Custom Events

Custom events do not bubble: In native DOM events, when an event is triggered, it can propagate up from the target element to its ancestors, allowing parent elements to listen for events on child elements. However, custom events in Angular do not bubble.
Case sensitivity: Output names are case-sensitive.
Inheritance: When a component extends another, it inherits the outputs from the parent component. This means child component automatically inherits the output (custom event) from the parent and can listen to or trigger it without needing to redefine the event.
Event names: Choose event names carefully to avoid conflicts with native DOM event names like click, focus, etc.

Conclusion

In conclusion, Angular provides two approaches for component communication through custom events: the traditional method using @Output() and EventEmitter, and the newer, simpler output() function. The newer approach eliminates the need for importing EventEmitter and reduces boilerplate code, making the code more concise and easier to maintain.

Why you should use @use instead of @import in Angular Projects

bytebantz — Tue, 02 Sep 2025 13:57:37 +0000

Before the introduction of @use, developers used @import to bring styles from different files into one. However, @import had some issues:

It could import the same file multiple times, leading to bloated CSS.
It pulled in everything from the imported file, even unused styles.
It caused naming conflicts when multiple files had variables with the same name.

To fix these, Sass introduced @use, which:

✔ Loads each file only once.
✔ Uses namespaces to avoid variable conflicts.
✔ Helps make CSS more optimized by importing only what’s needed.

Example: @ import (Old way)

// colors.scss
$primary-color: blue;
$secondary-color: red;


// styles.scss
@import 'colors';

body {
  background-color: $primary-color;
}

Problem: If colors.scss is imported multiple times across different files, it could cause duplication.

Example: @ use (New way)

// colors.scss
$primary-color: blue;
$secondary-color: red;

// styles.scss
@use 'colors';

body {
  background-color: colors.$primary-color;  // Notice the namespace "colors."
}

Why is this better?

The @use statement ensures colors.scss is only loaded once.
Variables need to be prefixed with the file name (colors.$primary-color), preventing conflicts.

Using @use with an Alias

Instead of typing colors.$primary-color every time, we can shorten it using as:

@use 'colors' as c;

body {
  background-color: c.$primary-color;
}

Benefit: Shorter and more readable.

@use in Angular Material
Angular Material switched to @ use for theming.

Old way (@import):

@import '@angular/material';
$my-primary: mat-palette($mat-indigo);

New way (@use):

@use '@angular/material' as mat;
$my-primary: mat.define-palette(mat.$indigo-palette, 500);

Understanding @forward rule in Sass

The @ forward rule in Sass works together with @ use to organize and control access to styles.

It allows you to re-export styles from one file to another while keeping some variables, mixins, or functions private.

Before Sass introduced @ forward, using @ import meant that everything in a file was always accessible, leading to bloated styles and naming conflicts.

If you want to explicitly control which variables get exposed, you can use @forward with the show keyword.

Example: Forwarding Only Some Variables

If you only want to expose specific variables, use show:

_colors.scss

$primary-color: blue;
$secondary-color: red;
$private-color: black; // ❌ Should not be public

@forward 'colors' show $primary-color, $secondary-color;

main.scss

@use 'colors';

body {
  background-color: colors.$primary-color; // ✅ Works
  color: colors.$secondary-color;          // ✅ Works
  border: 1px solid colors.$private-color; // ❌ ERROR! Not exposed
}

If you use @ forward without show, then all public variables, mixins, and functions from that module are automatically forwarded and accessible.

Example: Forwarding Everything

_colors.scss

$primary-color: blue;
$secondary-color: red;
$private-color: black; // This is still public unless restricted

@forward 'colors'; // ✅ Everything is forwarded

main.scss

@use 'colors';

body {
  background-color: colors.$primary-color; // ✅ Works
  color: colors.$secondary-color;          // ✅ Works
  border: 1px solid colors.$private-color; // ✅ Also works
}

Since @forward is used without show, public variables, mixins, and functions from _colors.scss are available in main.scss

Conclusion

In short, @ use provides better performance, prevents conflicts, and ensures cleaner, more efficient stylesheets, making it the preferred choice for modern Sass development.

Angular Best Practices Every Developer Needs to Know

bytebantz — Tue, 02 Sep 2025 11:29:20 +0000

Writing clean, maintainable, and performant Angular applications requires following best practices that enhance readability, testability, and performance.

Here are 6 key principles every Angular developer should follow:

1. Avoiding logic in Angular templates

Avoiding logic in Angular templates helps maintain cleaner, more maintainable code. Here’s why and how you should do it:

Why Avoid Logic in Templates?

1. Performance Optimization — Function calls in templates are executed repeatedly during change detection, which can impact performance.

2. Better Testability — Moving logic to the component makes it easier to write unit tests.

3. Improved Maintainability — Keeping business logic separate from the template reduces the risk of breaking functionality when modifying the UI.

4. Enhanced Readability — Templates remain clean and focused on presentation rather than logic.

How to Extract Logic from Templates

Instead of doing this:

<div *ngIf="isUserLoggedIn()">{{ getUserName() }}</div>

Move the logic to the component:

export class ExampleComponent {
  isLoggedIn = false;
  userName = '';

  constructor(private authService: AuthService) {
    this.isLoggedIn = this.authService.isAuthenticated();
    this.userName = this.authService.getUserName();
  }
}

Then use it in the template:

<div *ngIf="isLoggedIn">{{ userName }}</div>

This ensures the function isn’t re-evaluated unnecessarily and improves performance.

2. Using Aliases for Cleaner Imports

In a deep folder structure, import paths can become long and messy.

Using aliases can help keep your import paths clean and manageable in such projects with deep folder structures.

Example of bad imports:

import { MyComponent } from '../../../components/MyComponent';

This import path is long, hard to understand, and can easily break when files are moved around.

Instead, aliases allow you to define a short path to access files and components, improving clarity and reducing the chances of errors.

In Angular projects, aliases are set up in the tsconfig.json file.

Here’s an example:

In the tsconfig.json file, we will use the paths property to define aliases.

"compilerOptions": {
  "baseUrl": "./",
  "paths": {
    "@app/*": ["src/app/*"],
    "@services/*": ["src/app/services/*"],
    "@components/*": ["src/app/components/*"]
  }
}

Once you’ve set up your aliases, you can use them in your imports.

For example:

import { MyComponent } from '@components/MyComponent';

Instead of writing a long import path like:

import { MyComponent } from '../../../components/MyComponent';

How Aliases Improve Your Workflow:

Improved Readability: Aliases make it clear where your files are located. For instance, @components or @services give a clear context of what’s being imported, making your codebase easier to navigate.
Refactoring Made Easy: You can move files, folders, or entire sections of your application without worrying about breaking import paths throughout your project.
Consistency: With aliases, your import paths are consistent across the entire project, reducing the chance of errors.

3. Avoid Nested Subscriptions in RxJS

When handling multiple streams of data (like user input, API requests, or events), a common mistake is subscribing inside another subscription.

This leads to the following main problems:

Multiple ongoing requests → If a new request starts before the previous one finishes, multiple requests run at the same time.
Race conditions → The responses don’t always come back in order, so old data can overwrite new data.
Memory leaks → Unnecessary active subscriptions can slow down the app and use extra memory.

Instead, we should use switchMap

switchMap makes sure that only the latest request is completed and all previous requests are canceled

How This Looks in Code (Nested Subscriptions)

pickupLocation$.subscribe(location => {
  findDriver$(location).subscribe(driver => {
    console.log(`Driver assigned: ${driver}`);
  });
});

Problem:

If you update your location multiple times, multiple driver searches run at the same time.
The first request may return after the second, assigning the wrong driver.

Using switchMap (Cancels Old Requests)

pickupLocation$.pipe(
  switchMap(location => findDriver$(location)) // Cancels old requests
).subscribe(driver => {
  console.log(`Driver assigned: ${driver}`);
});

Fixed Problems:

Only one active search at a time (old requests are canceled).
Always get the correct driver for your latest request (no outdated responses).

Using switchMap ensures only the latest request matters, preventing outdated responses, unnecessary operations

4. Breaking large components into smaller, reusable component

As an Angular application grows, components tend to become large and difficult to maintain.

A single component that handles multiple responsibilities is harder to debug, test, and manage.

So, the idea is to split the large component into smaller ones that follows the Single Responsibility Principle (SRP), meaning each handle a specific task.

This way, you can test, debug, and reuse each smaller component more easily.

Example: Transforming a Large Component

Let’s say we have a large Angular component that:

Displays a list of items.
Filters items based on a search input.
Before Splitting: The Large Component

<!-- main.component.html -->
<div>
  <input [(ngModel)]="searchTerm" placeholder="Search..." />
  <div *ngFor="let item of filterItems(items, searchTerm)">
    <h3>{{ item.title }}</h3>
    <p>{{ item.description }}</p>
  </div>
</div>

// main.component.ts
export class MainComponent {
  items = [
    { title: 'fist item', description: 'Description of Item 1' },
    { title: 'second item', description: 'Description of Item 2' },
    { title: 'third item', description: 'Description of Item 3' }
  ];
  searchTerm = '';

  filterItems(items: any[], term: string) {
    return items.filter((item) => item.title.includes(term));
  }
}

After Splitting: Smaller Components

To make the component more reusable, we break it down into:

1. Search Bar Component — Handles search input.
2. Item List Component — Displays a list of items.
3. Item Component — Displays a single item.
4. Search Bar Component (search-bar.component.ts)

<!-- search-bar.component.html -->
<input [(ngModel)]="searchTerm" (input)="search.emit(searchTerm)" placeholder="Search..." />

// search-bar.component.ts
import { Component, EventEmitter, Output } from '@angular/core';

@Component({
  selector: 'app-search-bar',
  templateUrl: './search-bar.component.html',
})
export class SearchBarComponent {
  @Output() search = new EventEmitter<string>();
  searchTerm: string = '';
}

2. Item Component (item.component.ts)

<!-- item.component.html -->
<h3>{{ item.title }}</h3>
<p>{{ item.description }}</p>

// item.component.ts
import { Component, Input } from '@angular/core';

@Component({
  selector: 'app-item',
  templateUrl: './item.component.html',
})
export class ItemComponent {
  @Input() item: any;
}

3. Item List Component (item-list.component.ts)

<!-- item-list.component.html -->
<div *ngFor="let item of items">
  <app-item [item]="item"></app-item>
</div>

// item-list.component.ts
import { Component, Input } from '@angular/core';

@Component({
  selector: 'app-item-list',
  templateUrl: './item-list.component.html',
})
export class ItemListComponent {
  @Input() items: any[] = [];
}

4. Updated Main Component (main.component.ts)

<!-- main.component.html -->
<app-search-bar (search)="searchTerm = $event"></app-search-bar>
<app-item-list [items]="filterItems(items, searchTerm)"></app-item-list>

// main.component.ts
import { Component } from '@angular/core';

@Component({
  selector: 'app-main',
  templateUrl: './main.component.html',
})
export class MainComponent {
  items = [
    { title: 'Item 1', description: 'Description of Item 1' },
    { title: 'Item 2', description: 'Description of Item 2' },
    { title: 'Item 3', description: 'Description of Item 3' }
  ];
  searchTerm = '';

  filterItems(items: any[], term: string) {
    return items.filter((item) => item.title.includes(term));
  }
}

Why Break Large Components?

- Easier to Debug & Maintain — Smaller components mean fewer things can go wrong. If a bug appears, it’s easier to isolate and fix.

- Better Code Organization — Each component handles one task, making the project easier to navigate.

- Better Reusability — Extracting common UI elements prevents duplicate code.

- Improved Readability — Smaller files are easier to navigate.

- Faster Testing — Unit testing becomes much simpler because each component has a single purpose.

5. Documenting code

Documenting code with comments is an excellent practice, because it improves code maintainability, readability, and collaboration, making it easier for new developers (or even yourself in the future) to understand the logic.

Example 1: Documenting a Method

/**
 * This method converts a given age into a string.
 * It takes a number as input and returns the string version of it.
 * 
 * @param age The age value to be converted.
 * @returns A string representation of the age value.
 */
function getAge(age: number): string {
  return age.toString();
}

Example 2: Documenting a Variable

For class variables, documenting them can also be helpful.

class UserProfile {
  /**
   * The name of the user.
   * This is typically initialized when the user registers.
   * @example "John Doe"
   */
  userName: string;

  /**
   * The age of the user in years.
   * This is an optional field and may not be available for every user.
   * @example 28
   */
  userAge?: number;
}

Angular Example: Documenting a Service Method

In Angular services, you can document methods as follows:

@Injectable({
  providedIn: 'root'
})
export class UserService {
  /**
   * Fetches user data from the backend API.
   * It sends a GET request to retrieve the user's profile information.
   * 
   * @param userId The ID of the user whose data is to be fetched.
   * @returns An Observable of the user's data.
   */
  getUserData(userId: string): Observable<User> {
    return this.http.get<User>(`/api/users/${userId}`);
  }
}

Using clear, consistent commenting practices like this will make your code much more understandable.

6. Keep components lean by delegating complex logic to services.

In Angular, components and templates serve distinct roles in the app architecture.

The general rule is: components handle the logic, and templates handle the view. However, to avoid bloating your components with too much logic, it’s best to delegate business logic to services.

Example: Without a Service (Bad Practice)

Here, the component is doing too much.

import { Component } from '@angular/core';

@Component({
  selector: 'app-products',
  template: `<div *ngFor="let product of products">{{ product.name }}</div>`,
})
export class ProductsComponent {
  products = [
    { id: 1, name: 'Jacket' },
    { id: 2, name: 'Sneakers' },
  ];

  filterProducts(search: string) {
    return this.products.filter(product => product.name.includes(search));
  }
}

The filtering logic should be handled by a service instead.

Example: With a Service (Good Practice)

Move the logic to a service and inject it into the component.

Step 1: Create the Service

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class ProductService {
  private products = [
    { id: 1, name: 'Jacket' },
    { id: 2, name: 'Sneakers' },
  ];

  getProducts() {
    return this.products;
  }

  filterProducts(search: string) {
    return this.products.filter(product => product.name.includes(search));
  }
}

Step 2: Use the Service in the Component

import { Component } from '@angular/core';
import { ProductService } from '../services/product.service';

@Component({
  selector: 'app-products',
  template: `<div *ngFor="let product of filteredProducts">{{ product.name }}</div>`,
})
export class ProductsComponent {
  filteredProducts = [];

  constructor(private productService: ProductService) {
    this.filteredProducts = this.productService.getProducts();
  }

  searchProducts(search: string) {
    this.filteredProducts = this.productService.filterProducts(search);
  }
}

Why Delegate Logic to Services?

- Separation of Concerns — The component handles UI, and the service handles logic.

- Reusability — ProductService can be used in multiple components.

- Testability — We can test the service separately.

- Maintainability — Easier to modify or expand.

Conclusion

By applying these best practices, your Angular applications will be more efficient, maintainable, and scalable.

Common Security Vulnerabilities in Angular Applications and How to Fix Them

bytebantz — Wed, 26 Mar 2025 10:36:43 +0000

In this article, we’ll explore common security issues in Angular applications, how attackers exploit them, and how to secure your code.

1. Cross-Site Scripting (XSS)

XSS occurs when an application allows malicious scripts to execute in the browser.

Angular sanitization is a built-in mechanisms that checks untrusted content and ensures it’s safe for the DOM.

Angular cleans HTML by removing dangerous tags like <script>, blocks unsafe URLs (javascript: schemes), and prevents harmful CSS.

Angular automatically sanitizes values bound [innerHTML], <a [href]>, <img [src]>, and [style] to protect your app.

However, you can still introduce vulnerabilities if you intentionally bypass security mechanisms or manipulate the DOM directly.

Here are some examples of vulnerable code:

Vulnerability 1: Using bypassSecurityTrustHtml Unsafely

The bypassSecurityTrustHtml method forces Angular to trust the provided HTML, including unsafe content like <script> tags.

Angular’s DomSanitizer can be misused to allow malicious scripts.

Vulnerable Code:

import { Component } from '@angular/core';
import { DomSanitizer, SafeHtml } from '@angular/platform-browser';

@Component({
  selector: 'app-inner-html-binding',
  template: `<div [innerHTML]="trustedHtmlSnippet"></div>`,
})
export class InnerHtmlBindingComponent {
  trustedHtmlSnippet: SafeHtml;

  constructor(private sanitizer: DomSanitizer) {
    const potentiallyUnsafe = 'Template <script>alert("0wned")</script>';
    this.trustedHtmlSnippet = this.sanitizer.bypassSecurityTrustHtml(potentiallyUnsafe);
  }
}

Safer Approach:

Instead of bypassing security, let Angular sanitize the HTML automatically:

import { Component } from '@angular/core';

@Component({
  selector: 'app-inner-html-binding',
  template: `<div [innerHTML]="safeHtmlSnippet"></div>`,
})
export class InnerHtmlBindingComponent {
  safeHtmlSnippet = 'Template <script>alert("0wned")</script>'; // Angular will sanitize this automatically
}

Vulnerability 2: Directly Manipulating the DOM (ElementRef)

Angular’s built-in XSS protection only works in templates, but direct DOM manipulation bypasses it.

Using ElementRef and innerHTML allows unsafe content insertion.

Vulnerable Code:

import { Component, ElementRef, ViewChild } from '@angular/core';
import { FormsModule } from '@angular/forms';

@Component({
  selector: 'app-root',
  imports: [FormsModule],
  template: `
    <input [(ngModel)]="comment" placeholder="Enter your comment">
    <button (click)="postComment()">Post Comment</button>
    <div #commentBox></div>
  `,
})
export class AppComponent {
  @ViewChild('commentBox', { static: true }) commentBox!: ElementRef;
  comment: string = '';

  postComment() {
    this.commentBox.nativeElement.innerHTML = this.comment; // ⚠ Vulnerable to XSS!
  }
}

By default, modern browsers block scripts inserted via innerHTML (they won't execute <script> tags).

However, attackers can still exploit XSS without using <script> tags by injecting malicious event handlers like onerror, onclick, or onmouseover.

<img src="x" onerror="alert('Hacked!')">

Since the app is directly inserting user input into the DOM, if a user submits the comment above, the <img> tag loads, fails (because src="x" is invalid), and triggers the onerror JavaScript, showing an alert box. This is a Cross-Site Scripting (XSS) attack.

Fix: Use Angular’s Sanitization

To avoid XSS, use [innerHTML] instead of ElementRef.innerHTML:

import { Component } from '@angular/core';
import { FormsModule } from '@angular/forms';

@Component({
  selector: 'app-root',
  imports: [FormsModule],
  template: `
    <input [(ngModel)]="comment" placeholder="Enter your comment">
    <button (click)="postComment()">Post Comment</button>
    <div [innerHTML]="safeComment"></div>
  `,
})
export class AppComponent {
  comment: string = '';
  safeComment: string = '';

  postComment() {
    this.safeComment = this.comment; // Angular sanitizes input automatically
  }
}

2. Clickjacking

Clickjacking is when someone tricks you into clicking on something different from what you think you're clicking on.

For example, they might overlay a malicious button on top of a legitimate one, so when you click, you're actually interacting with something you didn't intend to.

Attackers can embed your Angular app inside an <iframe> and overlay a fake UI to steal user inputs.

To check if your website can be embedded in an <iframe>, create an HTML file (e.g., clickjack-test.html) and add this code:

<iframe src="https://your-angular-app.com" width="800" height="600"></iframe>

Example of Clickjacking in Action:

1. The Fake Job Ad

A scammer creates a webpage claiming: "Earn $500 per day! Click below to apply!"
This fake ad targets people searching for jobs.

2. The Clickjacking Trick

The fake page loads a real job posting inside an invisible iframe.
A hidden "Like" or "Follow" button is placed over the real "Apply Now" button.
When the user clicks "Apply Now," they actually like or follow a scam page instead.

3. The Redirection to Avoid Suspicion

After the hidden click happens, the user is redirected to the real job listing.
The victim sees a legitimate job post, making them think everything is normal.
They never realize they just followed a scam page!

Why Scammers Use Clickjacking:

They collect thousands of likes or follows for credibility.
They post fake job offers to lure victims.
Users click on scam links, thinking they are real opportunities.
Some are tricked into paying fake "registration fees."

Secure Fix

Angular does not have a specific built-in mechanism solely dedicated to preventing clickjacking out of the box.

Set X-Frame-Options and Content-Security-Policy headers in the backend:

X-Frame-Options: DENY
Content-Security-Policy: frame-ancestors 'none';

This prevents clickjacking by blocking the site from being embedded in iframes.

3. Cross-Site Request Forgery (CSRF)

CSRF is an attack where a malicious website tricks a user's browser into sending unintended requests to a different website where the user is authenticated.

CSRF attacks are possible because web browsers automatically include cookies, including session cookies that contain authentication information, in every request

If the server does not validate the request properly (e.g., checking for an anti-CSRF token or validating the Origin header), an attacker can still trick a logged-in user into making unintended changes.

Imagine you have an account on FastPizza (https://fastpizza.com), where you order food regularly.

How It Works Normally:

You log in and go to Settings → Change Email, where you enter a new email.

The website sends this request:

POST https://fastpizza.com/update-email
Content-Type: application/x-www-form-urlencoded

email=mynewemail@example.com

The Attack (CSRF Exploit)

You are already logged into FastPizza in one tab.

You then visit a malicious website, maybe a recipe blog or a free giveaway site.

The hacker creates this hidden form into the page:

<form action="https://fastpizza.com/update-email" method="POST">
    <input type="hidden" name="email" value="hacker@example.com">
</form>
<script>
    document.forms[0].submit(); // Automatically submits the form when the victim visits
</script>

If the victim is logged in, their session cookie is sent automatically.
The server processes the request and updates the email without any additional verification.
Now, the attacker's email is linked to the victim’s account.

Secure Fix

Use CSRF tokens in HTTP requests:

Angular's HttpClient helps prevent these attacks using a token system:

The backend server creates a special security token (usually named XSRF-TOKEN) and stores it in a cookie when the user loads the page.
Angular automatically reads this token and includes it in the request headers under X-XSRF-TOKEN.

If it’s not working automatically, create an Interceptor to manually extract the token.

3.The backend checks if the request contains a valid token before allowing it to change data.

If your backend uses different token names, you can configure Angular to use them:

provideHttpClient(
  withXsrfConfiguration({
    cookieName: 'CUSTOM_XSRF_TOKEN',
    headerName: 'X-Custom-Xsrf-Header',
  }),
)

4. DOM Clobbering

DOM Clobbering is an attack where an attacker manipulates the DOM properties to override JavaScript variables or elements, causing unintended behavior.

Imagine a user is trying to update their password on a website. If the frontend is vulnerable to DOM Clobbering, an attacker can inject their own password, causing the victim’s password to be changed to one controlled by the attacker.

Vulnerable Code:

<form id="updatePasswordForm">
  <input type="password" name="newPassword" placeholder="Enter new password" />
  <input type="password" name="confirmPassword" placeholder="Confirm new password" />
  <button type="submit">Update Password</button>
</form>

<script>
  const newPasswordInput = document.querySelector('input[name="newPassword"]');

  document.getElementById('updatePasswordForm').addEventListener('submit', function(event) {
    event.preventDefault();
    console.log('Updating password to:', newPasswordInput.value);
  });
</script>

Malicious Injection

An attacker injects the following malicious hidden input field into the page:

Since JavaScript automatically associates elements with global variables, document.getElementById('newPassword') now points to the hidden field instead of the real input.

Instead of their chosen password, "hackedPassword123" is sent to the server.

The attacker can now log in using the victim’s account.

Secure Fix Using Angular Reactive Forms

To prevent this attack, avoid querySelector() and use Angular’s Form Controls to securely reference inputs.

import { Component } from '@angular/core';
import { ReactiveFormsModule, FormControl, FormGroup, Validators } from '@angular/forms';

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [ReactiveFormsModule],
  template: `
    <form [formGroup]="passwordForm" (ngSubmit)="onSubmit()">
      <input type="password" formControlName="newPassword" placeholder="Enter new password">
      <input type="password" formControlName="confirmPassword" placeholder="Confirm new password">
      <button type="submit">Update Password</button>
    </form>
  `,
})
export class AppComponent {
  passwordForm = new FormGroup({
    newPassword: new FormControl('', [Validators.required]),
    confirmPassword: new FormControl('', [Validators.required])
  });

  onSubmit() {
    console.log('Updating password to:', this.passwordForm.get('newPassword')?.value);
  }
}

Conclusion

By understanding these vulnerabilities and implementing Angular’s built-in security mechanisms and recommended practices, developers can significantly enhance the security posture of their applications.

Design Patterns Every Angular Developer Should Know

bytebantz — Mon, 24 Mar 2025 17:25:13 +0000

New developers might not consider how the code will handle future changes or how easily it can be reused, expanded, or maintained. In the worst-case scenario, developers might even need to completely rebuild the project from scratch when things become too hard to fix. To avoid these issues, design patterns were created.

Design patterns are like blueprints that make your code easier to manage and change over time.

Design patterns are tried-and-tested solutions for common design issues in software development. Instead of giving a full solution, they act as best practices for solving common software design challenges.

Design patterns in Angular help you write cleaner, more organized code that makes your app easier to build, grow, and fix over time.

Why Design Patterns are important

1. Scalability

Design Patterns help break your app into small, reusable pieces. This makes it easy to add new features later without messing up existing ones.

2. Maintainability

Following design patterns ensures your code has a clear, organized structure.

For example using patterns like the Singleton Pattern makes the app more maintainable because you only have to change one piece of code in the service, and all the components that depend on it will automatically adapt.

3. Testability

Design patterns promotes the separation of concerns which makes it easier to mock and test components

4. Code Reusability

Patterns encourage writing reusable code.

For example, patterns like Factory and Singleton help you organize similar tasks in one place, so you can easily reuse them without rewriting the same logic.

1. Singleton Pattern

The Singleton Pattern ensures that a class only has one instance and allows that instance to be shared globally.

In Angular, this is often used for services, making sure only one instance of a service is used throughout the app.

A service becomes a singleton when it's provided at the root level. To do this, you use the providedIn: 'root' setting in the service’s metadata.

Example:

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root' // This makes the service a singleton
})
export class MyService {
  constructor() { }

  // Your service methods here
}

2. Facade Pattern

The Facade Pattern offers a simplified interface to interact with complex subsystems.

When you don’t use the Facade Pattern, components directly communicate with multiple services to handle different operations. This increases complexity as multiple components may replicate the same logic, leading to code duplication.

With the Facade Pattern instead of components calling multiple services, they interact with the facade. This makes the components leaner and easier to maintain, while business logic remains in one centralized place (the facade)

Example

@Injectable({
  providedIn: 'root',
})
export class CartFacade {
  constructor(private cartService: CartService, private orderService: OrderService) {}

  // Add product to cart
  addToCart(product: Product) {
    this.cartService.addItem(product);
  }

  // Remove product from cart
  removeFromCart(product: Product) {
    this.cartService.removeItem(product);
  }

  // Process checkout using the current cart
  checkout() {
    const cart = this.cartService.getCart();
    this.orderService.processOrder(cart);
  }

  // Get the current items in the cart
  getCartItems() {
    return this.cartService.getCart();
  }
}

To use the Facade Pattern in your Angular components, you simply inject the facade service into the component.

constructor(private cartFacade: CartFacade) {}

3. Factory Pattern

The Factory Pattern is a way of creating objects without specifying the exact class of the object that will be created.

It handles the object creation process and conceals the details of how instances are instantiated.

The Factory Pattern can create objects dynamically, which is useful of you don’t know in advance the exact objects/services your application will need at runtime

Example

Let's say you want to create different types of user notifications (e.g., email, SMS). You can implement the Factory Pattern as follows:

// src/app/notification.interface.ts // src/app/notification.interface.ts
export interface Notification {
  send(message: string): void;
}

// src/app/notification.service.ts
import { Injectable } from '@angular/core';
import { Notification } from './notification.interface';

@Injectable({
  providedIn: 'root',
})
export class EmailNotification implements Notification {
  send(message: string): void {
    console.log(`Email: ${message}`);
  }
}

@Injectable({
  providedIn: 'root',
})
export class SmsNotification implements Notification {
  send(message: string): void {
    console.log(`SMS: ${message}`);
  }
}

Now, let’s create a factory

// src/app/notification.factory.ts
import { Injectable } from '@angular/core';
import { EmailNotification } from './notification.service';
import { SmsNotification } from './notification.service';
import { Notification } from './notification.interface';

@Injectable({
  providedIn: 'root',
})
export class NotificationFactory {
  constructor(
    private emailNotification: EmailNotification,
    private smsNotification: SmsNotification
  ) {}

  createNotification(type: string): Notification {
    if (type === 'email') {
      return this.emailNotification;
    } else if (type === 'sms') {
      return this.smsNotification;
    } else {
      throw new Error('Unknown notification type');
    }
  }
}

Now, in your component, you can use the factory like this:

// src/app/notification/notification.component.ts
import { Component } from '@angular/core';
import { NotificationFactory } from '../notification.factory';
import { Notification } from '../notification.interface';

@Component({
  selector: 'app-notification',
  template: `
    <h1>Send Notification</h1>
    <button (click)="send('email')">Send Email</button>
    <button (click)="send('sms')">Send SMS</button>
  `,
})
export class NotificationComponent {
  constructor(private notificationFactory: NotificationFactory) {}

  send(type: string) {
    const notification: Notification = this.notificationFactory.createNotification(type);
    notification.send(`This is a ${type} notification!`);
  }
}

4. Strategy Pattern

Strategy Pattern deals with behaviors (algorithms) and how they are used.

Strategy patterns are useful when you need to switch between different algorithms or functionalities based on the context.

Example

This service will dynamically select the payment method based on the user’s choice.

@Injectable({
  providedIn: 'root',
})
export class PaymentService {
  constructor(private paypalPayment: PayPalPayment, private creditCardPayment: CreditCardPayment) {}

  processPayment(method: 'paypal' | 'creditcard', amount: number): string {
    if (method === 'paypal') {
      return this.paypalPayment.processPayment(amount);
    } else {
      return this.creditCardPayment.processPayment(amount);
    }
  }
}

Conclusion

Design patterns provide crucial benefits in terms of scalability, maintainability, testability, and code reusability. In Angular, using patterns like Singleton, Facade, Factory, and Strategy will help you build applications that are easier to manage and expand. These patterns are essential for any large or growing application where clean, organized, and maintainable code is a priority.

Understanding :host and :host-context in Angular Styling

bytebantz — Mon, 24 Mar 2025 12:37:39 +0000

When styling Angular components, you can’t simply target them using standard CSS selectors like you would with regular HTML elements. Instead, Angular provides special selectors like :host and :host-context to help style components effectively.

What is :host?

The :host selector is a special CSS rule in Angular that allows you to apply styles to the root element of a component.

Why do we need it?

Normally, in CSS, you can target elements directly. But in Angular, components are custom elements, and you cannot style them the usual way.

Example

Let’s say we are building a User Profile Card component in Angular.

<app-user-card>
    <img src="profile.jpg" alt="User Photo">
    <h3>John Doe</h3>
    <p>Web Developer</p>
</app-user-card>

If we try to add a border to this app-user-card in the component's CSS file:

app-user-card {
    border: 2px solid black;
    padding: 10px;
}

👉 This will not work because app-user-card is an Angular component and not a standard HTML element.

Solution: Use :host

We can use :host to target the root element:

:host {
  display: block;
  border: 2px solid black;
  border-radius: 0.375em;
  background-color: #eee;
}

✅ Now, the styles apply to the root element of the app-user-card component.

Conditional Styling Using :host(.class-name)

Sometimes, you only want to apply styles when the component has a certain class.

Example

Imagine we want to highlight premium users with a golden border.

<app-user-card class="premium">
    <img src="profile.jpg" alt="User Photo">
    <h3>Jane Smith</h3>
    <p>Premium Member</p>
</app-user-card>

Now, in our component's CSS:

:host(.premium) {
    display: block;
    border: 2px solid gold;
    border-radius: 0.375em;
    background-color: #eee;
}

✅ Now, these styles apply only when the premium class is present on app-user-card. If we remove the class="premium", the styles won’t apply.

What is :host-context?

The :host-context selector allows us to apply styles based on where the component is used.

:host-context(selector) applies styles only when the component is inside an element matching the given selector.

Using :host-context

Imagine your site has a Dark Mode feature. You want all User Profile Cards to look different when inside a dark-mode container.

<div class="dark-mode">
    <app-user-card>
        <img src="profile.jpg" alt="User Photo">
        <h3>Sarah Connor</h3>
        <p>Graphic Designer</p>
    </app-user-card>
</div>

:host-context(.dark-mode) {
    display: block;
    border: 2px solid gray;
    border-radius: 0.375em;
    background-color: #333;
    color: white;
}

✅ Now, if app-user-card is inside .dark-mode, it automatically changes to dark mode! 🌙

The Problem with :host-context()

While :host-context() is useful, it can cause tight coupling between components and global styles.

If you rename .dark-mode to .theme-dark, you must update every component using :host-context(.dark-mode).

A Better Alternative: Use CSS Variables Instead of :host-context()

Instead of :host-context(), we can use CSS variables that change based on a global class.

CSS variables are a powerful way to manage and centralize styling properties in CSS.

Here's how they work:

✅ Step 1: Define Global Theme Variables

CSS variables are defined with a -- prefix followed by a name and a value.

The :root pseudo-class is commonly used to define these variables globally, making them accessible throughout the application.

For example:

/* styles.css */
:root {
  --bg-color: white;
  --text-color: black;
}

.dark-mode {
  --bg-color: black;
  --text-color: white;
}

✅ Step 2: Apply Variables in Components

To use a CSS variable, you use the var() function, passing the variable name as an argument.

For example:

:host {
  background-color: var(--bg-color);
  color: var(--text-color);
  display: block;
  border: 2px solid gray;
  border-radius: 0.375em;
}

Now, components will automatically adjust without relying on :host-context().

Want to explore more?

Check out my deep dive on Angular styling techniques on Gumroad for additional insights and best practices! → https://bytebantz.gumroad.com

Your Data, Your Privacy: How VPNs Hide Your Identity

bytebantz — Sat, 28 Dec 2024 10:25:05 +0000

What is a VPN?

A VPN (Virtual Private Network) is a service that encrypts your internet connection and routes it through a secure server, masking your real IP address. By doing so, it ensures that your online activities remain private and your data is secure, even on public networks.

Why Use a VPN?

1. Enhanced Privacy

Without a VPN, websites, ISPs (Internet Service Providers), and other entities can track your IP address, browsing habits, and location. A VPN hides this information, giving you greater anonymity.

2. Security on Public Wi-Fi

Public Wi-Fi networks are hotspots for cybercriminals. A VPN encrypts your connection, safeguarding your data from prying eyes.

3. Bypassing Geo-Restrictions

VPNs allow you to access content unavailable in your country by routing your connection through servers in different regions.

4. Preventing ISP Throttling

Some ISPs monitor your online activities and slow down your connection based on usage. A VPN encrypts your traffic, preventing ISPs from selectively throttling your speeds.

5. Online Banking

Some banks block access from foreign IP addresses to prevent fraud. A VPN allows you to appear as if you're accessing the internet from your home country by routing your connection through a VPN server in your home country.

To grasp how VPNs work, it's helpful to understand some fundamental networking concepts.

1. Network Interface Card (NIC):

The NIC is the hardware in your computer or device that enables network connectivity.

Wired NICs use Ethernet cables to connect directly to a network.
Wireless NICs connect to Wi-Fi networks without cables.

Without a NIC, your device cannot access the internet, making it a critical component for VPN functionality.

2. Network Address Translation (NAT):

NAT (Network Address Translation) is a method used by routers to map multiple private IP addresses to a single public IP address (or a few public IPs).

NAT allows multiple devices on a private network to share a single public IP address, effectively managing limited public IP resources.

Without NAT, every device would need its own public IP address. For example:

If a single household had 10 devices, it would need 10 public IPs.
Multiply that by millions of households worldwide, and the demand for public IPs would far exceed supply.

NAT solves this problem by letting networks use private IPs internally and translating them to one or a few public IPs for external communication. This significantly reduces the number of public IPs required globally.

Example

1. The Setup:

Imagine you have a home network with 3 devices:

Device A: Private IP 192.168.1.2
Device B: Private IP 192.168.1.3
Device C: Private IP 192.168.1.4 These private IPs are not unique and cannot be used on the internet. Instead, your Internet Service Provider (ISP) gives you one public IP: 203.0.113.1.

2. Device Wants to Access the Internet:

Suppose Device A wants to visit example.com (IP 93.184.216.34). It sends a request to the router with its private IP address:

Source IP (Private): 192.168.1.2
Destination IP (Public): 93.184.216.34.

3. The Router Translates:

The router receives the request and does two things:

Replaces the private IP (192.168.1.2) with the public IP (203.0.113.1).
Records the translation in a table:

Private IP  | Port    | Public IP       | Port
192.168.1.2 | 12345   | 203.0.113.1     | 54321

Here, 12345 is the source port assigned by Device A, and 54321 is a new port the router assigns.

4. The Request Goes to the Internet:

Now, the request sent to example.com looks like this:

Source IP (Public): 203.0.113.1
Source Port: 54321
Destination IP (Public): 93.184.216.34. This makes it seem like the request is coming from the public IP, not Device A.

5. Response Comes Back:

The website example.com sends a response back to your public IP:

Source IP: 93.184.216.34
Destination IP (Public): 203.0.113.1
Destination Port: 54321.

6. Router Translates Back:

The router checks its NAT table to match the public IP and port (203.0.113.1:54321) to the corresponding private IP and port (192.168.1.2:12345). It then forwards the response to Device A.
7. Device A Gets the Data:

Device A receives the response, and the process is complete!

VPNs add a layer of privacy to this setup by replacing your public IP with that of the VPN server, preventing websites and other entities from tracking your location and activities.

How a VPN works

Step 1: Establishing a Secure Tunnel

When you enable a VPN, it creates a secure and encrypted connection (a "tunnel") between your device and a VPN server located elsewhere.
Encryption ensures that any data traveling through this tunnel is scrambled and cannot be intercepted or read by unauthorized parties.

Step 2: Sending Your Data

All your internet traffic (like requests to visit websites) is routed through this secure tunnel to the VPN server instead of going directly to the internet.

Step 3: Decryption at the VPN Server

The VPN server receives your encrypted data.
It decrypts the data to understand your request (e.g., visiting a specific website).

Step 4: Hiding Your IP Address

The VPN server forwards your request to the website you're trying to access.
The website does not see your actual IP address (your location). Instead, it sees the IP address of the VPN server, effectively hiding your real location.

Step 5: Receiving the Website’s Response

The website processes your request and sends the response (e.g., loading a webpage) back to the VPN server.

Step 6: Encrypting the Data

The VPN server encrypts the website's response and sends it back through the secure tunnel to your device.

Step 7: Decrypting and Displaying Data

Your device receives the encrypted data from the VPN server.
It decrypts the data, making it readable, and displays the content you requested (e.g., the webpage).

However, some VPNs may slow down your internet connection due to the extra step of routing traffic through a remote server. It's important to choose a VPN that offers high-speed servers, especially if you plan on streaming or gaming.

Some free VPNs may track and sell user data to advertisers, defeating the purpose of using a VPN in the first place. Always use a reputable paid service with no-logs policy, but remember that expensive doesn't necessarily equate to higher quality.

Recommended Affiliate VPN Providers

Surfshark

Why Choose Surfshark?

No-logs policy: Surfshark's no-logs policy means that your online activities are never tracked or stored.
Servers: Surfshark has over 3,200 servers, and its 100% RAM-only servers erase your data if the server is seized
You can use one Surfshark account to secure every device you own that supports a VPN client.
Surfshark offers advanced privacy features, including rotating IP and Dynamic MultiHop.
Surfshark is considered to be competitively priced.

NordVPN

Why Choose NordVPN?

Large Server Network: Access to a vast number of servers in multiple countries, over 5,500 servers worldwide, allowing for fast connections and diverse location options.
Advanced Security Features: Utilizes industry-standard encryption protocols like AES-256 for maximum data protection.
Dark Web Monitor: Get instant alerts about leaked credentials
Threat Protection: Additional feature to block malware, trackers, and malicious websites.

Conclusion

VPNs are essential for maintaining online privacy and security in today’s digital world. This article covered how VPNs work, their benefits, and key networking concepts like NIC and NAT that facilitate secure and efficient connectivity. Whether you’re looking to safeguard your personal data, bypass geographical restrictions, or prevent ISP throttling, a VPN is a great tool. With reliable options like Surfshark