Forem: Shivay Lamba

The LiteLLM Supply Chain Attack: A Wake-Up Call for AI Infrastructure

Shivay Lamba — Fri, 27 Mar 2026 15:24:29 +0000

A routine dependency install triggered one of the most serious supply chain incidents in the AI ecosystem. A compromised release of LiteLLM, an AI gateway with about 97 million monthly downloads, introduced malicious code that quietly extracted sensitive credentials from developers' systems. The attack needed no explicit action. Simply installing the affected package was enough to begin data exfiltration.

What makes this significant is how it happened and what it exposed. The breach began upstream in the software supply chain and exploited trust in CI/CD pipelines and dependency systems. It did not go after users directly. Even well-secured environments were affected by normal development workflows.

The scale of concern became clear when voices like Andrej Karpathy, former director of Tesla AI and former research scientist at OpenAI, pointed out how dangerous supply chain attacks have become, with Elon Musk reinforcing the need for caution.

source: https://x.com/karpathy/status/2036487306585268612?s=20

This points to a deeper issue in how modern AI infrastructure is built and trusted. In this article, let us examine what happened, how the attack unfolded, and what it means for building safer AI systems going forward.

Incident Overview: Scope, Timeline, and Entry Point

The issue began days before the public release. On March 19, the attacker group TeamPCP changed Git tags in the Trivy GitHub Action to point to a malicious build that carried a credential harvester.

Trivy runs deep within many CI/CD pipelines, including LiteLLM. It became a quiet but effective entry point. On March 23, a similar pattern appeared in Checkmarx KICS and the domain models.litellm.cloud was registered just before the main event.

On March 24 at 10:39 UTC, LiteLLM’s CI/CD pipeline ran the compromised Trivy scanner without version pinning. That gap exposed the PyPI publish token from the GitHub Actions environment. Within hours, two malicious versions were released and stayed available until about 16:00 UTC.

Version 1.82.7: Malicious code placed in proxy_server.py, triggered on import
Version 1.82.8: A .pth file that runs on every Python startup, no import needed

pip install litellm

A simple install like this could pull sensitive data such as SSH keys, cloud credentials, API keys, and more. The data was encrypted and quietly sent out. The breach came to light only after a bug in the attacker’s code caused a system crash, exposing activity that would have stayed hidden through a transitive dependency.

How the Attack Moved Through Trusted Systems

The attack began outside LiteLLM and moved through trusted systems until it reached developers.

Attackers changed the Trivy GitHub Action and pointed it to a malicious version
LiteLLM’s CI CD pipeline used it without fixing a specific version
The scanner pulled the PyPI publishing token from the pipeline
Attackers used this access to release malicious LiteLLM versions
Developers installed or updated the package and received the compromised code

Each step depended on trust. The pipeline relied on the scanner, and developers relied on the package source. Nothing seemed unusual at each step.

The attack spread through everyday workflows, including indirect installs through dependencies. Many systems were exposed, and developers remained unaware. This points to a clear issue. Risk extends beyond application code and includes the tools and systems that support it.

Understanding the True Impact of the Breach

The impact of this attack was severe. A simple install gave access to sensitive data across developer systems.

Attackers could access SSH keys, cloud credentials, Kubernetes secrets, API keys, CI CD tokens, and database passwords. Shell history, git credentials, and crypto wallets were also exposed .

This data was then encrypted and sent to an external domain. The process ran quietly in the background and gave no clear signal to the user. If Kubernetes access was present, the attack extended further. It could read cluster secrets and create privileged workloads to maintain access inside the system.

This level of access goes beyond a single application. It opens the door to full control of infrastructure across environments. AI systems increase this risk further. Tools like LiteLLM act as a central layer for multiple provider keys and requests. Once exposed, the impact spreads across connected services.

What This Reveals About Modern AI Systems

This event highlights key patterns in how modern AI systems are built and where risk enters.

Deep Dependency Chains: Modern AI stacks rely on multiple external packages layered atop one another. Many dependencies are indirect, which makes them harder to track. A single weak link can affect the entire system.
Trust Across Layers: CI CD pipelines trust external tools. Build systems’ trust dependencies. Developers trust package registries. Each layer depends on the next, creating a chain that attackers can move through step by step.
Centralized Gateway Design: AI gateways such as LiteLLM collect keys from multiple providers and route all requests through a single layer. This improves convenience but increases risk. Exposure at this layer affects every connected service.
Limited Visibility: Teams often lack clear insight into what runs inside pipelines or which dependencies are pulled in indirectly. This reduces early detection and slows response.
Security Scope Gaps: Security efforts often focus on application code. Supporting systems such as pipelines, tools, and dependencies receive less attention, even though they carry equal risk.

The Risk Built into Modern AI Architectures

The earlier points highlight a gap. Deep dependency chains, layered trust across systems, centralized gateways, and limited visibility increase risk across AI infrastructure.

Core functions like API routing and key handling often rely on large dependency chains. As these layers grow, exposure increases. The same structure that supports speed also creates entry points for compromise. Addressing this requires architectural changes, including reducing exposure to dependencies, isolating critical components, and maintaining tighter control over execution environments.

AI gateways sit at a critical layer, handling traffic, managing keys, and connecting providers, which makes their design directly tied to system risk.

Building Low-Exposure AI Infrastructure with Bifrost

For teams evaluating options right now, the focus should be on how a gateway limits the impact of a compromised dependency. This depends on how the system is designed and where control is maintained across it.

Bifrost is an open-source AI gateway that routes and manages requests across 20+ model providers through a single interface. Keys, traffic, and access stay under your control.

Its design takes a different path at the architectural level. The PyPI attack surface is removed entirely. Built in Go, Bifrost runs as a single binary or container, which removes the need for pip installs, avoids a Python runtime inside the gateway, and eliminates dependency chains that can be altered during installation.

Control remains within the user’s environment because Bifrost runs on private networks, where traffic and credentials remain internal. Key management is handled through direct integration with systems such as HashiCorp Vault, AWS Secrets Manager, GCP, and Azure, where secrets stay in managed storage with controlled access and clear audit visibility.

Comparative Overview: LiteLLM vs. Bifrost

The differences become clearer when both approaches are viewed side by side across key areas of risk, control, and deployment.

Category	LiteLLM	Bifrost
Language	Python (PyPI)	Go (binary/Docker)
Supply chain exposure	High	Eliminated (no pip dependency)
Credential storage	Environment/config-based	Vault-integrated
Deployment model	Application-level	In-VPC, isolated
Audit capability	Limited	Immutable, SIEM-ready
Migration effort	—	One-line configuration change
Performance	—	~11 µs overhead at scale
Compatibility	Native	Full LiteLLM compatibility

Closing Thoughts

The LiteLLM incident leaves a lasting takeaway. Systems built on layers of trust, dependencies, and software supply chains carry risk that spreads faster than expected. AI gateways sit at the center of this setup, which makes their design choices critical to overall security.

This is a moment to rethink how these systems are structured. Reducing dependency exposure, separating critical components, and maintaining control within your own environment can limit how far an issue can travel across the supply chain.

Bifrost follows this direction. Its design reduces exposure to dependencies, keeps credentials within managed systems, and runs in controlled environments, which helps limit the spread of similar attacks. To see how this approach can be applied, explore the Bifrost documentation.

If you do not know what each dependency in your AI stack has access to, that is the first thing to fix.

How I built a Content Curator CLI using Github Copilot CLI SDK

Shivay Lamba — Sun, 25 Jan 2026 19:44:21 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

Building Content Curator: CLI + Copilot SDK

I wanted a simple but practical project to test out the Copilot SDK. I ended up creating an AI-powered CLI that uses Copilot’s agentic core along with real-time web search (via Exa AI) to generate short-form video ideas, hooks, and full scripts for Reels, YouTube Shorts, and TikTok.

Repo: github-copilot-cli-sdk-content-curator

How Content Curator Uses GitHub Copilot SDK & Exa AI

1. Initializing the Copilot Client

At the heart of the app is the CopilotService class, which manages the AI client lifecycle:

this.client = new CopilotClient(clientOptions);
await this.client.start();
await this.createSession();

CopilotClient connects directly to Copilot models installed locally via the CLI.
client.start() initializes the client, preparing it for session creation.
createSession() sets up a streaming session with the chosen model and system prompt.

2. Session Management

Each AI session represents a continuous conversation with the Copilot model:

this.session = await this.client!.createSession({
  model: this.currentModel,
  streaming: true,
  systemMessage: { mode: "append", content: SYSTEM_PROMPT_BASE },
});

model – Determines which Copilot model (GPT-4o, GPT-5, Claude, etc.) powers content generation.
streaming: true – Enables partial outputs to be sent in real time, allowing the CLI to render content as it’s being generated.
systemMessage – Provides base instructions for the agent, ensuring that generated content matches the expected format for short-form videos.

3. Prompt Workflow

Content Curator sends structured prompts to Copilot for:

Content generation (/script, /ideas, /hooks)
Content refinement (/refine)
Generating variations (/more-variations)

Example:

const promptWithSearch = `${searchResults}

---

${basePrompt}`;

await this.sendPrompt(promptWithSearch, contentType);

Incorporates real-time search results from Exa AI to ensure generated content is relevant and up-to-date.
Supports topic- and platform-specific instructions, so scripts are optimized for Instagram, TikTok, or YouTube Shorts.

Using CopilotClient directly allows Content Curator to:

Maintain persistent AI sessions with context across multiple commands.
Stream outputs in real time, providing an interactive user experience.
Dynamically switch models without restarting the application.

Why Choose Copilot SDK Over Generic LLM Clients?

There are several strong reasons to prefer the Copilot SDK over generic LLM clients:

GitHub-native workflows – Direct access to repos, files, and workflows.
Built-in agentic behavior – Conversations, tools, reasoning, and MCP support.

The kinds of apps you can build with the Copilot SDK go well beyond content curation:

Summarizing PRs and generating release notes
Creating learning-path threads from a repository
Querying personal knowledge stores
Building CLIs and custom GUIs for AI agents

Conclusion

The Copilot SDK exposes the agentic capabilities of the Copilot CLI—including planning, tool execution, and multi-turn workflows—directly in your preferred programming language. This allows you to integrate Copilot into any environment, whether you’re building:

GUIs with AI workflows
Personal productivity tools
Custom internal agents for enterprise processes

Essentially, the SDK acts as an execution platform. It provides the same agentic loop that powers the Copilot CLI, while GitHub manages authentication, models, MCP servers, and streaming sessions.

