Tool Use Pattern

An LLM by itself can only produce tokens. It can't query a database, hit an API, run code, or check today's weather. The tool use pattern closes that gap by giving the model a structured way to say "I want to call function X with these arguments" and having the surrounding system actually execute that call and feed the result back in.

How it works, step by step

1. Tool definitions are given to the model (JSON Schema) - ame, description, and a schema for expected inputs.This happens in the system prompt or a dedicated tools parameter.

2. The model decides whether a tool is needed based on the user's request and the tool descriptions.

3. The model emits a structured tool call instead of (or alongside) natural language e.g. {"tool": "get_weather", "input": {"city": "Bangalore"}}.

4. The orchestrating code (not the model) executes the actual function hits the API, runs the query, etc.

5. The result is returned to the model as a new message (a "tool result").

6. The model incorporates that result into its next response either calling another tool or answering the user.

This is fundamentally a loop: think → act → observe → think again.

ReAct Pattern

ReAct (Reason + Act) is the pattern that interleaves the model's reasoning with tool calls, step by step, rather than doing all the thinking up front or calling a tool exactly once. It's essentially Tool Use pattern extended into a loop with explicit reasoning traces at each step.

Instead of "think once, then answer" or "call one tool, then answer," ReAct has the model alternate between:

• Thought: reason in natural language about what it knows and what it needs next

• Action: call a tool based on that reasoning

• Observation: read the tool's result

• Thought: reason again, incorporating the new observation

• ... repeat until it has enough to answer

• Final answer

This loop is what lets an agent handle multi-step problems where the next action genuinely depends on what the previous action returned, you can't know what to search for next until you see what the first search turned up.

Plan & Execute Pattern

Plan & Execute splits agentic work into two distinct phases: first produce a full multi-step plan, then work through it rather than deciding one step at a time the way ReAct does. It trades ReAct's adaptability for more efficient, more predictable execution.

1. Plan: a (usually more capable) model looks at the whole task and decomposes it into an ordered list of discrete steps upfront before any tool has been called or any information gathered.

2. Execute: same agent executes the plan in the given steps involving tool calls etc.

Incorporated in multi agent systems as well with a dedicated planner agent and execution agent

Agentic RAG Pattern

Agentic RAG takes the standard retrieve-then-generate pipeline and gives the model control over the retrieval itself instead of a fixed "always retrieve once, then answer" flow, the model decides whether to retrieve, what to retrieve, how many times, and whether the results are actually good enough to answer with.

Standard RAG (fixed pipeline):
Query → Embed → Retrieve top-k → Stuff into context → Generate answer (one shot, no judgment calls)

Agentic RAG (model-in-the-loop):
Query → Model reasons: "do I even need retrieval for this?"
→ If yes: Model decides what to search, calls retrieval asa tool
→ Model evaluates:"are these chunks actually relevant/sufficient?"                    → If not: reformulate query, retrieve again, or try a                               different source
→ Repeat until confident → Generate answer

Multi Agent Patterns

Sequential Execution

agents run one after another in a fixed order, each one's output becoming the next one's input - a pipeline, not a negotiation.

Task → Agent A → Agent B → Agent C → Final Output
       (draft)   (review)  (format)

Parallel Execution

runs multiple agents at the same time on independent pieces of a task, then combines their outputs - a fan-out/fan-in shape.

                ┌─→ Agent A (source 1) ─┐
Task ─ split ──┼─→ Agent B (source 2) ─┼── merge → Final Output
                └─→ Agent C (source 3) ─┘

Router Pattern

The Router pattern (also called Router-based orchestration or Dynamic Routing) puts a single decision-maker in front of a set of specialist agents, and sends each incoming task to whichever one fits, instead of running everyone in a fixed sequence or in parallel by default.

                          ┌─→ Agent A (billing questions)
Task → Router (classify) ─┼─→ Agent B (technical support)
                          └─→ Agent C (account changes)

Orchestrator Worker Pattern ( Manager Worker Pattern )

The Orchestrator-Worker pattern (also called Manager-Worker or Hierarchical orchestration) puts a central agent in charge of a task from start to finish - it doesn't just dispatch once like Router, it keeps control, breaking the task into subtasks, assigning them to workers, checking their results, and deciding what happens next.

Amazon Bedrock AgentCore is AWS's answer to a problem every team building agents eventually hits: your agent works great on your laptop, and then you need to actually run it somewhere with scaling, session isolation, observability, and a secure invocation boundary without hand-rolling that infrastructure yourself.

This post walks through taking a real multi-agent CrewAI crew - a two-agent "Research Crew" that researches a topic and turns the findings into a report from crewai run on a laptop to a secured, containerized deployment on AgentCore Runtime. Every step here was actually run against a live AWS account, including the mistakes.

What is Bedrock AgentCore, actually?

Strip away the marketing and AgentCore is a managed runtime with one real contract: give it a container (or a zipped Python package) that speaks HTTP on port 8080 — POST /invocations for the actual work, GET /ping for health and AgentCore handles the rest: provisioning, scaling, session isolation, IAM, logging, and (optionally) JWT-based auth in front of it. It's explicitly framework-agnostic. Nothing about the contract cares whether the code behind it is Strands, LangChain, LangGraph, or in this case, CrewAI.

That framework-agnosticism matters here: AgentCore's own CLI ships built-in project templates for Strands, LangChain/LangGraph, GoogleADK, OpenAI Agents, and Autogen but not CrewAI. The escape hatch is a BYO (bring your own code) agent: you register a code location and an entrypoint file, and AgentCore doesn't care what's inside as long as it implements the HTTP contract.

The architecture

Here's what we ended up with:

Walking it left to right:

• Client - anything calling the agent: a script, another service, agentcore invoke.

• Identity Provider (Cognito) / IAM-JWT Auth - the front door. AgentCore Runtime supports two inbound-auth modes: AWS_IAM (SigV4-signed requests, the default) or CUSTOM_JWT (bearer tokens from any OIDC-compliant issuer - Cognito here). This layer validates the request before it ever reaches your code.

• AgentCore Runtime → MicroVM → Docker Container → Agent Application Code - each invocation gets an isolated microVM running your container. Your code (main.py in this project) is the innermost layer — it never sees infrastructure concerns, just a payload in and a result out.

• Execution Role - the IAM role AgentCore assumes on your container's behalf, scoped to exactly what it needs.

• ECR - where the container image lives; the Execution Role pulls it to start the runtime.

• CloudWatch - logs and traces from every invocation land here automatically.

• Bedrock (LLM) - where the actual model calls go. The Execution Role, not the client, is what's authorized to invoke Bedrock - the client never touches AWS credentials at all.

The demo: a CrewAI Research Crew

The crew is intentionally simple - two agents, sequential process:

• Researcher — gathers information on a topic using SerperDevTool (web search), backed by bedrock/apac.amazon.nova-lite-v1:0.

• Analyst — turns the researcher's output into a structured markdown report, backed by the same model.

It's defined declaratively, CrewAI's JSON-first format - crew.jsonc for the crew/task graph, agents/researcher.jsonc and agents/analyst.jsonc for each agent's role/goal/backstory/model/tools:

// agents/researcher.jsonc
{
  "role": "Senior Research Specialist for {topic}",
  "goal": "Find comprehensive and accurate information about {topic}...",
  "llm": "bedrock/apac.amazon.nova-lite-v1:0",
  "tools": ["SerperDevTool"]
}

Locally, crewai run reads this straight out of pyproject.toml's [tool.crewai] block. Neither crew.jsonc nor the loader cares whether you're running on a laptop or inside AgentCore - which is exactly what makes the port to a BYO agent almost mechanical.

Wiring it into AgentCore

A BYO agent needs exactly one thing beyond the existing project: an entrypoint that speaks the AgentCore HTTP contract. CrewAI conveniently exposes a load_crew() helper that does the JSON-first loading programmatically, so the entrypoint is a thin wrapper:

# app/ResearchAgent/main.py
from pathlib import Path
from bedrock_agentcore.runtime import BedrockAgentCoreApp
from crewai.project.crew_loader import load_crew

app = BedrockAgentCoreApp()
CREW_PATH = Path(__file__).parent / "crew.jsonc"

@app.entrypoint
def invoke(payload, context):
    crew, default_inputs = load_crew(CREW_PATH)
    topic = payload.get("prompt", default_inputs.get("topic", ""))
    result = crew.kickoff(inputs={**default_inputs, "topic": topic})
    return {"result": result.raw}

if __name__ == "__main__":
    app.run()

BedrockAgentCoreApp handles the HTTP contract (/invocations, /ping) — the crew itself doesn't know it's running inside AgentCore at all.

The agent is registered in agentcore/agentcore.json as a flat resource entry — codeLocation, entrypoint, build type, environment variables, and (as it turned out) auth config, all declared, not templated:

{
  "runtimes": [{
    "name": "ResearchAgent",
    "build": "Container",
    "entrypoint": "main.py",
    "codeLocation": "app/ResearchAgent/",
    "envVars": [
      { "name": "SERPER_API_KEY", "value": "..." },
      { "name": "AWS_DEFAULT_REGION", "value": "ap-south-1" }
    ]
  }]
}

Two bugs that only show up in deployment

Everything above sounds clean in hindsight. It wasn't, the first time through — and both failures are worth calling out because neither is obvious from the CrewAI or AgentCore docs alone.

1. The package was too big for a CodeZip build. AgentCore's default build type zips your code and its dependencies and caps the artifact at 250 MB. crewai[bedrock,tools] blew past that at 285 MB. The reason: the tools extra doesn't scope dependencies per-tool — it pulls in crewai-tools' entire dependency tree, because the package ships all ~40 tool wrappers as one unit. The researcher agent uses exactly one tool (SerperDevTool, a thin requests wrapper), but that one line in pyproject.toml also drags in chromadb, lancedb, pyarrow, onnxruntime, pymupdf, and kubernetes — dependencies for RAG tools and PDF tools and a Kubernetes tool we never touch. The fix was switching the runtime's build type from CodeZip to Container — a container image isn't subject to the 250 MB cap, so the same heavy dependency tree just... works. (The leaner fix, for anyone hitting this without wanting to move to containers, is dropping the tools extra and hand-writing a ten-line Serper tool against requests instead.)

2. Cross-region model IDs silently picked the wrong region. The crew uses bedrock/apac.amazon.nova-lite-v1:0 — a cross-region inference profile that only routes within APAC regions. Locally, everything worked, because the AWS CLI's default profile region was ap-south-1. Deployed, every invocation failed with "The provided model identifier is invalid." The cause: CrewAI's Bedrock LLM provider builds its own boto3 session and only checks AWS_DEFAULT_REGION / AWS_REGION_NAME env vars for region — it never falls back to ~/.aws/config the way a bare boto3.Session() does. With neither env var set, it silently defaulted to us-east-1, where an APAC-only inference profile is, correctly, rejected. The fix was one env var — AWS_DEFAULT_REGION=ap-south-1 — set explicitly in both agentcore/.env.local (for local agentcore dev) and the runtime's envVars in agentcore.json (for the deployed container). Two separate places, because — importantly — .env.local never reaches the deployed runtime. It lives outside the container's codeLocation and is read only by the local dev server; production env vars are a completely separate, explicit declaration.

Locking down the front door: Cognito JWT auth

By default, AgentCore Runtime protects invocations with IAM/SigV4 — fine for service-to-service calls already inside your AWS account, but not something you'd hand to, say, a frontend client. Swapping in JWT auth is a matter of setting two fields on the runtime:

"authorizerType": "CUSTOM_JWT",
"authorizerConfiguration": {
  "customJwtAuthorizer": {
    "discoveryUrl": "https://cognito-idp.<region>.amazonaws.com/<pool-id>/.well-known/openid-configuration",
    "allowedClients": ["<app-client-id>"]
  }
}

The catch: AgentCore doesn't provision the identity provider for you — there's no agentcore add cognito. Cognito (user pool, resource server, domain, app client) is a plain AWS resource you create yourself; AgentCore's CLI only consumes the resulting discovery URL. This project's scripts/cognito/ directory has three small scripts for exactly that lifecycle: create-cognito.sh provisions everything and prints the config block above; get-bearer-token.sh does the client-credentials token exchange for testing; destroy-cognito.sh tears it back down. Once CUSTOM_JWT is set, plain boto3 invoke_agent_runtime calls stop working — SigV4 signing and JWT bearer tokens are mutually exclusive per runtime, so invocation becomes a raw HTTPS POST with an Authorization: Bearer <token> header instead.

Closing thoughts

None of the individual pieces here are exotic — CrewAI's JSON-first crews, AgentCore's BYO-agent model, Cognito client-credentials grants. What's worth taking away is that the two real failures — a silent dependency bloat past a packaging limit, and a silent region fallback inside a third-party LLM provider — both looked like AgentCore problems at first and were actually one level down, in how CrewAI resolves its own dependencies and its own AWS region. Deploying an existing framework onto a new runtime surfaces exactly these kinds of assumptions the framework was making that never had to be explicit before.

Full source for this project: https://github.com/ratishjain12/crewai-bedrock-agentcore

Traditional application monitoring isn't enough. LLM applications require a new layer of observability that captures prompts, model calls, agent workflows, retrieval steps, token usage, and much more.

Introduction

Modern LLM applications are no longer simple request-response APIs.

A single user query may involve:

• API Gateway

• Authentication

• Multiple LLM calls

• Retrieval from a Vector Database

• Tool execution

• Agent planning

• Memory lookup

• Reranking

• Response generation

If any step fails, understanding where, why, and how becomes difficult.

This is exactly what LLM Observability solves.

Unlike traditional monitoring that focuses on CPU or HTTP latency, LLM observability helps answer questions like:

• Why did the model hallucinate?

• Which retrieval step failed?

• Which tool took 8 seconds?

• Why did token usage suddenly double?

• Which model version produced poor answers?

• Where is most of the latency coming from?

The Three Pillars of Observability

Every observability platform—whether for distributed systems or LLM applications—is built on three core pillars:

1. Metrics

2. Logs

3. Traces

Together they provide answers to three different questions:

Think of them as progressively increasing levels of detail.

1. Metrics

Metrics are numerical measurements collected over time.

They provide a high-level view of system health.

Examples in traditional systems:

• CPU utilization

• Memory usage

• Request latency

• Error rate

• Requests per second

For LLM systems, metrics become even more interesting.

Examples:

• Prompt tokens

• Completion tokens

• Total cost

• Requests/minute

• Tool execution latency

• Cache hit ratio

• Retrieval latency

• Hallucination rate (if measured)

• User satisfaction score

• Agent step count

Metrics are lightweight and ideal for dashboards and alerting.

Example dashboard:

Average latency: 1.8 sec

P95 latency: 3.7 sec

Average tokens/request: 1842

Error rate: 1.2%

Daily cost: $146

Metrics answer:

"Is something wrong?"

They usually do not explain why

2. Logs

Logs are detailed records of individual events.

Unlike metrics, logs preserve context.

For an LLM application, logs might include:

{
  "request_id": "abc123",
  "model": "gpt-4.1",
  "temperature": 0.2,
  "prompt": "...",
  "completion": "...",
  "input_tokens": 1452,
  "output_tokens": 321,
  "latency_ms": 1832
}

Logs help investigate questions like:

• What prompt was actually sent?

• What response came back?

• Which model version was used?

• Which user triggered this?

• Which tool failed?

• What exception occurred?

Good logs should be:

• Structured

• Searchable

• Correlated

• Timestamped

Prefer structured logs:

{
 "event":"tool_execution",
 "tool":"weather_api",
 "latency":482,
 "status":"success"
}

Structured logs make querying much easier.

3. Traces

Metrics tell you something is wrong.

Logs tell you what happened.

Traces tell you where it happened.

Tracing follows a request from beginning to end as it travels across multiple services.

Imagine a user asks:

"Summarize my quarterly sales."

The request may flow like this:

Gateway

↓

Authentication

↓

Planner Agent

↓

Retriever

↓

Vector Database

↓

LLM

↓

SQL Tool

↓

LLM

↓

Response

A trace records every one of these steps.

This allows engineers to identify:

• Which component was slow

• Which component failed

• How requests propagated

• Total end-to-end latency

Without traces, debugging distributed AI systems becomes guesswork.

Understanding Traces and Spans

Tracing revolves around two fundamental concepts:

• Trace

• Span

These are often confused.

Let's break them down.

What is a Trace?

A trace represents the entire lifecycle of one request.

One user request equals one trace.

Example:

User asks:

"What were my sales this quarter?"

Everything that happens afterward belongs to a single trace.

Trace

├── Authenticate

├── Retrieve documents

├── LLM call

├── SQL query

├── Final response

Each trace has a unique Trace ID.

Every service involved shares this ID.

What is a Span?

A span represents one operation inside a trace.

Think of spans as building blocks.

Example:

Trace

├── Span: API Gateway
      22 ms

├── Span: Authentication
      41 ms

├── Span: Vector Search
      182 ms

├── Span: LLM Call
      2150 ms

├── Span: SQL Query
      98 ms

├── Span: Final Formatting
      12 ms

Each span contains metadata such as:

• Start time

• End time

• Duration

• Status

• Attributes

• Events

• Parent span

Because spans have parent-child relationships, the backend can reconstruct the complete execution tree

OpenTelemetry (OTel)

Collecting telemetry separately for every vendor quickly becomes painful.

Imagine rewriting instrumentation every time you move from Datadog to Grafana, or from Jaeger to another backend.

OpenTelemetry solves this problem.

OpenTelemetry (OTel) is the Cloud Native Computing Foundation (CNCF) open standard for generating, collecting, and exporting telemetry data. It is vendor-neutral and supported by most major observability platforms.

It standardizes three signal types:

• Metrics

• Logs

• Traces

Instead of instrumenting your application differently for every backend, you instrument once using OpenTelemetry.

The backend can change later without changing application code.

This vendor-neutral approach prevents vendor lock-in while enabling interoperability across observability ecosystems

The OpenTelemetry Observability Pipeline

One of the biggest strengths of OpenTelemetry is its decoupled architecture.

Instead of applications sending telemetry directly to an observability platform, data flows through a standardized pipeline.

Application

↓

OpenTelemetry SDK

↓

OpenTelemetry Collector

↓

Observability Backend

Let's understand each component.

1. OpenTelemetry SDK

The SDK runs inside your application.

Its responsibilities include:

• Creating spans

• Recording metrics

• Capturing logs

• Adding metadata

• Propagating Trace IDs

• Exporting telemetry

Example (Python):

from opentelemetry import trace

tracer = trace.get_tracer(__name__)

with tracer.start_as_current_span("llm_call"):
    response = client.responses.create(...)

The SDK should do as little processing as possible to minimize application overhead.

2. OpenTelemetry Collector

The Collector is the heart of the pipeline.

Instead of every application talking directly to Datadog, Grafana, or Jaeger, they all send telemetry to the Collector.

The Collector can:

• Receive telemetry from many services

• Batch requests

• Filter sensitive data

• Enrich telemetry

• Sample traces

• Transform attributes

• Route data to multiple destinations

• Retry failed exports

• Buffer during backend outages

For example:

20 Services

↓

OTel Collector

↓

Grafana

↓

Jaeger

↓

S3 Archive

A single Collector can fan out telemetry to multiple backends simultaneously, making migrations and multi-tool deployments much easier.

3. Observability Backend

The backend stores and visualizes telemetry.

Popular options include:

• Jaeger

• Grafana Tempo

• SigNoz

• Datadog

• Honeycomb

• New Relic

• Elastic Observability

The backend provides:

• Search

• Dashboards

• Trace visualization

• Service dependency graphs

• Alerts

• Cost analysis

• Root cause analysis

This is where engineers spend most of their debugging time.

The first is the classic cascading pipeline: speech-to-text → LLM → text-to-speech, all coordinated by your backend.

The second is the newer native multimodal realtime pipeline, where the client talks almost directly to a realtime model session capable of handling speech input/output in one loop.

I sketched both architectures to understand the tradeoffs more clearly. In this post, I’ll break down how each pipeline works, where latency comes from, what your backend is responsible for, and when I’d choose one over the other.

Why voice agent architecture matters?

Building a voice agent is not just about plugging an LLM into a microphone. The architecture you choose determines:

• how fast the assistant feels

• whether you can swap STT/TTS vendors independently

• how easily you can add tools and business logic

• how much conversational nuance the system can preserve

• how much your backend stays in the critical path

• how hard it is to debug latency spikes or broken turns

At a high level, most production systems today fall into one of two buckets:

1. Cascading voice pipeline
   Separate STT, LLM, and TTS services connected by backend orchestration.

2. Native multimodal realtime pipeline
   A realtime model session handles the conversational loop, while the backend acts more like a sidecar for auth, tools, and control.

1) Cascading voice pipeline

In the cascading design, the voice stack is decomposed into three separate stages:

• Speech-to-Text (STT / ASR)
  Converts user audio into text

• LLM reasoning/generation
  Takes the transcript + context and produces a response

• Text-to-Speech (TTS)
  Converts the response text back into audio

The backend orchestrates all three stages and sits directly in the middle of the conversation loop.

High-level flow

1. The client (browser / SIP endpoint / phone integration) streams audio to the backend

2. The backend forwards audio to an STT provider

3. The STT system emits partial/final transcripts

4. The backend sends the transcript + conversation context to an LLM