You remain fully in control of what you build on top of these core capabilities.

Demo

Here's the project link - https://github.com/shivaylamba/github-copilot-cli-sdk-content-curator

Video Walkthrough - https://www.youtube.com/watch?v=znmkkjpntKc

My Experience with GitHub Copilot CLI

I used GitHub Copilot CLI extensively while building this project, primarily as a thinking partner rather than just a code generator. It helped me move faster from intent to implementation by translating natural-language prompts into concrete shell commands, code snippets, and workflow suggestions directly in the terminal.

Copilot CLI was especially useful during early development and iteration. Whether it was scaffolding project structure, generating boilerplate code, debugging errors, or suggesting optimized commands, it reduced context switching between the editor, browser, and documentation. I could stay focused on the problem I was solving instead of searching for syntax or command references.

One of the biggest impacts was how it accelerated experimentation. I could quickly try alternative approaches, validate ideas, and refine implementations by asking follow-up questions in the CLI itself. This made the development process more interactive and exploratory, particularly when working with unfamiliar tools or configurations.

Overall, GitHub Copilot CLI significantly improved my productivity and flow. It didn’t replace my understanding or decision-making, but it acted as a powerful assistant that helped me write, test, and iterate faster—especially in moments where friction would normally slow development down.

How I Used GitLab Duo Agent Platorm to Build a Conference Demo in under an hour

Shivay Lamba — Thu, 08 Jan 2026 22:14:31 +0000

Learn how the Gitlab Duo Agent Platform helped me design and ship a complete GitLab CI pipeline: emitting OTel traces and integrating with Argo, in just one hour before my KubeCon talk.

Building a live demo for a conference can feel overwhelming. A few weeks ago, I committed myself to building an entire end-to-end CI/CD observability demo for my talk at KubeCon using Argo Workflows, Argo CD, and OpenTelemetry. But as anyone who has built live demos knows, things rarely stay simple. Between trace propagation, pipeline wiring, and environment setup, the list of moving pieces grows fast.

And then came the curveball. The original demo only included Argo Workflows and ArgoCD, with no CI component at all, and just one hour before my talk, my co-presenter and I decided that GitLab CI needed to be part of the story. That meant creating a pipeline, instrumenting it with OTel, wiring it to Argo, and exporting everything to SigNoz. Thankfully, I also had a secret superpower: the GitLab Duo Agent Platform. It became the key to building a fully functioning CI demo in record time.

Setting the Scene - What we wanted to show in our talk

While production observability is mature, visibility into the CI/CD journey before code reaches production is often missing. Thus, I and my co-presenter were presenting a KubeCon talk focused on end-to-end CI/CD observability using OpenTelemetry. In the session, we introduced CI/CD observability using OTel, with a deep dive into Argo Workflows and ArgoCD, showing how a single code change moves through GitLab CI, Argo Workflows, and Argo CD, all stitched together using OpenTelemetry’s new CI/CD semantic conventions.

Our goal was to highlight how the latest OTel CI/CD Semantic Conventions provide a vendor-neutral way to instrument every stage of the delivery pipeline, that is from build to deployment, thus making CI/CD telemetry just as accessible and standardized as application telemetry. We covered how to emit traces and metrics from Argo Workflows and ArgoCD, and how OTel can surface critical signals like job duration, workflow execution latency, deployment failures, and promotion events.

The original demo only covered ArgoCD, with no CI component at all. But just an hour before our presentation, during a quick conversation with my co-presenter, we realized that the story would be incomplete without showing how GitLab CI fits into the end-to-end trace flow.

GitLab Duo Agent Platform saves the day

To keep the talk impactful, we needed a fully working end-to-end demo: a commit triggering GitLab CI, emitting spans from each stage, launching an Argo Workflow for integration testing, handing off to ArgoCD for deployment, and finally showing a single trace in our SigNoz dashboard. Doing this manually would not have been possible in 1 hour, but with the Gitlab Duo Agent Platform we were able to generate the GitLab CI integration complete with OTel spans, otel-cli setup, trace propagation, and Argo Workflow submission in under an hour. That last-minute addition ended up becoming the highlight of our session.

To extend the talk demo to include CI, I needed GitLab CI to become part of the same end-to-end trace that already included Argo Workflows and Argo CD. So I asked Duo to help me generate the missing CI integration. Here’s the exact prompt I used:

I already have my OTel demo working for Argo Workflows and Argo CD using OTEL CLI. Now I also want to integrate the CI layer using GitLab CI.

Use a GitLab Runner to emit OTel spans via OTEL_EXPORTER_OTLP_ENDPOINT.

Wrap the key GitLab stages:  build, test, package,  using OpenTelemetry SDK calls so each step appears as a span. 

Export all CI traces to SigNoz (OTLP endpoint).

Finally, show how the GitLab job (build) can trigger an Argo Workflow (integration test) which then leads to an Argo CD deployment — all stitched together through trace context propagation.

The final output should create one seamless story:

 Commit → GitLab CI → Argo Workflow → Argo CD → Deployment → Observability Dashboard.”*

This became the starting point for the GitLab CI configuration that powered my KubeCon demo. Using the DAP agent I generated a .gitlab-ci.yml in minutes. The resulting pipeline includes four stages, each emitting its own OpenTelemetry span to trace the CI/CD execution. Every job installs otel-cli and creates a span that represents that stage of the pipeline (build, test, or package). In the integration stage, the pipeline installs the Argo CLI and automatically submits an Argo Workflow. This allowed the GitLab CI trace to seamlessly connect with the downstream Argo Workflow execution, creating a unified, end-to-end observability story.

Demo

You can check the live demo of the CI pipeline here:

And you find the code for the CI/CD pipeline here: https://gitlab.com/shivaylamba/kubecongitlabdemo

Final Thoughts

With just a few prompts and light debugging, the Duo Agent Platform helped me build the entire GitLab CI flow for the KubeCon demo in just about an hour, something that would normally take much longer. But the capabilities of Duo Agent Platform doesn’t end at helping create your code, you can also use the Duo Agent Platform with your GitLab CI environment to debug runners, optimize jobs, reason about logs, fix pipeline failures, and even explain complex YAML configurations.

How I Built an Agentic RAG Application to Brainstorm Conference Talk Ideas

Shivay Lamba — Tue, 08 Jul 2025 23:16:09 +0000

TL;DR

I love speaking at technical conferences. But in order to get selected to speak at the event, you need to submit a strong talk proposal or abstract—one that clearly shows relevance, technical depth, and actionable takeaways for the audience attending your talk. A good abstract isn’t just about the idea itself; it needs to show why the topic matters right now and how the talk will benefit attendees. At the same time, you want to avoid repeating something that’s already been presented.

To solve this, I built an AI-powered agentic application that helps me ideate and draft compelling talk abstracts. It uses a research agent to do deep research on a topic—finding the latest trends, developments, and active discussions—and combines that with fast vector search using Couchbase over previous talks on the same subject from past conferences. In this case, the system is specifically designed for KubeCon, and in this post, I’ll walk you through how I built the full pipeline to create a conference talk brainstorming AI tool.

You can find the code for this project here.

Important Note 🚨

The goal of the agent is just to provide a well structured abstract idea. One shouldn't just directly copy this AI generated abstract and submit it. But use it as a source of reference and draft an original handcrafted proposal.

Tech Stack

I used a mix of tools to build this project, each handling a different part of the process. Google ADK helps run the AI agents, Couchbase stores past Kubecon talks data and performs the vector search, and Nebius Embedding model for generating embeddings and LLM models (Example: Qwen) generates summaries and talk abstracts.

Complete Pipeline Flow / Architecture Deep Dive

The system is built as a modular, multi-stage pipeline that combines historical data with real-time research to generate high-quality talk proposal ideas.

Step 1: URL Extraction / Data Collection (`extract_events.py`)

Purpose: Scrape and extract all available KubeCon talk URLs from official conference schedule pages.

# Save the KubeCon schedule HTML to a file, then run:
python extract_events.py < schedule.html

What it does:

Parses HTML content from stdin
Extracts all event URLs with pattern event/
Merges with existing URLs in event_urls.txt
Outputs the count of new URLs discovered

Output: event_urls.txt - Contains all unique talk URLs

Step 2: Talk Data Crawling / Data Ingestion (`couchbase_utils.py`)

Purpose: Crawl each talk page, extract structured metadata (title, description, speakers, tags, etc.), and store it in Couchbase using well-defined document schemas.

python couchbase_utils.py

What it does:

Reads URLs from event_urls.txt
Uses AsyncWebCrawler to fetch talk pages in batches
Extracts structured data:
- Title
- Description
- Speaker(s)
- Category
- Date
- Location
Stores directly to Couchbase with document keys like talk_<event_id>

Features:

Batch processing (5 URLs at a time)
Error handling and retry logic
Progress tracking with success/failure counts
Automatic document key generation

Step 3: Embedding Generation (`embeddinggeneration.py`)

Purpose: Generate semantic vector embeddings from talk content (title + description + category) using the intfloat/e5-mistral-7b-instruct model from Nebius AI Studio, and store them back in Couchbase for fast vector search.

python embeddinggeneration.py

What it does:

Queries all documents from Couchbase
Combines title, description, and category into searchable text
Generates embeddings using intfloat/e5-mistral-7b-instruct model
Updates documents with embedding vectors
Enables vector search functionality

Model: Uses Nebius AI's embedding endpoint for high-quality vectors

Step 4: Agent + RAG Application (`talk_suggestions_app.py`)

Purpose: The user inputs a rough topic idea via the Streamlit interface. The system runs both the research agent and vector search in parallel, then combines the outputs using a Nebius AI LLM to generate a unique, well-structured abstract with key takeaways.

streamlit run kubecon-talk-agent/talk_suggestions_app.py

Core Features:

On one side, the application performs a vector search through a database (Couchbase) of past KubeCon talks to understand what’s already been covered. On the other, it leverages a web research agent powered by Google ADK to gather the latest trends, technical developments, and community discussions around the topic. This leads into a three-stage generation process: the Research Phase, where the agent collects up-to-date context; the Retrieval Phase, where similar historical talks are surfaced; and the Synthesis Phase, where an LLM merges both streams into a compelling proposal.

Let's look a bit deeper into the 3 step process:

Research Agent Execution

I created a custom multi-agent research system using Google ADK (Agent Development Kit). This system is designed to autonomously explore the to research emerging trends across the CNCF ecosystem in real-time from trusted sources.

Here's how it works under the hood:

Parallel Execution for Web Research