5. The LLM streams back response text

6. The backend forwards the generated text to a TTS provider

7. TTS returns synthesized audio

8. The backend streams audio back to the client

Breaking down the components

Client

The client can be:

• a browser using WebRTC/WebSocket audio streaming

• a SIP/telephony system for phone calls

• a mobile app streaming microphone audio

Its job is simple: capture audio, send it upstream, and play audio responses back with low latency.

Backend

The backend is the conductor of the entire pipeline.

It is responsible for:

• managing websocket sessions

• buffering audio chunks

• forwarding audio to STT

• maintaining conversation state

• calling the LLM with the latest transcript + context

• invoking TTS for response synthesis

• streaming synthesized audio back to the client

• enforcing business rules, auth, logging, and analytics

In a cascading pipeline, the backend is not optional infrastructure — it is the core orchestrator.

STT / ASR

The STT layer converts incoming speech into text. Typical providers include:

• OpenAI Whisper / realtime transcription offerings

• Azure Speech-to-Text

• Deepgram

• AssemblyAI

• ElevenLabs speech recognition offerings where relevant

This stage often also handles:

• voice activity detection (VAD) — detecting when the user starts/stops speaking

• turn detection — deciding when the user’s utterance is “complete enough” to send to the LLM

• partial transcript streaming

LLM

Once the backend has a usable transcript, it calls the LLM. This is where:

• intent understanding happens

• tool decisions happen

• conversation memory is used

• response text is generated

For voice systems, teams often prefer small, fast models for the conversational path because latency matters more than perfect reasoning depth for every turn.

TTS

Finally, response text is synthesized into speech using providers like:

• ElevenLabs

• Deepgram

• AssemblyAI / others depending on the stack

The backend then streams the generated audio to the client.

Why teams still use cascading pipelines

Advantages

• Modular and replaceable
  You can swap Deepgram for Whisper, or ElevenLabs for another TTS provider, without redesigning the whole system.

• Maximum backend control
  The backend sees the transcript, the prompt, the tool calls, and the generated response. That’s valuable for compliance, debugging, analytics, and guardrails.

• Tool orchestration is straightforward
  Since the LLM call already goes through your backend, executing tools, calling APIs, or injecting business logic is easy to control.

• Best when speech is only one part of a larger workflow
  For example: contact-center agents, internal enterprise assistants, booking flows, or customer support systems with strict backend workflows.

Drawbacks

• Higher latency because STT, LLM, and TTS are separate hops

• Speech expressiveness can be lost when everything is collapsed into text between stages

• Interruption handling is harder because the system has to coordinate stop-speaking / start-speaking behavior across multiple services

• More moving parts means more operational complexity

2) Native multimodal realtime pipeline

The second architecture is structurally different.

Instead of routing every conversational turn through separate STT → LLM → TTS services, the client establishes a direct low-latency connection to a realtime multimodal model session.

The backend still exists, but it no longer sits in the middle of every audio token flowing through the system. Instead, it acts more like a control plane / sideband service.

High-level flow

1. The client requests an ephemeral auth token from the backend

2. The client uses that token to establish a direct websocket/realtime connection to the model provider

3. Audio/video streams directly between the client and the realtime session

4. The backend maintains a sideband channel to the session for:

   • tool/function execution

   • telemetry monitoring

   • session updates / injected instructions

   • business logic hooks

This changes the role of the backend significantly.

Breaking down the components

Client

In the native multimodal setup, the client becomes much more important.

It is responsible for:

• establishing the realtime connection

• sending live audio (and sometimes video)

• receiving streamed speech responses directly from the model session

• handling interruptions and playback state on the client side

Because the client is closer to the model, the interaction can feel more conversational and immediate.

Backend

The backend does not disappear. It just moves out of the direct audio path.

Its responsibilities now shift toward:

• minting ephemeral session/auth tokens

• maintaining a sideband websocket / control channel

• intercepting and executing tool calls

• injecting dynamic instructions or policy updates

• collecting telemetry, usage, and observability data

• enforcing app-specific business rules

This is a crucial mindset shift:

In a cascading pipeline, the backend is the conversation orchestrator.
In a realtime multimodal pipeline, the backend is often the session controller and tool executor.

Realtime multimodal model session

The model session now handles much more of the conversational loop natively:

• streaming speech input

• turn-taking behavior

• response generation

• speech output

• sometimes multimodal context like audio + text + image/video

Instead of manually chaining STT + LLM + TTS, you’re delegating that conversational stack to the model provider.

Why the native multimodal pipeline feels faster

The biggest architectural win is that the system removes multiple explicit stages from the critical path.

Instead of:

client → backend → STT → backend → LLM → backend → TTS → backend → client

you get something closer to:

client ↔ realtime model session

with the backend participating only when needed.

That reduces:

• extra network hops

• orchestration overhead

• cross-service coordination delays

It also enables more natural interaction patterns like:

• faster interruptions / barge-in

• lower response latency

• smoother turn-taking

• tighter speech-to-speech conversational flow

When I’d choose each architecture

I’d choose a cascading pipeline when…

• I need full control over the stack

• I want to independently choose the best STT, LLM, and TTS vendors

• tool execution and business workflows are central to the product

• I’m building for enterprise / contact-center / workflow-heavy use cases

• I need strong logging, auditability, and stage-by-stage debugging

I’d choose a native multimodal realtime pipeline when…

• the core product value is real-time conversation quality

• low latency is the top priority

• I want more natural interruptions and turn-taking

• I’m building a voice assistant, AI tutor, interviewer, sales caller, or realtime support agent

• I’m comfortable delegating more of the speech loop to the model provider

If I had to summarize the tradeoff in one line:

• Cascading pipeline = control and composability (flexibility, low cost)

• Native multimodal pipeline = speed and conversational fluidity (less flexible, high cost, low latency than cascading pipeline)

Artificial Intelligence is evolving faster than ever. Just a few years ago, building AI applications meant training machine learning models from scratch and deploying them with complex infrastructure. Today, developers can build powerful AI systems using Large Language Models (LLMs), retrieval pipelines, vector databases, memory systems, and autonomous agents - all working together as a modern AI stack.

But there’s a problem.

Most aspiring AI engineers jump directly into prompting tools like ChatGPT or Claude without understanding the core concepts that power modern AI applications. As a result, they can use AI tools, but struggle to design reliable, scalable, and production-ready AI systems.

This blog is designed to bridge that gap.

In this guide, we’ll explore the foundational concepts every modern AI engineer should understand - including LLMs, RAG (Retrieval-Augmented Generation), MCP, fine-tuning, vector databases, memory systems, AI agents, and agentic workflows.

Rather than treating these as isolated buzzwords, we’ll understand how they connect together to form real-world AI architectures used in products like ChatGPT, Cursor, Perplexity, Claude, and modern AI copilots.

By the end of this blog, you’ll have:

• A strong mental model of the modern AI stack

• Clarity on how different AI components interact

• Practical understanding of real-world AI architectures

• A roadmap for building production-grade AI applications

Whether you’re an aspiring AI engineer, developer, student, or builder exploring the future of AI systems, this guide will help you understand the technologies shaping the next generation of software.

Understanding Large Language Models (LLMs)

Large Language Models (LLMs) are the foundation of modern AI applications. Tools like OpenAI ChatGPT, Anthropic Claude, and Google Gemini are all powered by LLMs trained on massive amounts of text data.

At their core, LLMs are prediction engines.

They learn patterns from enormous datasets and generate text by predicting the most probable next token in a sequence. A token can be a word, subword, punctuation mark, or even part of a sentence depending on the tokenizer being used.

For example, given the sentence:

“Artificial Intelligence is transforming…”

the model predicts what token is most likely to come next based on everything it learned during training.

The Transformer Architecture

Modern LLMs are primarily built on the Transformer architecture introduced in the 2017 paper:

Attention Is All You Need

The Transformer fundamentally changed AI by making it possible for models to understand relationships between words and context much more effectively than previous architectures like RNNs or LSTMs.

The key innovation behind Transformers is self-attention.

Self-attention allows the model to determine which words in a sentence are important relative to each other.

For example, in the sentence:

“The animal didn’t cross the street because it was too tired.”

the model understands that “it” refers to “the animal” rather than “the street.”

Tokens, Context Windows, and Parameters

To understand how LLMs work in practice, three concepts are extremely important:

Tokens

LLMs do not process raw sentences directly. They process tokens.

For example:

• “ChatGPT is amazing” may become multiple tokens

• Longer prompts consume more tokens

• Input + output tokens contribute to cost and latency

This is why token optimization matters in production AI systems.

Context Window

The context window defines how much information the model can “remember” during a conversation or task.

A larger context window allows the model to:

• Analyze larger documents

• Maintain longer conversations

• Work with more instructions simultaneously

However, larger context windows also increase compute cost and latency.

Parameters

Parameters are the learned weights inside the model.

In general:

• More parameters → greater capability

• But also → higher infrastructure requirements

Modern frontier models contain billions or even trillions of parameters trained across massive GPU clusters.

Training vs Inference

LLMs operate in two major phases:

Pretraining

During pretraining, the model learns language patterns from massive datasets collected from books, websites, codebases, research papers, and other sources.

This phase is extremely compute-intensive and can cost millions of dollars.

Inference

Inference happens when users interact with the model after training is complete.

Every time you send a prompt to ChatGPT or Claude, the model performs inference to generate a response.

Most AI engineers today focus more on inference applications rather than training foundational models from scratch.

Why LLMs Changed Software Forever

Traditional software behaves deterministically:

• Same input → same output

LLMs behave probabilistically:

• Same input can generate different outputs

• Responses are context-dependent

• Systems become more flexible and adaptive

Instead of hardcoding every rule manually, developers can now build systems where language itself becomes the interface.

That is why modern AI engineering is less about building isolated models and more about orchestrating intelligent systems around LLMs.

And this is where concepts like RAG, vector databases, memory systems, and AI agents become critically important.

Retrieval-Augmented Generation (RAG)

One of the biggest limitations of Large Language Models is that they do not truly “know” real-time or private information.

An LLM only knows what it learned during training. This creates several problems:

• Knowledge becomes outdated (Knowledge Cut-off)

• Models hallucinate facts

• Private company data cannot be accessed directly

• Responses may lack domain-specific accuracy

This is where Retrieval-Augmented Generation (RAG) becomes extremely important.

RAG is an architecture pattern that enhances LLMs by retrieving relevant external information before generating a response.

Instead of relying only on what the model memorized during training, the system dynamically fetches relevant context from external sources such as:

• PDFs

• Documentation

• Databases

• Notion pages

• Internal company knowledge bases

• APIs

• Websites

The retrieved information is then injected into the prompt so the LLM can generate more accurate and grounded responses.

How RAG Works

A typical RAG pipeline consists of three major stages:

1. Indexing Knowledge

Before retrieval can happen, documents must first be processed and stored.

This usually involves:

• Splitting documents into chunks

• Generating embeddings for each chunk

• Storing embeddings inside a vector database

For example:

• A 200-page PDF might be split into hundreds of smaller chunks

• Each chunk is converted into a numerical representation (embedding)

• These embeddings allow semantic search instead of keyword-only matching

2. Retrieval

When a user sends a query:

• The query itself is converted into an embedding

• The system searches for semantically similar chunks

• Relevant information is retrieved from the vector database

Unlike traditional search systems, semantic retrieval understands meaning rather than exact keywords.

For example:

• “How do I deploy this application?”

• “How can I host this project?”

Both queries may retrieve similar documents even though the wording is different.

3. Generation

The retrieved context is appended to the user’s prompt before sending it to the LLM.

The model now generates responses grounded in external information rather than relying purely on memorized knowledge.

This dramatically improves:

• Accuracy

• Freshness

• Reliability

• Personalization

Sparse Retrieval vs Dense Retrieval

There are two major retrieval approaches commonly used in RAG systems.

Sparse Retrieval

Traditional methods like BM25 rely on keyword matching.

Advantages:

• Fast

• Interpretable

• Good for exact terms

Disadvantages:

• Weak semantic understanding

• Struggles with paraphrased queries

Dense Retrieval

Dense retrieval uses embeddings generated by transformer models.

Advantages:

• Understands semantic meaning

• Better contextual matching

• More flexible retrieval

Disadvantages:

• Higher infrastructure cost

• Requires vector databases

Most modern AI applications use dense retrieval or hybrid approaches combining both methods.

Challenges in Building Good RAG Systems

Although RAG sounds simple conceptually, building high-quality RAG systems is surprisingly difficult.

Some common engineering challenges include:

Chunking Strategy

Chunks that are too small lose context.
Chunks that are too large reduce retrieval precision.

Retrieval Quality

Poor retrieval leads to poor generation.

Even the best LLM cannot answer correctly if irrelevant context is retrieved.

Latency

RAG pipelines introduce additional retrieval steps before generation.

This increases response time.

Context Window Limits

Too much retrieved context can overwhelm the model and reduce answer quality.

Data Freshness

Knowledge bases must be updated continuously to keep information relevant.

What is a Vector Database?

A vector database is a system designed to store and retrieve embeddings efficiently.

Instead of performing exact-match queries like traditional SQL databases, vector databases perform similarity search.

This allows AI systems to retrieve semantically relevant information extremely quickly.

Popular vector databases include:

• Pinecone Pinecone

• FAISS FAISS

• Chroma Chroma

• Milvus Milvus

These systems are commonly used in:

• RAG pipelines

• AI search engines

• Recommendation systems

• AI assistants

• Memory systems for agents

Why Embeddings Matter

Embeddings are one of the most important building blocks in modern AI engineering because they allow machines to understand semantic relationships between data.

They power capabilities such as:

• Semantic search

• Document retrieval

• Recommendation engines

• Context-aware AI systems

• Personalized AI experiences

Without embeddings, most modern RAG and AI memory systems would not work effectively.

Fine-Tuning and Model Adaptation

Although modern LLMs are incredibly capable out of the box, they are still general-purpose models.

In real-world applications, organizations often need models to:

• Understand domain-specific knowledge

• Follow custom response styles

• Perform specialized tasks

• Adapt to internal workflows

This is where fine-tuning becomes important.

Fine-tuning is the process of adapting a pretrained model using additional training data for a specific use case.

Instead of training a model from scratch, developers build on top of an already capable foundation model.

Full Fine-Tuning vs Efficient Adaptation

Training all model parameters is extremely expensive.

Because of this, modern AI systems often use more efficient adaptation techniques instead of full retraining.

Popular approaches include:

• LoRA (Low-Rank Adaptation)

• Adapters

• Prompt tuning

• Instruction tuning

These methods reduce compute cost while still enabling strong customization.

Fine-Tuning vs RAG

One of the most common misconceptions in AI engineering is confusing RAG with fine-tuning.

They solve different problems.

RAG is used for:

• Injecting external knowledge

• Accessing real-time information

• Retrieving private documents

• Improving factual grounding

Fine-tuning is used for:

• Changing model behavior

• Improving formatting/style

• Specializing tasks

• Adapting workflows

A good rule of thumb:

Use RAG for knowledge.
Use fine-tuning for behavior.

Many production AI systems combine both approaches together.

Challenges of Fine-Tuning

Fine-tuning is powerful, but it also introduces challenges.

1. Data Quality

Poor training data leads to poor model behavior.

2. Overfitting

Models may become too specialized and lose general capability.

3. Cost

Training and hosting customized models can become expensive.

4. Evaluation

Testing AI systems reliably is still a major engineering challenge.

This is why many teams first optimize prompting and RAG pipelines before moving to fine-tuning.

Memory in AI Systems

One of the biggest limitations of traditional LLM interactions is that conversations are often stateless.

The model may respond intelligently within a session, but once the context window is gone, the information disappears.

This creates an important challenge:

How can AI systems remember useful information over time?

This is where memory systems become essential in modern AI applications.

Short-Term vs Long-Term Memory

AI memory is commonly divided into two categories.

Short-Term Memory

Short-term memory exists inside the model’s context window.

This includes:

• Current conversation history

• Instructions

• Retrieved documents

• Temporary context

The limitation is that context windows are finite.

Once the limit is exceeded, older information is removed.

Long-Term Memory

Long-term memory persists information outside the model itself.

This memory is usually stored using:

• Vector databases

• Structured databases

• Knowledge graphs

• External storage systems

The system can later retrieve this information when needed.

Examples include:

• Remembering user preferences

• Past conversations

• Personalized recommendations

• Workflow history

• Project context

How AI Memory Works in Practice

Most memory systems follow a simple pattern:

1. Store important interactions externally

2. Convert them into embeddings

3. Retrieve relevant memories during future interactions

4. Inject them back into the prompt

This allows AI systems to behave more consistently and contextually over time.

In many ways, memory systems are an extension of RAG architectures.

What is Agentic AI?

Agentic AI refers to AI systems capable of acting more autonomously toward goals rather than waiting for step-by-step human instructions.

Traditional AI:

• Responds to prompts

Agentic AI:

• Plans

• Decides

• Iterates

• Executes workflows

This is a major shift in how software is being designed.

MCP (Model Context Protocol)

As AI systems become more connected to external tools, one major challenge starts to appear:

How can LLMs securely and reliably interact with different applications, databases, and services?

Every tool traditionally required:

• Custom integrations

• Separate APIs

• Manual authentication logic

• Tool-specific implementations

This quickly becomes difficult to scale.

This is where the Model Context Protocol (MCP) becomes important.

MCP is an open protocol designed to standardize how AI models communicate with external tools, data sources, and applications.

Instead of building custom integrations for every system individually, MCP creates a common interface between AI systems and external resources.

You can think of MCP as:

“USB-C for AI applications.”

How MCP Works

At a high level, MCP introduces a standardized communication layer between:

• AI models

• Tools

• External applications

An MCP-compatible system can expose:

• Tools

• Resources

• Context

• Actions

to an AI model in a structured way.

Instead of hardcoding integrations directly into the application, tools become dynamically discoverable and reusable.

For example, an AI assistant could:

• Access files from a filesystem

• Query a database

• Use GitHub tools

• Interact with cloud infrastructure

• Read documentation

all through a standardized protocol.

MCP and AI Agents

MCP becomes especially powerful when combined with AI agents.

Agents require access to:

• Context

• Memory

• External tools

• Execution environments

MCP provides a cleaner and more scalable way to manage these interactions.

Rather than building isolated agent architectures for every application, developers can build reusable ecosystems of tools that AI systems can access dynamically.

This is one of the reasons MCP is gaining significant attention in the AI ecosystem.

A Simple Mental Model of Modern AI Systems

A modern AI application often looks something like this:

• LLM → reasoning engine

• RAG → retrieves external knowledge

• Vector Database → stores semantic embeddings

• Memory System → maintains context over time

• Fine-Tuning → adapts behavior for specific tasks

• MCP / Tools → connects external systems and APIs

• AI Agent Layer → orchestrates actions and workflows

Instead of relying on a single model, modern AI systems combine multiple layers working together.

This shift is transforming AI from:

• Simple chat interfaces

into:

• Autonomous, context-aware software systems

What is Rate Limiting?

Suppose you have a application where a user can post his picture, for this action you are calling an api endpoint running on a server and the endpoint stores the post in the database.

Now lets say the user posting the picture spams the post button and the server recieves thousands of requests per second, potentially overwhelming the server and causing it to crash or become unresponsive for other users.

To avoid the above scenario Rate Limiting is used!!

Setup

Create a boilerplate Next.js project using:

npx create-next-app@latest

Install @upstash/redis and @upstash/ratelimit using:

npm i @upstash/redis @upstash/ratelimit

docs - https://upstash.com/blog/upstash-ratelimit

Implementation of rate limiting

Since we are using nextjs the demonstration of implementation will be using server actions.

so, go ahead create a folder of actions and creates a server action which posts a picture or content to the database(Highly suggest prisma or drizzle for this).

After creating the server action follow the following steps:

• create a config folder and inside it create upstash.ts file with the following code

    import { Redis } from "@upstash/redis"
  
    export const redis = new Redis({
        // get these credentials by creating account on upstash
        url: `enter your upstash db url here` 
        token: `enter you db token here`
    });
  

• Now inside your server actions file, where the action for posting is created we'll use upstash/ratelimit by doing the following:

    "use server";
    import { Ratelimit } from '@upstash/ratelimit';
    import { redis } from './upstash'; // the file that you created above
    import { headers } from 'next/headers';
  
    const ratelimit = new Ratelimit({
        redis,
        limiter: Ratelimit.slidingWindow(5,"120s"); 
        //this means 5 requests is allowed per 120 seconds
    });
  
    export const addPost = async () => { // your server action
        const ip = headers().get('x-forwarded-for'); //getting user's ip 
        const {remaining, limit, success} = await ratelimit.limit(ip!);
        console.log(limit) // shows max limit
        console.log(remaining) // shows remaining requests in the window
        console.log(success) // returns if able to process the request
  
        // so to implement rate limit we need to use simple if condition
        if(!success){
            return "unable to process the request, limit reached wait for 2 minutes";
        }
  
        //rest of the addPost logic should be here dealing with the database
    }
  

Note: Here we are using rate limiting which uses sliding window technique and there are many more types of rate limiting to know about them check out the following link:

types of rate limiting: https://www.imperva.com/learn/application-security/rate-limiting/

There you go!! now you know how to implement rate limiting in your large scale projects very easily without any headache.

• Install Python: If you don't have Python installed on your system, you can download it from the official Python website (https://www.python.org/downloads/).

• Create a Virtual Environment: It's recommended to create a virtual environment for your FastAPI project to keep your dependencies isolated. You can use the built-in venv module in Python to create a virtual environment

    python -m venv myenv
  

• Install FastAPI: With the virtual environment activated, install FastAPI and its dependencies using pip:

    pip install fastapi uvicorn
  

• Create a FastAPI Application: Create a new Python file (e.g., main.py) and add the following code:

    from fastapi import FastAPI
    import uvicorn
    app = FastAPI()
  
    @app.get("/")
    async def root():
        return {"message": "Hello World"}
  
    if __name__ == "__main__":
        uvicorn.run(app, host="0.0.0.0", port=8000
  

• Uvicorn is an ASGI web server implementation for Python to run FastApi app on local host

Let's create an api endpoint using FastApi

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Product(BaseModel):
    id: int
    name: str
    description: str
    price: float

@app.get("/") #endpoint
async def root():
    return {"message": "Welcome to the E-commerce API!"}


# example of dynamic url
@app.get("/products/{product_id}", response_model=Product) 
async def get_product(product_id: int):
    # Fetch the product data from a database or external service
    product = {
        "id": product_id,
        "name": "Product Name",
        "description": "Product Description",
        "price": 19.99
    }
    return product

• To run the FastApi app use uvicorn main:app --reload command

    uvicorn main:app --reload
  

The api endpoint /product/{product_id} will return product based on the product_id provided in the params making it a dynamic url

Pydantic is data validation and parsing library generally used for data modelling of data that the user passes while hitting the api endpoint or when the user recieves the data when hitting the api endpoint.

HTTP methods used to create endpoints are GET,POST,PUT,DELETE

In the above example we have created get request api.

This way you can created api endpoints quickly and easily with the help of FastAPI

FastAPI also helps to document your api and you can access this docs using /docs endpoint of the FastAPI app.

Testing

Testing is the process of evaluating a software application or system to identify defects, ensure its functionality meets the desired requirements, and verify that it performs as intended. It helps in maintaining software reliability and usability.

There are two types of testing in general

• Unit Testing

• Integration Testing

Unit Testing

Unit testing is a level of software testing where individual components or units of a software application are tested in isolation. A "unit" typically refers to the smallest testable part of a program, such as a function, method, or class.

Integration Testing

Integration testing is a level of software testing that focuses on the interactions and interfaces between various units or components of a software system. The primary goal of integration testing is to ensure that these individual units when combined, work together as intended and that the interactions between them do not lead to defects or unexpected behavior.

React Testing Library & Jest

React Testing Library and Jest are two of the most popular tools used for testing React applications.

Setup

Firstly Install the react testing library package in your project using the following command

npm install --save-dev @testing-library/react

• You might also need to set up a configuration file for Jest, such as jest.config.js or package.json settings.

• Create the react components that you want to test.

In this blog, we are gonna see how to write a simple test for a component and run the tests.

Firstly, create a test file for your component the naming convention generally followed is ComponentName.test.js

Now, inside your test file import the required functions such as render and screen from the react testing library as well as the component that you want to test.

import React from 'react';
import { render, screen } from '@testing-library/react';
import MyComponent from './MyComponent';

Now let's understand how the react testing library and jest work!!

Structure of a test block

• Render a component you want to test

• Search for the element you want to interact with

• After that assert/check the results to see whether they are working as desired

The code below shows how a test block is written

test('MyComponent renders correctly', () => { // test block
  render(<MyComponent />);
  const element = screen.getByText('Hello, World!');
  expect(element).toBeInTheDocument();
});

The above test checks whether the element having the text Hello, World! is rendering properly on the screen or not.

We use render function to render the component we are supposed to test on.

The screen object is an essential utility that provides methods for querying and interacting with the rendered components.

To understand these methods refer to the below chart

The chart shows what each function returns in the case of No Match, 1 Match, 1+ Match and async calls.

A Little bit about Jest

Jest is a JavaScript testing framework maintained by Facebook. It's a powerful and developer-friendly tool for testing JavaScript code, including React applications.

It provides features like test runners, assertion libraries, mocking, and code coverage out of the box.

Use Jest's test runner to execute your tests. You can do this through the command line with npm test or yarn test (if configured).

To learn more in-depth on testing refer to the following resources

Checkout React testing library documentation here Docs

📚 Stay In the Know! Follow Our Blog

Discover a world of knowledge, inspiration, and insights right at your fingertips. Our blog is a treasure trove of valuable content that you won't want to miss. 🌟

Don't miss out! Click that "Follow" button now, and let the learning journey begin.

📖✨

Server-Side Rendering (SSR):

Definition: In SSR, the server generates the HTML for a web page and sends it to the client (usually a web browser) as a fully rendered page. This means that the initial page load includes all the content and is ready to be displayed immediately.

Static Server-Side Rendering (Static SSR):

1. Definition: In Static SSR, the server pre-generates HTML pages at build time or when content changes. Each page is pre-rendered into a static HTML file and stored on the server. These pre-rendered pages are then served to clients upon request.

2. Key Characteristics:

   • Pre-Generated Pages: All the pages are generated in advance, typically during the build process. This means that content does not change on the server at runtime.

   • Fast and Scalable: Since the HTML pages are pre-rendered, they can be served very quickly to clients. This approach is highly scalable as it doesn't require much server-side computation for each request.

   • Ideal for Content-Heavy Sites: Static SSR is well-suited for websites with mostly static content, like blogs, news sites, or e-commerce platforms with infrequent product updates.

3. Use Cases:

   • Static Websites: Websites with content that doesn't change frequently, like company homepages or personal blogs, can benefit from Static SSR to achieve fast page loads.

   • Jamstack Architecture: Static site generators like Gatsby, Next.js (with static site generation), or Hugo often use Static SSR to create efficient and performant websites.

Dynamic Server-Side Rendering (Dynamic SSR):

1. Definition: In Dynamic SSR, the server generates HTML pages for each request, and the content may change based on user interactions or data from external sources (e.g., a database). Unlike Static SSR, pages are created or modified at runtime.

2. Key Characteristics:

   • On-Demand Rendering: Each page is generated on the server when a user requests it, allowing for dynamic content and personalization.

   • Real-Time Updates: Dynamic SSR can provide real-time or near-real-time updates because it can fetch and render the latest data on each request.

   • Suitable for Content that Changes Frequently: Applications where content is frequently updated or personalized, such as social media feeds or e-commerce product listings, benefit from Dynamic SSR.

3. Use Cases:

   • Content-Intensive Applications: Dynamic SSR is suitable for applications with frequently changing content, such as news websites, forums, or social media platforms.

   • Personalized User Experiences: Websites that require user-specific content, like personalized recommendations or user profiles, can use Dynamic SSR to tailor content for each user.

Client-Side Rendering (CSR):

1. Definition: In CSR, the server sends a minimal HTML shell to the client, which includes JavaScript. The JavaScript code is responsible for fetching data from an API and rendering the content in the browser. The page is constructed dynamically on the client-side.

2. Key Characteristics:

   • Slower Initial Load: CSR typically results in a slower initial page load because the client needs to download the minimal HTML and then execute JavaScript to populate the content.

   • Interactive and Fast Navigation: Once the initial load is complete, CSR can provide a smoother and more interactive user experience as subsequent navigation and content updates can be faster.

   • Not SEO-Friendly by Default: Search engines may have difficulty indexing content initially because they might not execute JavaScript.

3. Use Cases:

   • Single-Page Applications (SPAs): Applications that require a high level of interactivity, like social media platforms or web-based productivity tools, often use CSR to provide a dynamic user experience.

   • Web Apps with Frequent Updates: Applications where content is frequently updated or needs real-time data often opt for CSR because it allows for quick updates without full page reloads.

In many real-world scenarios, a combination of SSR and CSR is used. This approach, known as "Hybrid Rendering," takes advantage of the benefits of both techniques. For example, a website may use SSR for the initial page load to optimize speed and SEO and then switch to CSR for subsequent navigation and interactions to provide a more interactive user experience. This mix allows web developers to strike a balance between performance and interactivity based on the specific needs of their application.

map, filter, and reduce These three versatile functions are not only essential tools in a JavaScript developer's arsenal but also shining examples of the functional programming paradigm.

let's learn these three very important functions in a step-by-step manner

Map

• The map function creates a new array by applying a given function to each element of an existing array.

• It does not modify the original array; instead, it returns a new array with the results.

•       const numbers = [1,2,3,4];
        const doubledNumbers = numbers.map((num) => num * 2);
  
        console.log(doubledNumbers);
        //output - [1,4,6,8]
  

Filter

• The filter function creates a new array containing all the elements that pass a test implemented by the provided function.

• It does not modify the original array; instead, it returns a new array with the results.

•       const numbers = [1, 2, 3, 4, 5];
        const evenNumbers = numbers.filter((num) => num % 2 === 0);
        console.log(evenNumbers);
        //output [2,4]
  

Reduce

• The reduce function reduces an array to a single value by applying a function to each element and accumulating the result.

• It takes a callback function that has an accumulator (the accumulated result) and the current element as arguments.

• You can also provide an initial value for the accumulator.

•       const numbers = [1, 2, 3, 4, 5];
        const sum = numbers.reduce((accumulator, current) {
                        return accumulator + current
                    }, 0);
        console.log(sum);
        //output - 15
  

• The second parameter 0 is the initial value given to the accumulator.

Conclusion

In summary, map transforms each element of an array and returns a new array, filter selects elements that meet a specific condition, and reduce accumulates the elements into a single value. These functions are powerful tools for working with arrays functionally and concisely, improving code readability and maintainability.

Understanding Objects

At the core of Javascript OOP is objects. Everything in javascript under the hood is an object, An object is a collection of key-value pairs where keys are strings (or symbols) and values can be of any data type or even functions.

Here's an example of Object in Javascript -

const person = {
  name: "John",
  age: 30,
  sayHello: function() {
    console.log(`Hello, my name is ${this.name} and I am ${this.age} years old.`);
  }
};

person.sayHello(); // Output: Hello, my name is John and I am 30 years old.

Classes and Constructors in Javascript

In ES6(ECMAScript 6), Javascript introduced a more structured and general way of creating objects. A class is a blueprint for creating objects with shared properties and methods.

Example -

class Person {
  constructor(name, age) { // constructor for the class
    this.name = name;
    this.age = age;
  }

  Hello() { //no need to use function keyword in class
    console.log(`Hello, my name is ${this.name} and I am ${this.age} years old.`);
  }
}

const person1 = new Person('John', 30);
const person2 = new Person('Jane', 25);

person1.Hello(); // Output: Hello, my name is John and I am 30 years old.
person2.Hello(); // Output: Hello, my name is Jane and I am 25 years old.

The constructor function of the class gets called whenever a new keyword is used to create the object of that class and initializes initial values for the object.

The "this" keyword helps in getting the context of the current object and setting the values.

Inheritance and Subclasses

JavaScript also supports inheritance through prototype-based inheritance. You can create a subclass (a child class) that inherits properties and methods from a parent class (a superclass).

class Student extends Person {
  constructor(name, age, grade) {
    super(name, age); // Call the parent class constructor
    this.grade = grade;
  }

  study() {
    console.log(`${this.name} is studying for their ${this.grade} grade.`);
  }
}

const student1 = new Student('Alice', 12, '6th');
student1.sayHello(); // Output: Hello, my name is Alice and I am 12 years old.
student1.study();

The super() function calls the superclass constructor function.

using extends keyword class Student inherits properties and methods of class Person and now we can use the properties of Person class in a Student object.

This phenomena is called inheritance.

Encapsulation, Abstraction, and More

OOP in JavaScript allows you to implement essential OOP principles such as encapsulation and abstraction. You can hide internal details and expose only the necessary interfaces, making your code more modular and maintainable.

Additionally, JavaScript provides tools like getters and setters to control access to object properties, further enhancing encapsulation.

To learn more in depth about these topics I'll be providing blogs on the topics soon.

Conclusion

Object-Oriented Programming in JavaScript empowers developers to create structured, reusable, and maintainable code. Understanding objects, classes, constructors, and inheritance is fundamental to harnessing the power of OOP in JavaScript. With these concepts in your toolkit, you can design elegant and efficient solutions for a wide range of applications.

In Javascript, everything is an object and the prototype serves as a blueprint for every object containing its properties and methods.

To understand it more easily let's first understand what are constructor functions

Constructor Functions -

Constructor functions are used to create objects. They act as templates for objects, defining their initial state and behavior.

Here's an example -

function myObj(name,age){ //constructor functions
    this.name = name;
    this.age = age;
}

const obj1 = new myObj("xyz","20");
const obj2 = new myObj("yzx","21");

The above constructor function takes properties "name" and "age" and sets them as properties on the newly created objects with the new keyword**.**

However, with this approach, each object created using new myObj() has its own copy of the properties and methods, leading to potential memory inefficiencies if there are many instances.

Prototypes -

JavaScript's prototype system comes into play to address above issue. Every function in JavaScript has a property called prototype, which is an object that can hold properties and methods shared among all instances created by that constructor function.

function Person(name, age) {
  this.name = name;
  this.age = age;
}

Person.prototype.sayHello = function () {
  console.log(`Hello, my name is ${this.name} and I am ${this.age} years old.`);
};

const person1 = new Person("Alice", 30);
const person2 = new Person("Bob", 25);

person1.sayHello(); // "Hello, my name is Alice and I am 30 years old."
person2.sayHello(); // "Hello, my name is Bob and I am 25 years old."

Since everything in javascript is an object we can use their prototype attribute to create our own set of properties for such objects common to all the instances of that object as the sayHello() function created above will be available to both person1 and person2 objects as both are instance of the same constructor function.

Prototypal Inheritance -

You can achieve prototypal inheritance using the __proto__ property in JavaScript. Here's an example:

// Parent object
const animal = {
  speak: function () {
    console.log(`I am an animal.`);
  },
};

// Child object inheriting from the parent
const dog = {
  __proto__: animal, // Set the prototype to 'animal'
  bark: function () {
    console.log("Woof!");
  },
};

// Create instances of 'dog'
const dog1 = Object.create(dog);
dog1.speak(); // "I am an animal."
dog1.bark();  // "Woof!"

const dog2 = Object.create(dog);
dog2.speak(); // "I am an animal."
dog2.bark();  // "Woof!"

Here, the dog object inherits the properties of the animal object with the help of __proto__ property. so all instances of the dog object will have the speak function in their prototype methods and variables.

However, __proto__ property was used in older javascript syntax in new Javascript modern syntax Object.setPrototypeOf() and Object.getPrototypeOf()

Here's an example -

// Parent object
const animal = {
  speak: function () {
    console.log(`I am an animal.`);
  },
};

// Child object
const dog = {
  bark: function () {
    console.log("Woof!");
  },
};

// Establishing prototype-based inheritance
Object.setPrototypeOf(dog, animal);

// Create instances of 'dog'
const dog1 = Object.create(dog);
dog1.speak(); // "I am an animal."
dog1.bark();  // "Woof!"

const dog2 = Object.create(dog);
dog2.speak(); // "I am an animal."
dog2.bark();  // "Woof!"

We use Object.setPrototypeOf(dog, animal) to establish prototype-based inheritance. This sets the prototype of dog to animal, creating a prototype chain where dog inherits from animal.

Conclusion -

In conclusion, JavaScript offers several mechanisms for establishing prototype-based inheritance, each with its own advantages and use cases. Whether you choose to use constructor functions, Object.create(), or Object.setPrototypeOf(), the fundamental concept remains the same: objects can inherit properties and methods from their prototypes, creating a flexible and efficient way to structure and organize your code.

Understanding prototype chains and how objects relate to each other through prototypes is crucial for writing maintainable and efficient JavaScript code.

Subscribe to our blog post to learn more about the fundamentals of web development.

In this blog post, we will explore how to combine the capabilities of React Hook Form and EmailJS to create a seamless form validation and email service integration.

What is React Hook Form?

React Hook Form is a lightweight and performant library for managing forms in React applications. It simplifies form validation, state management, and submission handling by leveraging React's hooks feature.

Setting up a React Application:

To get started, ensure that you have Node.js and npm (Node Package Manager) installed on your machine. Create a new React application using the following command in your terminal:

npx create-react-app form-validation-email-service

Installing React Hook Form and EmailJS:

Navigate into the project directory and install React Hook Form and EmailJS packages:

cd form-validation-email-service
npm install react-hook-form @emailjs/browser --save

Building a Form with React Hook Form:

In your React component file, import the necessary dependencies:

import React from 'react';
import { useForm } from 'react-hook-form';

function ContactForm() {
  const { register, handleSubmit } = useForm();

  const onSubmit = (data) => {
    console.log(data);
  };

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      {/* Form fields */}
    </form>
  );
}