The first step involves spinning up multiple research agents that gather insights independently from different web sources. I use a ParallelAgent to run all of these at the same time:

ExaAgent: Leverages the Exa API to search for recent high-quality blogs, articles, and summaries published in the past 90 days.

TavilyAgent (optional): Pulls developer sentiment and discussion threads from platforms like Reddit, X (formerly Twitter), and Dev.to.

LinkupAgent (optional): Surfaces curated technical posts, deep-dives from sites like GitHub and Hacker News.

Each of these tools is wrapped in its own LlmAgent, configured with dynamic instructions based on the user’s topic. Because they operate independently, they don’t interfere with one another and collectively reduce total response time.

These agents are executed in parallel using a ParallelAgent, ensuring low latency and independent execution. Once all the raw data is collected, it is passed to a SummaryAgent, which synthesizes the results into a clean, structured summary using a powerful LLM (nebius/Qwen/Qwen3-235B-A22B).

Sequential Reasoning for Synthesis and Insight

Once all agents (ParallelAgent) complete their respective searches, I combine their outputs into a single structured flow.

Other than search agents, the entire pipeline with steps like summarization and analysis is being done sequentially, managed using ADK’s SequentialAgent:

SummaryAgent: This agent synthesizes the raw research results into a cohesive, structured Markdown summary. It filters the highlights common themes, and stitches together the key insights from the research agents.

AnalysisAgent: This agent reviews the summary and delivers deeper insights including:

Key Trends – Major developments or patterns observed
Novel Angles – Unique viewpoints or underexplored ideas
Unanswered Questions – What the community is still trying to figure out
Contrarian Viewpoints – Active debates or non-mainstream takes

This sequential setup is intentional: the AnalysisAgent depends on the clean output from the SummaryAgent. Running them in parallel would reduce quality and coherence.

The Orchestration Layer

The full pipeline is managed through ADK’s orchestration features:

ParallelAgent → for running web search agents
SequentialAgent → for dependent reasoning steps
Runner → to execute the pipeline
InMemorySessionService → for fast, stateless execution

Here's a simplified breakdown of the pipeline:

def run_adk_research(topic: str) -> str:
    # 1. Setup Models
    nebius_base_model = LiteLlm(model="nebius/Qwen/Qwen3-235B-A22B", api_key=os.getenv("NEBIUS_API_KEY"))

    # 2. Define Agents
    exa_agent = LlmAgent(
        name="ExaAgent",
        model=nebius_base_model,
        instruction=f"Use the exa_search_ai tool to fetch the latest news and developments about '{topic}'.",
        tools=[exa_search_ai],
        output_key="exa_results"
    )

    # 3. Summarize Results
    summary_agent = LlmAgent(
        name="SummaryAgent",
        model=nebius_base_model,
        instruction="""
            You are a meticulous research summarizer. Combine the results from 'exa_results' 
            into a cohesive markdown summary. Focus on trends, notable discussions, and 
            community sentiment.
        """,
        output_key="final_summary"
    )

    # 4. Execute Pipeline
    pipeline = SequentialAgent(
        name="AIPipelineAgent",
        sub_agents=[
            ParallelAgent(name="ParallelSearch", sub_agents=[exa_agent]),
            summary_agent
        ]
    )

    runner = Runner(agent=pipeline, app_name="adk_research_app", session_service=InMemorySessionService())

    content = types.Content(role="user", parts=[types.Part(text=f"Start analysis for {topic}")])
    events = runner.run(user_id="streamlit_user", session_id="session_xyz", new_message=content)

    for event in events:
        if event.is_final_response():
            return event.content.parts[0].text

    return "Failed to generate summary."

Retrieval Agent Execution

Once real-time research is complete, the system now proceeds to retrieving historical context from past KubeCon talks. This is done using Couchbase vector search, which allows us to compare the semantic similarity of the user's idea with previous talk proposals.

What happens here?

We take the user’s query and generate an embedding using intfloat/e5-mistral-7b-instruct via Nebius' embedding API.

We then perform a vector search against a kubecontalks index in Couchbase that stores embeddings of historical talks.

Finally, we fetch the metadata (title, speaker, category, description) for the top matching talks.

This helps us:

Understand what’s already been covered.
Avoid duplicate proposals.
Borrow inspiration from successful submissions

Here's the sample code for the same:

class CouchbaseConnection:
    def __init__(self):
        connection_string = os.getenv('CB_CONNECTION_STRING')
        username = os.getenv('CB_USERNAME')
        password = os.getenv('CB_PASSWORD')
        bucket_name = os.getenv('CB_BUCKET')
        collection_name = os.getenv('CB_COLLECTION')

        auth = PasswordAuthenticator(username, password)
        options = ClusterOptions(auth)
        self.cluster = Cluster(connection_string, options)
        self.bucket = self.cluster.bucket(bucket_name)
        self.scope = self.bucket.scope("_default")
        self.collection = self.bucket.collection(collection_name)
        self.search_index_name = os.getenv('CB_SEARCH_INDEX', "kubecontalks")

    def generate_embedding(self, text: str) -> List[float]:
        client = OpenAI(base_url=os.getenv("NEBIUS_API_BASE"), api_key=os.getenv("NEBIUS_API_KEY"))
        response = client.embeddings.create(
            model="intfloat/e5-mistral-7b-instruct",
            input=text,
            timeout=30
        )
        return response.data[0].embedding

    def get_similar_talks(self, query: str, num_results: int = 5) -> List[Dict[str, Any]]:
        embedding = self.generate_embedding(query)
        search_req = SearchRequest.create(MatchNoneQuery()).with_vector_search(
            VectorSearch.from_vector_query(
                VectorQuery("embedding", embedding, num_candidates=num_results)
            )
        )
        result = self.scope.search(self.search_index_name, search_req)
        rows = list(result.rows())

        similar_talks = []
        for row in rows:
            doc = self.collection.get(row.id)
            if doc and doc.value:
                talk = doc.value
                similar_talks.append({
                    "title": talk.get("title", "N/A"),
                    "description": talk.get("description", "N/A"),
                    "category": talk.get("category", "N/A"),
                    "speaker": talk.get("speaker", "N/A"),
                    "score": row.score
                })
        return similar_talks

The results of this phase are then passed into the final synthesis stage.

Synthesis Phase

The final phase brings everything together: the user’s idea, the ADK-generated real-time insights, and the similar historical talks.

The goal is to produce a talk propsal idea proposal that is:

Timely – aligned with current trends.
Unique – not duplicating past talks.
Actionable – with clear learning objectives and audience fit.

How it works?

We use a LLM (Qwen/Qwen3-235B-A22B) to analyze:

User’s raw idea
Web analysis from the research agent
Historical KubeCon talks from vector search

We then ask the model to synthesize all of this into a structured format containing:

Title
Abstract
Key Learning Objectives
Target Audience
Why this talk is unique

def generate_talk_suggestion(query: str, similar_talks: List[Dict[str, Any]], adk_research: str) -> str:
    historical_context = "\n\n".join([
        f"Title: {talk['title']}\nDescription: {talk['description']}\nCategory: {talk['category']}"
        for talk in similar_talks
    ]) if similar_talks else "No similar talks found."

    prompt = f"""
You are an expert in cloud-native conference planning.

User's Idea:
{query}

PART 1: Historical Talks
{historical_context}

PART 2: Web Research
{adk_research}

Your task is to generate a fresh and compelling talk proposal. Follow this structure:

**Title:**  
*A catchy title that grabs attention.*

**Abstract:**  
*2–3 paragraphs outlining the core idea, approach, and takeaways.*

**Key Learning Objectives:**  
- Bullet 1  
- Bullet 2  
- Bullet 3  

**Target Audience:**  
*Beginner SREs? Advanced Platform Engineers?*

**Why This Talk is Unique:**  
*Explain how it differs from existing talks and addresses a fresh trend or gap.*
"""

    client = OpenAI(api_key=os.getenv("NEBIUS_API_KEY"), base_url=os.getenv("NEBIUS_API_BASE"))
    response = client.chat.completions.create(
        model="Qwen/Qwen3-235B-A22B",
        messages=[
            {"role": "system", "content": "You are a cloud-native conference program advisor."},
            {"role": "user", "content": prompt}
        ],
        temperature=0.7,
        max_tokens=2048
    )
    return response.choices[0].message.content

This is where the magic happens. The model takes a dual-context approach—both fresh insights and past data—to recommend a proposal that’s:

grounded in reality,
informed by what’s already been done
provides real world use-cases

Final thoughts

Building this made me realize that talk ideation is just another AI use case. Blending historical talk data with up-to-the-minute research minimizes time and effort spent to getting latest information and having to spend time finding previous talks on the topics.

AI Agents help simplify tasks and can orchestrate complex workflows with ease.

Curious to try this for your own conference? Drop me a note—I’d love to hear your ideas and evolve this further with the community!

Using Nebius AI Models with LangChain/Langgraph via LiteLLM

Shivay Lamba — Mon, 09 Jun 2025 19:33:08 +0000

Note: there is a Python package for Nebius Langchain https://pypi.org/project/langchain-nebius/
This approach is an alternative approach with LiteLLM

Nebius AI Studio is a platform from Nebius that simplifies the process of building applications using AI models. It provides a suite of tools and services for developers to easily test, integrate and fine-tune various AI models, including those for text and image generation.
You can checkout the list of available models here.

LangChain is one of the most popular open source frameworks for building Generative AI / LLM based applications.

Thus in this blog we will cover how you can use LiteLLM to access Nebius AI Studio Models when building LLM/Agentic Applications with Langchain and Langgraph (LangGraph is an open source AI agent framework designed to build, deploy and manage complex generative AI agent workflows).

LiteLLM Nebius AI provider

LiteLLM is a library and proxy server that simplifies interactions with various Large Language Model (LLM) APIs, allowing developers to use a consistent interface with over 100 different LLMs. It essentially provides a standardized OpenAI API format for these different providers, making it easier to switch between them without rewriting code.

LiteLLM includes Nebius AI Studio as one of the LLM providers.

In order to use a Nebius Model with LiteLLM, ensure you have the NEBIUS_API_KEY set as an environment variable.
os.environ['NEBIUS_API_KEY'] = "insert-your-nebius-ai-studio-api-key"

This is how we can use a Nebius Model:
model="nebius/Qwen/Qwen3-235B-A22B"

Using LiteLLM with LangChain

You can use the ChatLiteLLM chat model from the LangChain Community models.

from langchain_community.chat_models import ChatLiteLLM
And here's how you can use Nebius AI model with ChatLiteLLM

from langchain_community.chat_models import ChatLiteLLM

# Create LLM class
llm = ChatLiteLLM(model="nebius/Qwen/Qwen3-235B-A22B")

Creating an ReAct Agent with Langgraph

Once you have initialized the LLM, you can now use to create agents with Langgraph.

In the example below example, we are using Langgraph to create a ReAct agent that can interact with a Couchbase database using Model Context Protocol. ReAct Agents iteratively think, use tools, and act on observations to achieve user goals, dynamically adapting their approach. LangGraph offers a prebuilt ReAct agent (create_react_agent).

from langchain_mcp_adapters.tools import load_mcp_tools
from langgraph.prebuilt import create_react_agent
from langgraph.checkpoint.memory import InMemorySaver
from langchain_community.chat_models import ChatLiteLLM

import os
# env variable
os.environ['NEBIUS_API_KEY']

llm = ChatLiteLLM(
model="nebius/Qwen/Qwen3-235B-A22B",
)

async def main():
    async with stdio_client(server_params) as (read, write):
        async with ClientSession(read, write) as session:
            # Initialize the connection
            print("Initializing connection...")
            await session.initialize()

            # Get tools
            print("Loading tools...")
            tools = await load_mcp_tools(session)

            # Create and run the agent
            print("Creating agent...")
            checkpoint = InMemorySaver()

            agent = create_react_agent(
                llm, 
                tools,
                prompt=system_prompt,
                checkpointer=checkpoint
            )

            print("-"*25, "Starting Run", "-"*25)
            await qna(agent)

The main function ties everything together to set up and run our agent:

Start & Connect to MCP Server: It first starts the mcp-server-couchbase process using stdio_client and establishes a communication ClientSession with it.
Initialize Session & Load Tools: The session is initialized. Then, load_mcp_tools queries the MCP server to get the available Couchbase tools and prepares them for LangChain.
Set Up Agent Memory: InMemorySaver is created to allow the agent to remember conversation history.
Create ReAct Agent: The create_react_agent function builds our AI agent, providing it with the language model, the Couchbase tools, our system_prompt, and the checkpoint for memory.
Run Q&A: Finally, it calls the qna function, passing the created agent to start the question-and-answer process with the database.

You dive deeper into this example, you can checkout the Github Repository for this project.

Conclusion

While Nebius AI Studio doesn't yet have direct integrations with LangChain, the flexibility of the AI dev ecosystem means you’re not stuck waiting. With LiteLLM, you can use Nebius Models with LangChain/Langgraph to build agentic applications.

Building a Multi-Agent RAG System with Couchbase, CrewAI, and Nebius AI Studio

Shivay Lamba — Thu, 05 Jun 2025 03:27:08 +0000

Traditional RAG systems typically follow a linear approach: retrieve documents, generate a response, and present it to the user. While effective, this approach can lack the nuanced understanding and specialized processing that complex queries often require. In contrast, AI agents introduce a more dynamic and intelligent workflow to RAG-based operations. They can collaborate, iterate, and critique each other’s outputs, enabling deeper understanding and more coherent responses. This agent-driven approach transforms RAG from a static process into an adaptive system capable of producing higher-quality, context-aware content.

In this blog post, we’ll guide you through building a powerful semantic search engine using Couchbase as the database, CrewAI for agent-based Retrieval-Augmented Generation (RAG) operations, and Nebius AI Studio for the LLM and embedding model.

What is CrewAI?

CrewAI is an open-source Python framework that supports developing and managing multi-agent AI systems.

What sets CrewAI apart is its ability to facilitate collaborative task handling and goal-driven execution, enabling agents to work together efficiently toward shared outcomes. It incorporates iterative thinking and feedback loops, allowing agents to refine their decisions and outputs continuously. It also offers seamless communication between the agents.

Building a Multi-Agent RAG System with Couchbase and CrewAI

The foundation of this example is a powerful semantic search engine using Couchbase as the vector database and CrewAI for agent-based RAG operations. CrewAI allows us to create specialized agents that can work together to handle different aspects of the RAG workflow, from document retrieval to response generation.

Setting Up LLM Components

For this project, we chose Nebius AI Studio as our LLM and embedding provider. Nebius AI Studio is a platform that simplifies the process of building applications using AI models. It provides a suite of open-source LLM and embedding models.

Extending the base OpenAI LLM

For the CrewAI LLM, we replace the base_url with the Nebius AI Studio endpoint: https://api.studio.nebius.com/v1/, define the model we wish to use, and add the NEBIUS_AI_KEY API key

# Define the LLM with Nebius AI Studio
llm = LLM(
    model="openai/meta-llama/Meta-Llama-3.1-70B-Instruct",
    base_url="https://api.studio.nebius.com/v1/",
    api_key=os.getenv('NEBIUS_AI_KEY')
)

Creating the NebiusEmbeddings Class

LangChain doesn’t natively support Nebius’s API. To bridge this gap, we created a custom NebiusE5MistralEmbeddings class that extends LangChain’s Embeddings interface, allowing seamless integration with Nebius’s embedding model:

from langchain_core.embeddings import Embeddings
from typing import List
import requests

class NebiusEmbeddings(Embeddings):
    def __init__(self, api_key: str, model: str = "BAAI/bge-en-icl"):
        self.api_key = api_key
        self.model = model
        self.base_url = "https://api.studio.nebius.ai/v1/embeddings"

    def embed_documents(self, texts: List[str]) -> List[List[float]]:
        """Embed a list of documents using Nebius AI Studio."""
        headers = {
            "Authorization": f"Bearer {self.api_key}",
            "Content-Type": "application/json"
        }

        payload = {
            "model": self.model,
            "input": texts
        }

        response = requests.post(self.base_url, json=payload, headers=headers)
        response.raise_for_status()

        data = response.json()
        return [item["embedding"] for item in data["data"]]

    def embed_query(self, text: str) -> List[float]:
        """Embed a single query using Nebius AI Studio."""
        return self.embed_documents([text])[0]

embeddings = NebiusE5MistralEmbeddings(
    api_key=os.getenv('NEBIUS_AI_KEY'),  # Or set NEBIUS_API_KEY environment variable
    model="intfloat/e5-mistral-7b-instruct"
)

This class implements embed_documents for processing batches of text and embed_query for individual search queries, interacting directly with the Nebius API endpoint. Nebius AI Studio supports various embedding models, including BGE and E5-mistral.

Setting Up the Couchbase Vector Store

We initialize the Couchbase vector store and ingest the articles in batches:

from langchain_couchbase.vectorstores import CouchbaseVectorStore

vector_store = CouchbaseVectorStore(
    cluster=cluster,
    bucket_name=CB_BUCKET_NAME,
    scope_name=SCOPE_NAME,
    collection_name=COLLECTION_NAME,
    embedding=embeddings,
    index_name=INDEX_NAME
)

batch_size = 100
articles = [article for article in unique_articles if len(article) <= 50000]
vector_store.add_texts(texts=articles, batch_size=batch_size)
logging.info("Document ingestion completed successfully.")

Creating a Vector Search Tool with CrewAI

We create a vector search tool to allow CrewAI agents to retrieve relevant documents:

from crewai.tools import tool

retriever = vector_store.as_retriever(search_type="similarity")

@tool("vector_search")
def search_tool(query: str) -> str:
    """Search for relevant documents using vector similarity."""
    docs = retriever.invoke(query)
    return "\n\n".join([f"Document {i+1}:\n{doc.page_content}" for i, doc in enumerate(docs)])

This tool:

Uses the vector store’s retriever to perform similarity searches.
Formats results for easy consumption by AI agents.

Defining the Agents

The Research Expert uses the vector store to retrieve relevant documents using the vector_search tool. The Technical Writer agent, also powered by the same model, takes the research output and generates a well-structured, reader-friendly response.

Here’s how we set up the agents

from crewai import Agent, Task, Crew, Process

# Research Expert Agent
researcher = Agent(
    role="Research Expert",
    goal="Retrieve and analyze relevant information from the vector store to answer user queries accurately.",
    backstory="A skilled data analyst with expertise in semantic search and information retrieval.",
    tools=[search_tool],
    llm=llm,
    verbose=True
)

# Technical Writer Agent
writer = Agent(
    role="Technical Writer",
    goal="Craft clear, concise, and well-structured responses based on research findings.",
    backstory="An experienced writer specializing in turning complex data into engaging narratives.",
    llm=llm,
    verbose=True
)

Defining Tasks

We define tasks for each agent to ensure a clear division of work:

# Research Task
research_task = Task(
        description=f"Research and analyze information relevant to: {query}",
        agent=researcher,
        expected_output="A detailed analysis with key findings and supporting evidence"
    )

# Writing Task
writing_task = Task(
        description="Create a comprehensive and well-structured response",
        agent=writer,
        expected_output="A clear, comprehensive response that answers the query",
        context=[research_task]
    )

The Crew object orchestrates the agents in a sequential process, where the Research Expert completes its task before passing the output to the Technical Writer.

Running the Crew!

With agents and tasks defined, it's time to kick off the crew. To demonstrate the agent workflow, we process a sample query about the FA Cup third round draw:

def process_query(query, researcher, writer):
    crew = Crew(
        agents=[researcher, writer],
        tasks=[research_task, writing_task],
        process=Process.sequential,
        verbose=True,
        cache=True,
        planning=True
    )
    return crew.kickoff(inputs={"query": query})

query = "What are the key details about the FA Cup third round draw? Include information about Manchester United vs Arsenal, Tamworth vs Tottenham, and other notable fixtures."
result = process_query(query, researcher, writer)
print(result)

This query triggers the following workflow:

The Research Expert uses the vector_search tool to retrieve relevant BBC News articles from the Couchbase vector store, leveraging Nebius’s embeddings for semantic similarity.
The agent analyzes the retrieved documents and generates a summary of key details, such as the historical context of Manchester United vs Arsenal and the potential for an upset in Tamworth vs Tottenham.
The Technical Writer takes this summary and crafts a polished article.

The console output during crew.kickoff() shows each agent thinking, using tools, and passing information to the next agent,

Final Thoughts

Building a semantic search engine with Couchbase, CrewAI, and Nebius AI Studio is a powerful way to leverage AI Agents to build more robust and accurate RAG applications. Couchbase’s vector search enables efficient semantic retrieval, CrewAI’s agent-based architecture streamlines the RAG workflow, and Nebius AI Studio’s models provide high-quality embeddings and language generation.

Agentic RAG provides a powerful foundation for building intelligent applications that can understand and respond to user queries with high relevance and accuracy.