export default ContactForm;

Validating Form Inputs:

React Hook Form offers a simple way to validate form inputs using built-in validation rules or custom functions. Let's add some basic validation to our form fields:

<input
  type="text"
  {...register('name', { required: true })}
/>

<input
  type="email"
  {...register('email', 
    { 
      required: true, 
      pattern: /^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}$/i 
    }
  )}
/>

Submitting Form Data:

To handle form submission, we'll utilize the handleSubmit function provided by React Hook Form. In the onSubmit callback, we can access the form data and perform further actions:

const onSubmit = (data) => {
  console.log(data);

  // Perform additional actions like API calls or email service integration
};

Integrating EmailJS

EmailJS is a service that allows you to send emails directly from the client-side without any server-side code.

Sign up for an account on the EmailJS website and obtain your user ID and template ID. Import the EmailJS library and configure it with your credentials:

import emailjs from '@emailjs/browser';

 const onSubmit = (data) => {
    console.log(data);
    const params = {
        "user_name":data.username, //key value mustbe same as in your template in emailjs
        "user_email":data.email,
        "message": data.message,
    }
    emailjs.sendForm('YOUR_SERVICE_ID', 'YOUR_TEMPLATE_ID', params ,'YOUR_PUBLIC_KEY')
      .then((result) => {
          console.log(result.text);
      }, (error) => {
          console.log(error.text);
      });
  };

You can now test your form by filling in the required fields and submitting it. Ensure that you receive the success message and check the recipient's email inbox for the email notification.

Conclusion

In this blog post, we explored the process of implementing form validation using React Hook Form and integrating an email service using EmailJS. React Hook Form simplified form management by providing an intuitive API for validation and submission handling. By integrating EmailJS, we were able to enhance the functionality by sending automated email notifications to the desired recipient.

Remember to further explore the documentation of React Hook Form and EmailJS to unleash their full potential in your projects. Happy coding!

Here's an extensive guide to object-oriented programming (OOP) in Dart:

1. Classes and Objects:

   • Classes in Dart define the blueprint for creating objects. You can create classes using the class keyword.

   • Objects are instances of classes, and you can create objects using the new keyword or by omitting it in newer Dart versions.

    class Person {
      String name; //variables of a class
      int age; //variables of a class

      void sayHello() {
        print("Hello, my name is $name. I'm $age years old.");
      }
    }

    void main() {
      // Creating an object of the Person class
      var person = Person();
      person.name = "John";
      person.age = 30;

      // Calling the sayHello() method
      person.sayHello(); // Output: Hello, my name is John. I'm 30 years old.
    }

• Properties represent the state or data associated with an object. They are declared using variables inside a class.

• Methods define the behavior of an object. They are functions defined within a class and can manipulate the object's properties.

1. Constructors:

• Constructors are special methods used for object initialization. Dart provides default constructors if none is defined explicitly.

• You can create named constructors to provide multiple ways to create objects.

• The this keyword refers to the current instance of the class within a constructor.

• There is another type of constructor known as redirecting constructor in Dart.

class Point {
  double x;
  double y;

  // Default constructor
  Point(this.x, this.y);

  // Named constructor
  Point.origin() {
    x = 0;
    y = 0;
  }

  // redirecting Constructors
  Point.addval(double x, double y) : this(x,y);
}

void main() {
  var p1 = Point(2, 3); // Using the default constructor
  print("Point p1: (${p1.x}, ${p1.y})"); // Output: Point p1: (2.0, 3.0)

  var p2 = Point.origin(); // Using the named constructor
  print("Point p2: (${p2.x}, ${p2.y})"); // Output: Point p2: (0.0, 0.0)

  var p3 = Point.addval(4,5); // Using the redirecting constructor
  print("Point p3: (${p3.x}, ${p3.y})"); // Output: Point p3: (4.0, 5.0)
}

Important Concepts of OOP in Dart:

1. Inheritance:

   • Inheritance allows you to create new classes based on existing ones. The new class inherits the properties and methods of the parent class.

   • Dart supports single inheritance, meaning a class can only inherit from one superclass.

   • The extends keyword is used to establish inheritance relationships.

    class Animal {
      void eat() {
        print("Animal is eating.");
      }
    }

    class Dog extends Animal {
      void bark() {
        print("Dog is barking.");
      }
    }

    void main() {
      var dog = Dog();
      dog.eat(); // Output: Animal is eating.
      dog.bark(); // Output: Dog is barking.
    }