Building Multi-Agent Workflows using Mastra AI and Couchbase

Shivay Lamba — Sun, 18 May 2025 00:43:41 +0000

TL;DR: In this post, we explore how to use Mastra AI — a TypeScript-native agent framework — with Couchbase Vector Search to build a production-ready, multi-agent RAG (Retrieval-Augmented Generation) blog-writing assistant.

2025 has marked a significant shift toward agent-based AI systems. There have been a large number of AI Agent frameworks released in the past few months. One such powerful agent framework is Mastra.

Mastra is an open-source TypeScript agent framework. You can use Mastra to build AI agents that have memory, can execute functions, or chain LLM calls in deterministic workflows. You can also feed them application-specific knowledge using RAG. Mastra also comes with built-in support for running evals and observability, making it very suitable for production use cases.

What are Mastra Workflows

There has been growing complexity in building robust AI applications. What starts as a simple LLM call quickly becomes extremely complex with a large number of agents, prompts, and coordination logic among agents. This is where Mastra workflows come in. The Mastra Workflows bring structure, reliability, and developer-friendly patterns to building generative AI applications.

Mastra workflows are graph-based state machines that allow you to orchestrate complex sequences of AI operations. Workflows let you define discrete steps with clear inputs, outputs, and execution logic.

This functionality combines the flexibility of TypeScript with the structure of a workflow engine.

With workflows providing orchestration, the next crucial component is knowledge retrieval. That’s where Couchbase Vector Store fits in.

Couchbase Vector Store for Mastra

Mastra now natively supports Couchbase as a vector store for RAG workflows.

In Mastra, you can process your documents into chunks, create embeddings, store them in a vector database, and then retrieve relevant context at query time.

Setting up the Couchbase vector store is relatively simple:

// Initialize Couchbase connection
const couchbaseStore = new CouchbaseVector({
  connectionString: process.env.CB_CONNECTION_STRING,
  username: process.env.CB_USERNAME,
  password: process.env.CB_PASSWORD,
  bucket: process.env.CB_BUCKET,
  scope: process.env.CB_SCOPE,
  collection: process.env.CB_COLLECTION
});

// Create vector search index
await couchbaseStore.createIndex({
  indexName: "research_embeddings", // name of Couchbase Vector Search Index
  dimension: 1536, // Embedding dimensionality 
  similarity: "cosine"
});

Note: When setting up vector search in Couchbase, developers can optimize for either recall (accuracy) or latency based on application needs. The system supports vectors with dimensions up to 4096, making it compatible with most modern embedding models.

Implementing a Multi-Agent Research-Writer Workflow using Mastra AI and Couchbase

The foundation of this example is a multi-agent architecture in which the user initially provides a search query. Based on this, the Researcher Agent performs RAG, leveraging Couchbase vector search to retrieve relevant documents. Then, the Writer Agent transforms the research output into polished content.

You can check out the Github Repo for this project here

Creating a Research Agent

The research agent takes an input query from the user and retrieves relevant information using RAG:

const researchAgent = new Agent({
  name: 'Research Agent',
  instructions: `You are a research assistant that analyzes academic papers.
    Find relevant information using vector search and provide accurate answers.`,
  model: openai('gpt-4o-mini'),
  tools: {
    vectorQueryTool: createVectorQueryTool({
      vectorStoreName: 'couchbaseStore',
      indexName: 'research_embeddings',
      model: openai.embedding('text-embedding-3-small'),
    }),
  },
});

This agent uses OpenAI's GPT-4o-mini model and is equipped with a vector query tool that allows it to search through embedded documents stored in Couchbase.

Creating a Writer Agent

The writer agent takes the research output and transforms it into polished content

import { Agent } from "@mastra/core/agent";
import { openai } from "@ai-sdk/openai";

export const writerAgent = new Agent({
  name: "Writer Assistant",
  instructions: `You are a professional blog writer that creates engaging content. 
    Your task is to write a well-structured blog post based on the research provided.
    Focus on creating high-quality, informative, and engaging content.
    Make sure to maintain a clear narrative flow and use the research effectively.
    Focus on the specific content available in the tool and acknowledge if you cannot find sufficient information to answer a question.
    Base your responses only on the content provided, not on general knowledge.`,
  model: openai("gpt-4o-mini"),
});

Creating a Writer Workflow using Mastra Workflows

As mentioned previously, Mastra’s workflow system provides a standardized way to define steps and link them together. In this example, we create a workflow for the Researcher and Writer Agents to connect these agents in a sequential process.

import { Step, Workflow } from "@mastra/core/workflows";
import { z } from "zod";
import { researchAgent } from "../agents/researchAgent";
import { writerAgent } from "../agents/writerAgent";

// Define the research step
const researchStep = new Step({
  id: "researchStep",
  execute: async ({ context }) => {
    if (!context?.triggerData?.query) {
      throw new Error("Query not found in trigger data");
    }
    const result = await researchAgent.generate(
      `Research information for a blog post about: ${context.triggerData.query}`
    );
    console.log("Research result:", result.text);
    return {
      research: result.text,
    };
  },
});

// Define the writing step
const writingStep = new Step({
  id: "writingStep",
  execute: async ({ context }) => {
    const research = context?.getStepResult<{ research: string }>("researchStep")?.research;
    if (!research) {
      throw new Error("Research not found from previous step");
    }

    const result = await writerAgent.generate(
      `Write a blog post using this research: ${research}. Focus on the specific content available in the tool and acknowledge if you cannot find sufficient information to answer a question.
    Base your responses only on the content provided, not on general knowledge.`
    );
    console.log("Writing result:", result.text);
    return {
      blogPost: result.text,
      research: research,
    };
  },
});

// Create and configure the workflow
export const blogWorkflow = new Workflow({
  name: "blog-workflow",
  triggerSchema: z.object({
    query: z.string().describe("The topic to research and write about"),
  }),
});

// Run steps sequentially
blogWorkflow.step(researchStep).then(writingStep).commit();

This code defines the workflow with two steps: first research, then writing. Data flows between the steps, with the research output feeding directly into the writing process.

Conclusion

The Couchbase Vector Store integration with Mastra AI enables you to build scalable and production-ready AI agents, thanks to Mastra's agent orchestration capabilities and Couchbase's vector search.

As AI agent adoption continues to evolve, we can expect even more powerful AI systems that combine the strengths of multiple specialized agents and knowledge retrieval mechanisms.

Elasticsearch to Meilisearch migration guide

Shivay Lamba — Fri, 07 Apr 2023 10:06:14 +0000

Elasticsearch migration guide

Contents:

Introduction
Differences
Migration script
Front-end components
Conclusion

If you are currently using Elasticsearch and plan to migrate to Meilisearch for your application, follow this guide to help you with the transition.

Differences

Before migrating, you may want to understand better what differentiates Elasticsearch from Meilisearch.

Elasticsearch is a distributed search engine that uses clusters and nodes to optimize performance, whereas Meilisearch is a single instance/node with customizable startup options. Meilisearch is still evolving, and many functionalities are not yet supported. You can think of Meilsearch as similar to the Elasticsearch component in the ELK Stack, but without the rest of the components like Kibana, Logstash and Beats.

You may see what new upgrades our developers are working on by visiting the public roadmap.

Migration Script

This guide will show you how to migrate data from Elasticsearch to Meilisearch using NodeJs and it has no impact on the programming language that will be used with Meilisearch in the future.

Initialize project

Start by creating a directory elastic-meilisearch-migration and initialize it as an npm project:

mkdir elastic-meilisearch-migration
cd elastic-meilisearch-migration
npm init -y

Next, create a script.js file:

touch script.js

This file will contain our migration code.

Install required packages

To get started, you'll need two npm packages. The first is @elastic/elasticsearch, the JavaScript client for the ElasticSearch API, and the second is meilisearch, the JavaScript client for the Meilisearch API. To install them, run the below command:

npm install --save @elastic/elasticsearch meilisearch

Create client objects

We need client instances of both Elasticsearch and Meilisearch to access their respective API. Paste the below code in script.js:

const { Client: ElasticSearch } = require('@elastic/elasticsearch')
const { MeiliSearch } = require('meilisearch')

const esClient = new ElasticSearch({
  cloud: {
    id: 'ES_CLOUD_ID',
  },
  auth: {
    username: 'ES_USER_NAME',
    password: 'ES_PASSWORD',
  },
})

const meiliClient = new MeiliSearch({
  host: 'MEILI_HOST',
  apiKey: 'MEILI_API_KEY',
})

First, we create an Elasticsearch client esClient using elastic cloud credentials. You can also try other authentication methods. Replace the original values for ES_CLOUD_ID,ES_USER_NAME and ES_PASSWORD.

Then, we create a Meilisearch client meiliClient by providing the host url and API key. Also, replace MEILI_HOST and MEILI_API_KEY with their respective values.

Fetch data from Elasticsearch

This could be a challenging step because we will iterate the index until the entire index is not searched. In each iteration, we search for the subsequent 10,000 documents, format them, and store them. The iteration will end when we get an empty result. To achieve such a paginated search result, we will use the Search After method.

This logic has been reduced to the below code.

async function getElasticSearchDocuments() {
  let isFetchingComplete = false
  let search_after = null
  let documents = []

  const searchObject = {
    index: 'ES_INDEX',
    size: 10000,
    body: {
      query: {
        match_all: {},
      },
    },
    sort: {
      'id.keyword': 'asc',
    },
  }

  do {
    if (search_after) searchObject.search_after = search_after

    const result = await esClient.search(searchObject)
    const hits = result.hits.hits

    isFetchingComplete = hits.length == 0
    search_after = hits[hits.length - 1]?.sort || null
    documents = documents.concat(hits.map(hit => hit._source))
  } while (isFetchingComplete == false)

  return documents
}

Replace ES_INDEX with the index name you want to export.

Upload data to Meilisearch

Add the following code:

  const documents = await getElasticSearchDocuments()
  const meiliIndex = meiliClient.index('MEILI_INDEX')
  await meiliIndex.addDocuments(documents)

The variable documents contain an array of documents ready to be uploaded to Meilisearch.

After that, we get the index instance and upload all the documents with the addDocuments method. Meilisearch will create the index if it doesn't already exist.

Note: The addDocuments method is asynchronous, which means the request is not handled as soon as it is received, but it is put into a queue and processed.

Replace MEILI_INDEX with the index name where you would like documents to be added.

That's all! When you're ready to run the script, enter the below command:

node script.js

Finished Script

Here's the complete script code.

const { Client: ElasticSearch } = require('@elastic/elasticsearch')
const { MeiliSearch } = require('meilisearch')

const esClient = new ElasticSearch({
  cloud: {
    id: 'ES_CLOUD_ID',
  },
  auth: {
    username: 'ES_USER_NAME',
    password: 'ES_PASSWORD',
  },
})

const meiliClient = new MeiliSearch({
  host: 'MEILI_HOST',
  apiKey: 'MEILI_API_KEY',
})

async function getElasticSearchDocuments() {
  let isFetchingComplete = false
  let search_after = null
  let documents = []

  const searchObject = {
    index: 'ES_INDEX',
    size: 10000,
    body: {
      query: {
        match_all: {},
      },
    },
    sort: {
      'id.keyword': 'asc',
    },
  }

  do {
    if (search_after) searchObject.search_after = search_after

    const result = await esClient.search(searchObject)
    const hits = result.hits.hits

    isFetchingComplete = hits.length == 0
    search_after = hits[hits.length - 1]?.sort || null
    documents = documents.concat(hits.map(hit => hit._source))
  } while (isFetchingComplete == false)

  return documents
}

;(async () => {
  const documents = await getElasticSearchDocuments()
  const meiliIndex = meiliClient.index('MEILI_INDEX')
  await meiliIndex.addDocuments(documents)
})()

Front-end components

Instant Meilisearch is a plugin connecting your Meilisearch instance with InstantSearch, giving you access to many (but not all) of the same front-end components as Algolia users. Here is an up-to-date list of components compatible with Instant Meilisearch.

Conclusion

In summary, we have discussed the primary advantages and limitations of both search engines, but our discussion has only touched the tip of the iceberg. The functionalities of Meilisearch and Elasticsearch surpass what has been covered in this article. To obtain a comprehensive comparison between Meilisearch, Elasticsearch, and other search engines, please consult the dedicated section in our documentation.

Integrate a seamless search experience in an NextJS e-commerce application with Meilisearch

Shivay Lamba — Sat, 01 Apr 2023 02:52:24 +0000

Drastically improve your users' product discovery experience with our easy-to-use and easy-to-deploy search engine.

Introduction

Searching is a crucial feature of any e-commerce application which directly affects conversions. A good search experience requires quick and accurate search results. However, it requires investing time and developer resources to build. Here's when Meilisearch enters the picture—providing an open-source search engine that is lightning fast, hyper-relevant, and typo-tolerant with little to no setup time.

In this tutorial, we'll add a seamless search experience with Meilisearch to a light e-commerce application. We will import a list of 1,000 products to Meilisearch. Users can search through these products and benefit from advanced features like filtering and sorting options.

Upon completion, you will have an app similar to our demo application at http://ecommerce.meilisearch.com, which provides rapid search results on a catalog of over 1.4 million products.

Prerequisites

NodeJs
Next.js - React Framework
Meilisearch

Getting Started

Let's get started with the installation of the necessary tools.

1. Install and launch Meilisearch

You have many ways to install Meilisearch. One of the methods is to use cURL for the installation.

You can paste the following code into your terminal:

# Install Meilisearch
curl -L https://install.meilisearch.com | sh

# Launch Meilisearch
./meilisearch

This command will launch a local Meilisearch server at http://localhost:7700/.

2. Adding data to Meilisearch

Create and navigate to a new folder called seed. You can use the following command to install Meilisearch's Javascript client using npm.

npm install meilisearch

We have gathered a list of 1,000 products from various Amazon datasets and compiled them in a data.json file. We will add these products to the Meilisearch index.

You can download this data.json file from GitHub.