1. Polymorphism:

   • Polymorphism allows objects of different classes to be treated as objects of a common superclass.

   • Dart achieves polymorphism through method overriding. You can override methods in a subclass to provide different implementations.

    class Animal {
      void makeSound() {
        print("Animal is making a sound.");
      }
    }

    class Dog extends Animal {
      @override
      void makeSound() {
        print("Dog is barking.");
      }
    }

    class Cat extends Animal {
      @override
      void makeSound() {
        print("Cat is meowing.");
      }
    }

    void main() {
      var dog = Dog();
      var cat = Cat();

      dog.makeSound(); // Output: Dog is barking.
      cat.makeSound(); // Output: Cat is meowing.

      // Polymorphism in action
      Animal animal = dog;
      animal.makeSound(); // Output: Dog is barking.

      animal = cat;
      animal.makeSound(); // Output: Cat is meowing.
    }

1. Encapsulation:

   • Encapsulation refers to the practice of hiding internal implementation details and exposing only necessary information.

   • In Dart, you can mark properties and methods as private using the underscore (_) prefix.

   • You can provide getter and setter methods to control access to private properties.

2. Abstraction:

   • Abstraction focuses on defining interfaces or abstract classes that provide a common set of methods that subclasses must implement.

   • Dart supports abstract classes and methods using the abstract keyword.

   • Abstract classes cannot be instantiated directly; they serve as a base for subclasses.

    abstract class Animal {
      void makeSound();
    }

    class Dog extends Animal {
      @override
      void makeSound() {
        print("Dog is barking.");
      }
    }

    class Cat extends Animal {
      @override
      void makeSound() {
        print("Cat is meowing.");
      }
    }

    void main() {
      Animal dog = Dog();
      dog.makeSound(); // Output: Dog is barking.

      Animal cat = Cat();
      cat.makeSound(); // Output: Cat is meowing.
    }

1. Interfaces:

   • Dart does not have a separate interface keyword, as every class defines an interface.

   • You can implement multiple interfaces in a class using the implements keyword.

   • Classes implementing an interface must provide implementations for all the interface's methods.

2. Static Members:

   • Static members belong to the class itself rather than instances of the class.

   • You can declare static properties and methods using the static keyword.

   • Static members can be accessed without creating an object of the class.

    class Circle {
      static const double pi = 3.14159;
      static int numberOfCircles = 0;

      Circle() {
        numberOfCircles++;
      }

      static void printPi() {
        print("The value of pi is: $pi");
      }
    }

    void main() {
      Circle();
      Circle();

      print("Number of circles: ${Circle.numberOfCircles}"); // Output: Number of circles: 2

      Circle.printPi(); // Output: The value of pi is: 3.14159
    }

1. Mixins:

   • Mixins are a way to reuse a set of methods in multiple classes without using inheritance.

   • They allow you to add behavior to a class without becoming its superclass.

   • You can define a mixin using the mixin keyword and apply it to a class using the with keyword.

    mixin Swimmer {
      void swim() {
        print("Swimming...");
      }
    }

    mixin Flyer {
      void fly() {
        print("Flying...");
      }
    }

    class Animal {
      void eat() {
        print("Eating...");
      }
    }

    class Dolphin extends Animal with Swimmer {}

    class Bird extends Animal with Swimmer, Flyer {}

    void main() {
      var dolphin = Dolphin();
      dolphin.eat(); // Output: Eating...
      dolphin.swim(); // Output: Swimming...

      var bird = Bird();
      bird.eat(); // Output: Eating...
      bird.swim(); // Output: Swimming...
      bird.fly(); // Output: Flying...
    }

This guide covers the key concepts of object-oriented programming in Dart. By understanding these concepts and their implementation in Dart, you can build robust and scalable applications.

Thank you for reading! Stay connected for more valuable content. Be sure to follow us to receive regular updates, exclusive content, and special offers. Join our vibrant community of learners by visiting our website and exploring all that we have to offer. Let's continue our journey of knowledge and growth together!!

State management is the process of managing the state of your Flutter application. The state of an application is the data that changes over time, such as the current user, the current page, or the contents of a shopping cart.

Why do you need State Management?

Flutter apps are built using a declarative programming language, which means that you describe the UI of your app in terms of how it should look, rather than how it should behave. This makes it easy to create beautiful and complex UIs, but it can also make it difficult to manage the state of your app.

Without state management, you would have to manually update the state of your app whenever it changes. This would be very tedious and error-prone, especially for large and complex apps.

What is Provider?

provider is a state management package for Flutter that makes it easy to manage the state of your app. Provider uses a concept called dependency injection to manage the state of your app.

Dependency injection is a technique where you pass the dependencies of a class into the constructor of that class. This makes it easy to change the dependencies of a class without having to modify the class itself.

Provider uses dependency injection to manage the state of your app. When you create a Provider, you pass the state of your app into the constructor of the Provider. This makes it easy to change the state of your app without having to modify the code that uses the state.

How to use Provider

To use Provider, you first need to install the package. You can do this by running the following command in your terminal:

flutter pub add provider

Once the package is installed, you can start using it in your app. The following code shows how to create a simple state management solution with Provider:

import 'package:provider/provider.dart';

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Provider(
      builder: (context, child) {
        return MaterialApp(
          home: MyHomePage(),
        );
      },
    );
  }
}

class MyHomePage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // Get the current count from the provider
    int count = Provider.of<Counter>(context).count;

    return Scaffold(
      appBar: AppBar(
        title: Text('My App'),
      ),
      body: Center(
        child: Text('The count is $count'),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: () {
          // Increment the count
          Provider.of<Counter>(context).increment();
        },
        child: Icon(Icons.add),
      ),
    );
  }
}

class Counter with ChangeNotifier {
  int count = 0;

  void increment() {
    count++;
    notifyListeners();
  }
}

• In this code, we create a Counter class that extends the ChangeNotifier class. The ChangeNotifier class provides a mechanism for notifying listeners when the state of the object changes.

• We then create a MyHomePage widget that uses Provider to get the current count from the Counter object. When the user clicks the floating action button, the count is incremented and the Counter object is notified.

Conclusion

Provider is a powerful state management library that can make it easy to manage the state of your Flutter apps.

With Provider, you can create a single source of truth for your app's state, and you can access the state from any widget in your app.

Provider also provides a number of features that make it easy to manage state, such as change notification,inheritance, and lazy loading.

If you are looking for a state management library for your Flutter app, I encourage you to check out Provider.

What is Hashing? Hashing is the process of mapping data of arbitrary size to a fixed-size output. This fixed-size output is called a hash or a message digest. The hash function takes input data and produces a fixed-length output, which is typically a unique representation of the input data. The resulting hash is often used for indexing, searching, and data integrity verification.

Advantages of Hashing: Hashing provides several advantages, such as:

1. Data Integrity Verification: Hashing is widely used for verifying data integrity. By comparing the hash value of the original data with the hash value of the received data, one can determine whether the data has been modified or corrupted during transmission.

2. Fast Retrieval: Hashing allows for quick retrieval of data from large datasets. Instead of searching through the entire dataset, hash functions can be used to index data and retrieve it quickly.

3. Security: Hashing is an essential tool in cryptography. It is used to store passwords securely and to authenticate data.

Types of Hash Functions: There are various types of hash functions, including:

1. Cryptographic Hash Functions: Cryptographic hash functions are designed to be secure and are commonly used in cryptography. Examples of cryptographic hash functions include SHA-256 and SHA-512.

2. Non-Cryptographic Hash Functions: Non-cryptographic hash functions are used for indexing, searching, and data integrity verification. Examples of non-cryptographic hash functions include MurmurHash and FNV.

Applications of Hashing: Hashing has several applications, including:

1. Password Storage: Hashing is used to store passwords securely. When a user enters a password, it is hashed and compared with the stored hash value. If the values match, the user is granted access.

2. Data Integrity Verification: Hashing is used to verify the integrity of data during transmission. The hash value of the original data is compared with the hash value of the received data to determine whether the data has been modified or corrupted.

3. Indexing and Searching: Hashing is used to index and search large datasets quickly. Hash functions can be used to map data to a fixed-size index, allowing for fast retrieval of data.

In Hashing Hash Tables are used but many times collision occurs when new data is being added to the Hash Table to avoid this there are many collision resolution techniques like linear probing, separate chaining and quadratic probing below there is an in-depth explanation of these techniques -

1. Linear Probing: Linear probing is a simple method for resolving collisions. When a collision occurs, the algorithm checks the next available slot in the table and places the item there. This process continues until an empty slot is found. The main disadvantage of linear probing is that it can result in clustering, where items are stored in adjacent slots, making it more difficult to search the table efficiently.

   

2. Separate Chaining: Separate chaining is a technique where each slot in the hash table contains a linked list of items that hash to that location. When a collision occurs, the item is added to the linked list. This method avoids clustering and is more efficient for large datasets. However, it requires additional memory to store the linked lists and may result in slower search times if the lists become too long.

   

Quadratic Probing: Quadratic probing is a variation of linear probing that tries to distribute items more evenly across the table. Instead of checking the next available slot, the algorithm searches for the next available slot using a quadratic function. This method reduces clustering and provides better search efficiency than linear probing. However, it may result in longer search times for some inputs.

In conclusion, hashing is an essential concept in computer science, providing several benefits such as data integrity verification, fast retrieval, and security. Understanding the different types of hash functions and their applications can help developers make informed decisions when implementing hashing in their applications.

ChatGPT API helps developers to integrate ChatGPT features into their projects which can be either chat-based or voice assistant ie - using your commands as input and the API will generate a response based on that command.

DALL-E API is used for image generation based on user prompts

Pre-requisites before integration

• Create an account on Open AI by going to their documentation page

• Generate your API Key which will be used to make an API call to the ChatGPT API and DALL-E API by clicking on Create new secret key

• Make sure to store the API Key somewhere like the .env file as you will only be able to see it on the website only once.

Integrate APIs in your Flutter Project

• Create a dart file which will contain all the functions regarding the API calls to

  ChatGPT and DALL-E and name it for example openai_service.dart

• We are gonna use the HTTP package for the API call but you can also use the dart_openai package for the API calls(dart_openai)

• Now we are gonna use chat API(chat completions) which supports two open AI models: GPT-4 and GPT-3.5-turbo

• Now as we are also using DALL-E API together we need some way to distinguish whether the user is asking to generate an image or not for that we will be using an async function named as isArtPrompt() and use Chat completions for it.

  This function returns a yes or no based on which API call is made either to ChatGPT API or DALL-E API.

  