Each record is associated with a product. Each product has a brand, category, tag, price, rating, and other related information. We will make these attributes sortable and filterable in our Meilisearch instance via [updateFilterableAttributes](https://docs.meilisearch.com/reference/api/filterable_attributes.html#update-filterable-attributes) and [updateSortableAttributes](https://docs.meilisearch.com/reference/api/sortable_attributes.html#update-sortable-attributes) methods.

/* Here's an example of a product record in the data.json file */

[
    {
        "id": "711decb2a3fdcbbe44755afc5af25e2f",
    "title": "Kitchenex Stainless Steel Flatware Pie Server and Pie Cutter Set of 2",
    "description": "The Kitchen Stainless Pie Server is both flashy and chic...",
        "category": "Home & Kitchen",
    "brand": "Dr. Pet",
    "price": 16.84,
        "tag": "Kitchen",
    "rating": 4.7,
    "reviews_count": 7
    },
    ...999 more items
]

Let’s create a script to add the data from the data.json file to a products index in Meilisearch. Here’s the code of the script:

const { MeiliSearch } = require("meilisearch");

const client = new MeiliSearch({
  host: "http://localhost:7700",
  apiKey: "", // No API key has been set
});

const INDEX_NAME = "products";

const index = client.index(INDEX_NAME);

const data = require("./data.json");

(async () => {
  console.log(`Adding Filterable and Sortable Attributes to "${INDEX_NAME}"`);
  await index.updateFilterableAttributes([
    "brand",
    "category",
    "tag",
    "rating",
    "reviews_count",
    "price",
  ]);
  await index.updateSortableAttributes(["reviews_count", "rating", "price"]);

  console.log(`Adding Documents to "${INDEX_NAME}"`);
  await index.updateDocuments(data);
    console.log('Documents Added');
})();

If you called your script seed.js, you could run the command below to start adding data to your Meilisearch instance:

node seed.js

Wait until the data is ingested into the Meilisearch instance. It is usually done in a few seconds. You may go to [http://localhost:7700/](http://localhost:7700/) to check the list of 1000 products in the Meilisearch.

3. Set up the project

Let's build an e-commerce application in Next.js. N*ext.js* is an open-source React framework that enables server-side rendering and static website generation.

We can set up a Next.js application using the create-next-app tool. Navigate to your project base directory in the terminal, and use the following command to install a Next.js application:

npx create-next-app@latest ecommerce

It may take a few minutes to complete. This command will create a folder named ecommerce in your project base directory with all the boilerplate code. Navigate to the ecommerce folder and install the following npm libraries:

react-instantsearch-dom - an open-source library that uses InstantSearch.js to build search interfaces in front-end applications quickly.
@meilisearch/instant-meilisearch - It's a client for InstantSearch.js. It establishes communication between Meilisearch and InstantSearch.

You can install these libraries using the following command:

npm i --save react-instantsearch-dom @meilisearch/instant-meilisearch

You may add some pre-defined stylesheet files. You can download all the CSS modules from here and paste all the files into the styles folder in the base directory.

Important Note:

As of Next.js v12 and above, react-instantsearch-dom is not working as expected when React’s Strict mode is enabled (refer to link). A quick and easy fix for this is to disable strict mode. You can disable it by adding reactStrictMode: false to next.config.js. You may find this file at the root of your project.

/* next.config.js */

module.exports = {
  reactStrictMode: false, // set this to false
  images: {
    domains: [''],
  },
}

To apply modifications, restart the Next.js server.

4. Building and integrating components

We have completed the initial step of seeding the data to the Meilisearch instance and installing the necessary tools. From here, we will start integrating the components required for creating a search experience in the application.

4.1 Adding search box and connecting components to Meilisearch

We can create a navigation bar that contains a search box to perform searches within the application. We will use the SearchBox component from the react-instantsearch-dom library to do so.

You can create a navbar.jsx file in the components/layout folder and use the following code in it:

import React from 'react';
import { SearchBox } from 'react-instantsearch-dom';
import styles from '../../styles/nav-bar.module.css';

export const NavBar = () => {
  return (
    <div className={styles.container}>
      <SearchBox />
    </div>
  );
};

export default NavBar;

We must connect the SearchBox component to Meilisearch. We will create a searchClient with the necessary credentials and pass it to the InstantSearch component as a prop along with the index name.

To do this, you can create a layout.jsx file in the components/layout/ folder and use the following code in it:

import React from 'react';
import NavBar from './navbar';
import { InstantSearch } from 'react-instantsearch-dom';
import { instantMeiliSearch } from '@meilisearch/instant-meilisearch';

const searchClient = instantMeiliSearch('http://localhost:7700', '');

const Layout = ({ children }) => {
  return (
    <InstantSearch indexName="products" searchClient={searchClient}>
      <NavBar />
      <main>{children}</main>
    </InstantSearch>
  );
};

export default Layout;

Next.js uses the App component to initialize pages. Every time the server is launched, _app.js is the primary file rendered. We will add the Layout component and a few stylesheet files to the _app.js file. Adding the Layout component will supply the search results to all the child components.

You may replace the code in the _app.js file with the following code:

import Layout from "../components/layout/layout";
import "../styles/globals.css";
import "../styles/searchBoxAIS.css";

function MyApp({ Component, pageProps }) {
  return (
    <Layout>
      <Component {...pageProps} />
    </Layout>
  );
}

export default MyApp;

4.2 Creating various search filters

Let’s add a filter functionality to the application. We will need a few components from the react-instantsearch-dom library:

The RefinementList component can be used to filter the data based on facets. The number of items related to the given filter will also be displayed.
```
<RefinementList attribute="category" />
```
The RatingMenu component creates a rating list. We need to define what’s the maximum rating. It displays a select menu (starting from 1 star till max) to select the rating. The component only works with integers.
```
 <RatingMenu attribute="rating" max={5} />
```
The ClearRefinements component will be used to provide a button that will clear all the applied filters within the application. This is handy when we've applied many filters and want to delete them all at once.
```
<ClearRefinements />
```

We will add all three components to implement the filter functionality. You can create a new file SearchFilters.jsx in the components/home/ folder and use the following code:

import {
  ClearRefinements,
  RatingMenu,
  RefinementList,
} from 'react-instantsearch-dom';

const SearchFilters = () => (
  <div>
    <h2>
      <span>Filters</span>
      <ClearRefinements />
    </h2>
    <h4>Categories</h4>
    <RefinementList attribute="category" />
    <h4>Tags</h4>
    <RefinementList attribute="tag" />
    <h4>Brands</h4>
    <RefinementList attribute="brand" />
    <h4>Rating</h4>
    <RatingMenu attribute="rating" max={5} />
  </div>
);

export default SearchFilters;

4.3 Implementing a product card component

We will create a component named Hit to represent a single product. We may design a card view for the component that will include the basic information for the product, like - title, description, rating, review count, price, brand, and image. All these details can be retrieved from the component’s product prop. After that, we can display the results by looping over the component.

We can create a file hits.jsx in the components/home/ folder. You can paste the following lines of code into the file:

import styles from "../../styles/searchResult.module.css";

const Hit = ({ product }) => {
  const { rating, images, title, description, brand, price, reviews_count } = product;

  return (
    <div className={styles.card}>
      <div
        className={styles.productResImg}
        style={{ backgroundImage: `url(${images[0]})` }}
      />
      <div className={styles.productResCntnt}>
        <h6 className={styles.productResBrand}>{brand}</h6>
        <div className={styles.productResTitl}>{title}</div>
        <div className={styles.productResDesc}>
          {description.substring(0, 50)}...
        </div>
        <div className={styles.productResPrice}>${price}</div>
        <div className={styles.productResReview}>
          {reviews_count ? (
            <div className={styles.productRateWrap}>
              <span className={styles.productRate}>
                {reviews_count} review
              </span>{" "}
              <span>⭐ {rating}</span>
            </div>
          ) : (
            "No Review"
          )}
        </div>
      </div>
    </div>
  );
};

export default Hit;

4.4 Designing a page layout to display the list of products

It’s time to design the product list page with a sort feature and pagination to display a limited number of products on a page. For this, we can use the following components from the react-instantsearch-dom library:

The Pagination component, by default, allows you to display a list of 20 products per page. We can also provide the showLast property to display an estimate of the number of pages.
```
<Pagination showLast={true} />
```
The SortBy component will sort the search results based on the facets. We need to provide a Meilisearch index and a list of value and label.

Let's say we need to sort the category in the index products alphabetically. You may use the following code:
```
<SortBy
  defaultRefinement="products"
  items={[
    { value: 'category', label: 'Sort category alphabetically' },
  ]}
/>
```
The SortBy has a few properties, including the defaultRefinement attribute for providing the Meilisearch index and the items attribute to provide a list of value and label.

The value includes the document's attribute, and as the name suggests, we will use the label to add label text in a dropdown list.
The connectStateResults hook will retrieve the search results from the Meilisearch instance using InstantSearch. The connectStateResults function has some arguments, including:
- searchState provides the information about the user's input in the provided search box.
- searchResults gives the result obtained after querying the Meilisearch instance.
- The searching argument represents the loading state for the result retrieval from the Meilisearch.

We will use the searchState argument to get the list of products and loop the list using the map function over the Hit component to display the result. We will use the SortBy component to sort based on price and reviews_count.

We can create a file SearchResult.jsx in the component/home/ folder and use the following code:

import {
  Pagination,
  SortBy,
  connectStateResults,
} from 'react-instantsearch-dom';
import SearchFilters from './SearchFilters';
import Hit from "./hits.jsx";
import styles from '../../styles/searchResult.module.css';

const Results = connectStateResults(
  ({ searchState, searchResults, searching }) => {
    const hits = searchResults?.hits;

    if (searching) {
      // This will show the loading state till the results are retrieved
            return 'Loading';
    }

    return (
      <>
        <SearchFilters />
        <div className={styles.products}>
                    {/* Condition for rendering component based on results */}
          {searchResults?.nbHits !== 0 ? (
            <>
              <div className={styles.resultPara}>
                <span>
                  Showing {searchResults?.hits.length || 0} of{' '}
                  {searchResults?.nbHits || 0}{' '}
                  {searchState.query &&
                    !searching &&
                    `for "${searchState.query}"`}
                </span>
                <div>
                  <SortBy
                    defaultRefinement="products"
                    items={[
                      { value: 'products', label: 'Sort' },
                      {
                        value: 'products:price:desc',
                        label: 'Price: High to Low',
                      },
                      {
                        value: 'products:price:asc',
                        label: 'Price: Low to High',
                      },
                      {
                        value: 'products:reviews_count:desc',
                        label: 'Most Reviews',
                      },
                    ]}
                  />
                </div>
              </div>
              <div className={styles.grid}>
                                {/* Using search result list, we will loop over the Hit component */}
                {hits?.length > 0 &&
                  hits.map((product) => (
                    <Hit key={product.id} product={product} />
                  ))}
              </div>
            </>
          ) : (
            <p className={styles.paragraph}>
              No results have been found for {searchState.query}.
            </p>
          )}
                    {/* Adding pagination over the results */}
          <Pagination showLast={true} />
        </div>
      </>
    );
  }
);
export default Results;

4.5 Displaying results on the application

We have created all the required components to display the results. We need to add the Results component to the index.jsx file to display the result on the screen. You can copy and paste the following code into the index.jsx file.

import styles from '../styles/home.module.css'
import Results from '../components/home/SearchResult'

export default function Home () {
  return (
    <div className={styles.container}>
      <main className={styles.main}>
        <div className={styles.mainContent}>
          <Results />
        </div>
      </main>
    </div>
  )
}

export const getStaticProps = async () => {
  return {
    props: {}
  }
}

You can use the following command to run the application:

npm run dev

Go to http://localhost:3000. The output will resemble the image provided below:

You can find the complete code here, https://github.com/shivaylamba/demos/tree/main/src/ecommerce.

Conclusion

We created a lightning-fast search experience for an e-commerce application. You can now take the learnings from above and integrate a similar search experience into your applications. You may play with typo-tolerance, geo-search filters, and many other features to better suit your needs.

Here are some references of real-world examples of Meilisearch used in e-commerce experiences:

We're excited to see what you come up with. Share your experience and Meilisearch integration in your e-commerce application on the Slack community.

If you have any queries or suggestions, please let us know on Slack. For more information on Meilisearch, check out our Github repository and official documentation.”

Add search in your Gatsby project using Meilisearch

Shivay Lamba — Tue, 24 May 2022 09:06:37 +0000

This guide will go through all the steps for adding the content of your Gatsby app to Meilisearch. ( https://github.com/shivaylamba/meilisearch-gatsby-plugin-guide.git)
We will use the content of NikitaJS Documentation, an open-source documentation site built with Gatsby, for this guide. We will then make this content searchable using Meilisearch.
Nikita is a toolkit that gathers a set of functions commonly used during system deployment. It is built for Node.js. We chose this project as it doesn’t have search functionality for its documentation.

Introducing our Tools

Meilisearch

Meilisearch is an open-source search engine that works out-of-the-box.

It provides a customizable searching and indexing solution along with features like typo tolerance, filters, and synonyms.

Requirements

To be able to follow this tutorial, you'll need the following:

An open terminal or command prompt
Node.js >= 14.15.X and <= 16.X: this makes it possible to run JS outside a browser
- You can check your active version with the command node --version
- If your version of Node is outside this range, we recommend that you install nvm and use it to access Node 14
NPM and NPX >= 6.x (installed with Node.js): package managers that help you access and use JS libraries

Steps

Start MeiliSearch
Setup the Gatsby project
Add the content of the Gatsby app to Meilisearch
Build the frontend
Conclusion

Start MeiliSearch

There are multiple ways to download and run a MeiliSearch instance.

For example, you can use Docker to install and run it locally:

docker pull getmeili/meilisearch:latest 

docker run -it --rm -p 7700:7700 getmeili/meilisearch:latest ./meilisearch --master-key=masterKey

The Meilisearch instance will run on the following host:http://localhost:7700.

Setup the Gatsby project

Let’s open a terminal and clone the NikitaJs project that we will be using for this guide:

git clone https://github.com/adaltas/node-nikita.git

You can find the content of the Gatsby app in markdown files in the docs/content folder. This content is used by Gatsby to create the application.

Adding the Meilisearch plugin

Let’s start by installing the meilisearch plugin:

cd node-nikita/docs/website
npm install gatsby-plugin-meilisearch

Let’s also install all the dependencies:

npm install

To see how the website is rendered, run it using npm run serve.

Adding the content of the Gatsby app to Meilisearch

Now that you have installed the plugin and have both the web app and the Meilisearch instance running, let's configure the plugin to make the content searchable.

The main code for the docs website lies in the directory docs/website.

All the plugin configurations can be found in the gatsby-config.js file in the documentation website source directory.

In this example, all the markdown files will be retrieved from the documentation and added to the Meilisearch instance. This will be handled by the gatsby-plugin-mdx module.

Configuring the plugin

The first step is to add your Meilisearch credentials to the Meilisearch Gatsby plugin:

{
    resolve: 'gatsby-plugin-meilisearch,
    options: {
      host: 'http://localhost:7700', // your host URL goes here
      apiKey: 'masterKey',   // your API key goes here       
      indexes: [],
    },
  },

The next step is to add the content to the indexes field.

This field can be considered the heart of the plugin. This is where you store the data that needs to be added to Meilisearch.

The indexes field is an array that can be composed of multiple index objects. Each index object contains the following information:

indexUid This field contains the name of the index in Meilisearch. For this example, the index nikita-api-docs will be created.

indexUid: 'nikita-api-docs'

query This is the graphQL query that will be executed to retrieve the data, i.e. the content of the pages. The query can be very specific depending on the plugins used. Gatsby comes with inbuilt support for GraphQL and you can use the GraphQL tool (http://localhost:8000/___graphql) provided by Gatsby in development mode to help you build it.

You can now see the graphQL query using the gatsby-plugin-mdx plugin. gatsby-plugin-mdx will fetch all the markdown files in the documentation given through the gatsby-source-filesystem plugin.

This will include the title, navtitle, and description of the markdown files from the frontmatter.

The data is transformed into a JavaScript object:

query: `query MyQuery {
              allMdx {
                edges {
                  node {
                    frontmatter {
                      title
                      navtitle
                      description
                    }
                    slug
                    rawBody
                    id
                  }
                }
              }
            }`,

iii. transformer

It’s a function that transforms the fetched data (from GraphQL query execution) before sending it to Meilisearch.

Let's suppose, the data returned from the query is:

 data = {
  allMdx: {
    edges: [
      {
        node: {
          frontmatter: {
            title: "Introduction",
            navtitle: "intro",
          },
          body: "Introduction to the Nikita.js",
          slug: "/introduction",
          id: "1",
        },
      },
      {
        node: {
          frontmatter: {
            title: "Architecture",
            navtitle: "architecture",
          },
          body: "Architechture of Nikita.js",
          slug: "/architecture",
          id: "2",
        },
      },
    ],
  },
};

We need to change the key names, and create a simple object, therefore, we can use the map function,

transformer: (data) => {
        data.allMdx.edges.map(({ node }) => {
          // Node property has been destructured here
          return {
            id: node.id,
            lvl0: node.frontmatter.title,
            lvl1: node.frontmatter.navtitle,
            content: node.body,
            anchor: node.slug,
          };
        });
}

/*
  It will return a list of transformed structured object

    [
    {
      id: "1",
      lvl0: "Introduction",
      lvl1: "introduction",
      content: "Introduction to the Nikita.js",
      anchor: "/introduction"
    },
    {
      id: "2",
      lvl0: "Architecture",
      lvl1: "architecture",
      content: "Architechture of Nikita.js",
      anchor: "/architecture"
    }
  ]
*/

In this, data will be passed to a customized function. A map function restructures the whole object into a simple array that can be indexed to Meilisearch.

An id field is required for indexing the data in Meilisearch.

After filling in these fields, the Meilisearch configuration should look like this:


   {
    resolve: 'gatsby-plugin-meilisearch',
    options: {
      host: 'http://localhost:7700',
      apiKey: 'masterKey',
      batchSize: 1,
      indexes: [
        {
          indexUid: 'nikita-api-docs',
          settings: {
              searchableAttributes: ['lvl0', 'lvl1', 'lvl2', 'content'],
            },
          transformer: (data) =>
              data.allMdx.edges
                .map(({ node }) => {
                  // Have to update for versioning
                  const currentVersion =
                    node.slug.substring(0, 8).search('project') === -1
                      ? '/current'
                      : ''

                  return {
                    id: node.id,
                    lvl0:
                      node.frontmatter.navtitle || node.frontmatter.title || '',
                    lvl1:
                      node.frontmatter.title || node.frontmatter.navtitle || '',
                    lvl2: node.frontmatter.description || '',
                    content: node.rawBody,
                    url: `${currentVersion}/${node.slug}`,
                  }
                }),
            query: `query MyQuery {
              allMdx {
                edges {
                  node {
                    frontmatter {
                      title
                      navtitle
                      description
                    }
                    slug
                    rawBody
                    id
                  }
                }
              }
            }`,
          },
        ],
      },
    },

Build the project

The gatsby-plugin-meilisearch will fetch and send data for indexation to Meilisearch during the build process

To start the build process, run the following command:

npm run build

After the build, there should be a message in the terminal that your content was successfully indexed:

success gatsby-plugin-meilisearch - x.xxxs - Documents added to Meilisearch

You can validate this by going to http://localhost:7700, entering the API key, and checking that your app content has been added to Meilisearch.

Build the frontend ( UI )

Now that the data is indexed, let’s proceed to build the user interface for creating the search experience.

For this example, we will use the Meilisearch docs-searchbar.js. It is a front-end SDK for Meilisearch that provides an easy integration of a search bar into the documentation site. The content indexed earlier in the Meilisearch instance will be referenced.

Let’s start by installing the docs-searchbar.js SDK in the frontend directory of the project.

# With NPM
npm install docs-searchbar.js

Search Bar

The first step is to import the docs-searchbar module into the AppBar.js code. The file can be found in website/src/components/shared.

import 'docs-searchbar.js/dist/cdn/docs-searchbar.css'

Next add a useEffect Hook to add the docsSearchBar function to the AppBar.js code.

useEffect(() => {
    if(window !== undefined){
      const docsSearchBar = require('docs-searchbar.js').default

      docsSearchBar({
        hostUrl: 'http://localhost:7700',
        apiKey: 'masterKey',
        indexUid: 'nikita-api-docs',
        inputSelector: '#search-bar-input',
        meilisearchOptions: {
          limit: 5,
        },
        debug: true,
        enhancedSearchInput: true,
      })
    }
  }, [])

The docsSearchBar function comes in with a number of different parameters.

The hostUrl and the apiKey serve as the credentials of your Meilisearch instance.

indexUid is the index identifier in your Meilisearch instance where your documentation/website content is stored.

inputSelector is the id attribute of the HTML search input tag. In the case of the docsSearchBar, it will match the id of the input.

enhancedSearhInput: When set to true, a theme is applied to the search box to improve its appearance. It adds the .searchbox class which can be used to further customize the search box.

Next, add an input tag of type search with an id:

<input type="search" id="search-bar-input" />

It’s done!

Testing the Implementation

Run the command npm run develop to initiate the site and run it on localhost:8000. A search input should appear like this:

Conclusion

We hope this article was a pleasant introduction to the new Meilisearch plugin for Gatsby.

If you have any questions, please join us on Slack. For more information, see our:

Messing with Service Meshes using Meshery

Shivay Lamba — Wed, 20 May 2020 08:39:00 +0000

What is Meshery?

Meshery is the Service Mesh Management Tool
Meshery enables operators, developers, and service owners to realize the full potential of a service mesh...

But wait! What is a service mesh exactly?

Service meshes in the Cloud Native Space are tools for adding observability, reliability, security, and features to applications by inserting them at the platform layer rather than the application layer.

In a control plane service meshes provide the following:
Provides policy, configuration, and platform integration.
Takes a set of isolated stateless sidecar proxies and turns them into a service mesh.
Does not touch any packets/requests in the data path.

While in the data plane, service meshes provide the following as well :
Provides policy, configuration, and platform integration.
Takes a set of isolated stateless sidecar proxies and turns them into a service mesh.
Does not touch any packets/requests in the data path.

How does Meshery come into the picture?

Meshery provides federation, backend system integration, expanded policy and governance, continuous delivery integration, workflow, chaos engineering, and application performance tuning.

Benefits of using Meshery for service meshes :

Configuration Best Practices Assess your service mesh configuration against deployment and operational best practices with Meshery's configuration analyzer.

Service Mesh Interface (SMI) Conformance Operate and upgrade with confirmation of SMI compatibility. Defines compliant behavior. Produces compatibility matrix. Ensures provenance of results. Runs a set of conformance tests. Built into participating service mesh’s release pipeline.

The service mesh management plane Supports the following : 1.Lifecycle 2.Workload 3.Performance 4.Configuration

Performance Management Most importantly, you can do performance comparison between different service meshes by doing load tests.

type PerformanceProfile struct {
    ID *uuid.UUID `json:"id,omitempty"`

    Name              string         `json:"name,omitempty"`
    LastRun           string         `json:"last_run,omitempty"`
    Schedule          *uuid.UUID     `json:"schedule,omitempty"`
    LoadGenerators    pq.StringArray `json:"load_generators,omitempty" gorm:"type:text[]"`
    Endpoints         pq.StringArray `json:"endpoints,omitempty" gorm:"type:text[]"`
    ServiceMesh       string         `json:"service_mesh,omitempty"`
    ConcurrentRequest int            `json:"concurrent_request,omitempty"`
    QPS               int            `json:"qps,omitempty"`
    Duration          string         `json:"duration,omitempty"`
    TotalResults      int            `json:"total_results,omitempty"`

    RequestHeaders string `json:"request_headers,omitempty"`
    RequestCookies string `json:"request_cookies,omitempty"`
    RequestBody    string `json:"request_body,omitempty"`
    ContentType    string `json:"content_type,omitempty"`

    UpdatedAt *time.Time `json:"updated_at,omitempty"`
    CreatedAt *time.Time `json:"created_at,omitempty"`
}

The above code shows the performance criteria for different service meshes.

The Meshery Architecture!

For Providers :
For Clients :

Forem: Shivay Lamba

The LiteLLM Supply Chain Attack: A Wake-Up Call for AI Infrastructure

Incident Overview: Scope, Timeline, and Entry Point

How the Attack Moved Through Trusted Systems

Understanding the True Impact of the Breach

What This Reveals About Modern AI Systems

The Risk Built into Modern AI Architectures

Building Low-Exposure AI Infrastructure with Bifrost

Comparative Overview: LiteLLM vs. Bifrost

Closing Thoughts

How I built a Content Curator CLI using Github Copilot CLI SDK

What I Built

Building Content Curator: CLI + Copilot SDK

How Content Curator Uses GitHub Copilot SDK & Exa AI

1. Initializing the Copilot Client

2. Session Management

3. Prompt Workflow

Why Choose Copilot SDK Over Generic LLM Clients?

Conclusion

Demo

My Experience with GitHub Copilot CLI

How I Used GitLab Duo Agent Platorm to Build a Conference Demo in under an hour

Setting the Scene - What we wanted to show in our talk

GitLab Duo Agent Platform saves the day

Demo

Final Thoughts

How I Built an Agentic RAG Application to Brainstorm Conference Talk Ideas

TL;DR

Important Note 🚨

Tech Stack

Complete Pipeline Flow / Architecture Deep Dive

Step 1: URL Extraction / Data Collection (extract_events.py)

Step 2: Talk Data Crawling / Data Ingestion (couchbase_utils.py)

Step 3: Embedding Generation (embeddinggeneration.py)

Step 4: Agent + RAG Application (talk_suggestions_app.py)

Research Agent Execution

Parallel Execution for Web Research

Sequential Reasoning for Synthesis and Insight

The Orchestration Layer

Retrieval Agent Execution

What happens here?

Synthesis Phase

How it works?

Final thoughts

Using Nebius AI Models with LangChain/Langgraph via LiteLLM

LiteLLM Nebius AI provider

Using LiteLLM with LangChain

Creating an ReAct Agent with Langgraph

Conclusion

Building a Multi-Agent RAG System with Couchbase, CrewAI, and Nebius AI Studio

What is CrewAI?

Building a Multi-Agent RAG System with Couchbase and CrewAI

Setting Up LLM Components

Extending the base OpenAI LLM

Creating the NebiusEmbeddings Class

Setting Up the Couchbase Vector Store

Creating a Vector Search Tool with CrewAI

Defining the Agents

Defining Tasks

Running the Crew!

Final Thoughts

Building Multi-Agent Workflows using Mastra AI and Couchbase

What are Mastra Workflows

Couchbase Vector Store for Mastra

Implementing a Multi-Agent Research-Writer Workflow using Mastra AI and Couchbase

Creating a Research Agent

Creating a Writer Agent

Creating a Writer Workflow using Mastra Workflows

Conclusion

Elasticsearch to Meilisearch migration guide

Elasticsearch migration guide

Differences

Migration Script

Initialize project

Install required packages

*Create client objects*

*Fetch data from Elasticsearch*

Upload data to Meilisearch

Finished Script

Front-end components

Step 1: URL Extraction / Data Collection (`extract_events.py`)

Step 2: Talk Data Crawling / Data Ingestion (`couchbase_utils.py`)

Step 3: Embedding Generation (`embeddinggeneration.py`)

Step 4: Agent + RAG Application (`talk_suggestions_app.py`)

Create client objects

Fetch data from Elasticsearch

Prerequisites

1. Install and launch Meilisearch