•   Future<String> isArtPrompt(String prompt) async {
        try {
          final res = await http.post(
              Uri.parse("https://api.openai.com/v1/chat/completions"),
              headers: {
                'Content-Type': 'application/json',
                'Authorization': 'Bearer $OpenAIApiKey'
              },
              body: jsonEncode({
                'model': "gpt-3.5-turbo",
                'messages': [
                  {
                    "role": "user",
                    "content":
                        "Does this message want to generate an AI picture, image, art or anything similar? $prompt . Simply answer with a yes or no."
    //this content asks chatGPT and retrieves answer in yes or no 
                  }
                ],
              }));
          print(res.body);
          if (res.statusCode == 200) {
            String content =
                jsonDecode(res.body)['choices'][0]['message']["content"];
            content = content.trim(); //trimming all space from output
            switch (content) {
              case 'yes':
              case 'Yes':
              case 'Yes.':
              case 'yes.':
                   final res = await dallEAPI(prompt); 
                   // dalle api call if yes
                return res;
              default:
                final res = await chatGPTAPI(prompt);
                // ChatGPT api call if no
                return res;
            }
          }
          return "An internal error!!";
        } catch (e) {
          return e.toString();
        }
      }
  

  Now the functions chatGPT API and DALL-E are as follows

•   final List<Map<String, String>> messages = [];
    // Chat Completetion API call
    Future<String> chatGPTAPI(String prompt) async {
        messages.add({'role': 'user', 'content': prompt});
        try {
          final res = await http.post(
              Uri.parse("https://api.openai.com/v1/chat/completions"),
              headers: {
                'Content-Type': 'application/json',
                'Authorization': 'Bearer $OpenAIApiKey'
              },
              body: jsonEncode({
                'model': "gpt-3.5-turbo",
                'messages': messages,
              }));
          print(res.body);
          if (res.statusCode == 200) {
            String content =
                jsonDecode(res.body)['choices'][0]['message']["content"];
            content = content.trim();
            messages.add({'role': 'assistant', 'content': content});
            return content;
          }
          return "An internal error!!";
        } catch (e) {
          return e.toString();
        }
      }
  
    // image generation API call
    Future<String> dallEAPI(String prompt) async {
        messages.add({'role': 'user', 'content': prompt});
        try {
          final res = await http.post(
              Uri.parse("https://api.openai.com/v1/images/generations"),
              headers: {
                'Content-Type': 'application/json',
                'Authorization': 'Bearer $OpenAIApiKey'
              },
              body: jsonEncode({
                'prompt': prompt,
                'n': 1, // number of images to be generated
              }));
          print(res.body);
          if (res.statusCode == 200) {
            String imgUrl = jsonDecode(res.body)['data'][0]['url'];
            imgUrl = imgUrl.trim();
            messages.add({'role': 'assistant', 'content': imgUrl});
            return imgUrl;
          }
          return "An internal error!!";
        } catch (e) {
          return e.toString();
        }
      }
  

  Thats it !! Now you can use the isArtPrompt() function and pass it your desired prompt, the function will call either of the APIs and give a response which you can use in your Flutter app to showcase the user.

You can check out my Voice assistant Flutter App using ChatGPT API and DALL-E API for text response and image generation based on user prompts(Voice Assistant App).

Make sure to follow me and subscribe to this blog for more tech blogs like this on daily basis, P.S. - your support is much appreciated!!!

Create: The Create operation allows users to create new data entries in the database. This can be done using a web form or an API endpoint. When the user submits the data, it is sent to the server and stored in the database. The data is validated to ensure that it meets the required criteria before it is stored in the database.

Read: The Read operation allows users to retrieve data from the database. This can be done by querying the database using specific criteria. For example, a user might search for all the products in a specific category or all the users who have signed up in the last week. The data is returned in a format that can be easily understood by the user, such as a table or a list.

Update: The Update operation allows users to modify existing data in the database. This can be done using a web form or an API endpoint. When the user submits the updated data, it is sent to the server and stored in the database. The data is validated to ensure that it meets the required criteria before it is updated in the database.

Delete: The Delete operation allows users to remove data from the database. This can be done using a web form or an API endpoint. When the user confirms the deletion, the data is removed from the database. It is important to note that this operation should be used with caution, as it can result in the loss of important data.

Suppose, you are on Instagram and you create a post, this is called create functionality and now in that post after uploading you are trying to change the caption of the post, this is update functionality similarly you delete a post triggering delete functionality and while you are searching for an account to follow you are triggering read functionality as you are trying to search the account which Instagram will provide by reading from its database.

The above example, tells you that CRUD functionality is most crucial for big tech companies to maintain their product.

The importance of CRUD functionality: CRUD functionality is important for several reasons. First, it allows users to interact with data simply and intuitively. This makes it easier for users to manage their data and reduces the likelihood of errors.

Second, CRUD functionality ensures that data is consistent and accurate. When users create, read, update, and delete data using a standardized set of operations, the data remains consistent across the entire system.

Finally, CRUD functionality helps to ensure the security of the system. By controlling access to the Create, Read, Update, and Delete operations, the system can prevent unauthorized access to sensitive data.

In conclusion, CRUD functionality is an essential feature of any application that deals with data. It provides users with a simple and intuitive way to manage their data, ensures the consistency and accuracy of the data, and helps to ensure the security of the system.

To Learn More about what is an API checkout my Blog

APIs are an essential part of software development and they are becoming highly important for businesses around the world as they are moving their operations to the cloud. APIs allow applications to access data and interact with other applications seamlessly and efficiently.

For example, suppose you are building an app which allows users to search for weather conditions across countries and states for this you can use a Weather API which has all the data and integrates it into your application making it very efficient and easy to build. Moreover, you can also add more features to your app by using multiple APIs.

Without APIs, most of your favourite software wouldn't exist today such as Google Maps API lets you integrate Google Maps on your mobile which is allowing many tech startups like Ola, Uber etc. to provide location service.

Why should you use APIs in your application?

• It extends application capabilities.

• Allows developers to reuse certain application logic.

• APIs are platform-independent, they deliver data without being affected by the requesting platform.

• Enables the app to access outside resources.

So How Does an API Work?

Imagine you are trying to order an item from an online e-commerce store now when you click on buy item your request gets transferred to the backend web server of the e-commerce store via an API request.

Now, the backend server will respond to the API request and pass on your order request to the delivery partner and the delivery partner will deliver the requested item to you.

This process of sending a request is called an API request and the response to the API request is called an API response.

So API helps in providing a secured layer between applications and the data they access, protecting sensitive information from unauthorized access.

Types of APIs

• Open/Public APIs -

  These APIs are available to everyone as a result, open APIs typically have relatively low authentication and authorization measures and are often restricted in the assets they share. These are either free to access or have a subscription fee.

• Partner APIs -

  Partner APIs are shared externally, but only among those with a business relationship with the API company. Access is limited to authorized clients with official licenses

• Internal APIs -

  internal APIs (also called private APIs) are not intended for use by third parties. Internal APIs are only made available for use inside a company and are meant to streamline data transfers between teams and systems.

• Composite APIs -

  Composite APIs combine multiple APIs allowing developers to bundle calls or requests and receive one unified response from different servers.

10 APIs you can use in your Applications -

• Google Maps API (Checkout)

• Omdb API (Checkout)

• Open Weather Map API (Checkout)

• Spotify API (Checkout)

• Coinbase API (Checkout)

• Fake Store API (Checkout)

• Novu API (Checkout)

• Zenserp API (Checkout)

• Number verification API (Checkout)

• Stripe API (Checkout)

The process in which a function calls itself either directly or indirectly is called recursion and the corresponding function is called a recursive function with recursion you can solve some complex problems quite easily examples of such problems are tower of hanoi, tree traversals, DFS of graph etc.

properties of recursion -

• performing the same operation multiple times with different inputs

• At every step, the input is reduced to make the problem smaller

• A base condition is required to stop the recursion process otherwise infinite loop will occur

Many people when try to solve a problem using recursion they try to trace each recursive call to determine what each function call is doing but this is a trap of endless confusion to avoid this trap you need not need to know what each function call is doing rather you just need to pick a subproblem and believe that your function will solve the rest of the problem, you need to take a leap of faith and believe in your function.

Steps to approach a problem and think recursively

• Step 1) Know what your function is supposed to do.

• Step 2) Determine a subproblem from the main problem.

• Step 3) Find out the answer to the subproblem and use it to solve the main problem.

• Step 4) Last step is to determine the base condition of the problem

Let's take a simple problem such as finding the sum of 1 to n numbers and follow the 4 steps mentioned above to solve the problem.

Know what your function is supposed to do

This is the most basic and general step but a very important one. Now in the question above, we know that we need to calculate the sum of numbers from 1 to n

So our function needs to take a value n and return the sum from 1 up to n so our inputs of the function cant exceed n.

let's say the function is sumTo().

int sumTo(int n){

}

Determine the subproblem from the main problem

A subproblem is any problem that is smaller than the main problem and it is important to find the appropriate subproblem

In the above case, the subproblem can be solving the sum of all numbers less than n.

so the appropriate subproblem will be solving for the sum of (n-1) numbers.

Finding out the answer to the subproblem and using it to solve the main problem

The solution for the sum of n-1 numbers will be

sumToSubProblem = 1+2+3 ...... + n-1

Now to find the solution to the main problem we just need to add the nth number -

mainProblem = subProblem + n

So the code will be

int sumTo(int n){
     int subProblem = sumTo(n-1);
     return subProblem + n;
}

The last step is to find the base case for the recursion process -

A base case condition is any condition that stops the recursion process and is necessary to avoid the infinite loop.

So to find the base condition we need to find at what input the function becomes irrelevant in the above case we know if n = 0 the function will become irrelevant as 0+0 will give 0 only.

so on applying this base condition we will have a complete solution to the main problem

int sumTo(n-1){
    if(n == 0) return 0;
    int subProblem = sumTo(n-1);
    return subProblem + n;
}

More examples -

Reversing a string using recursion

As per the first step, we know that we need a function that takes a string as input and return a reversed string.

string reverseString(string s){

}

Now we need to determine a subproblem which in this case will be leaving the first character and solving for the rest of the characters.

ie - string s = "hello";

so the subproblem will be reversing "ello" to "olle" and adding the first character 'h' in the end.

string reverseString(string s){
     string substring = s.substr(1,s.length());
     string reversedSubProblem = reverseString(substring);
     return reversedSubProblem + s[0];
}

Now the last step will be finding the base case condition which in this case will be if string s become empty string because that is the most basic string a user can provide.

so,

string reverseString(string s){
     if(s == "") return "";
     string substring = s.substr(1,s.length());
     string reversedSubProblem = reverseString(substring);
     return reversedSubProblem + s[0];
}

Similarly to find the nth Fibonacci number the subproblems will be finding the Fibonacci terms (n-1) and (n-2) and the addition of these two terms will give the solution for the nth Fibonacci term.

and the base condition, in this case, will be for n = 0 and n = 1 as there are no two previous terms for these values

int fibonacci(int n){
    if(n == 0) return 0;
    if(n == 1) return 1;
    int term1 = fibonacci(n-1);
    int term2 = fibonacci(n-2);
    return term1+term2;
}