DEV Community: Opemipo Disu

AI Agents Calling Your Existing Backend Without MCP Development

Opemipo Disu — Thu, 24 Sep 2026 09:06:11 +0000

AI agents are becoming more useful than ever; they’re now doing more than just generating text. They can now retrieve information from different sources, call tools, and act on a user's prompt. But the problem is that most AI applications are missing one thing: a way to reach systems where the real business logic lives.

The Model Context Protocol (MCP) solves part of this problem. It gives AI applications a standard way to discover and call external tools. The catch is that building a dedicated MCP server for your existing backend adds another piece of software you now have to maintain.

In this tutorial, you'll learn what Graftcode is, how it connects to MCP, and how to expose an existing backend to an AI agent without writing a custom MCP server.

Why AI Agents Need Backend Access

Most agents start by connecting a language model to a user interface. Models can generate text, answer questions, summarize content, and perform reasoning tasks. However, the challenge arises when the AI needs context that isn’t present in the prompt.

For example:

Customer account details
Subscription information
Internal documentation
Knowledge bases

Information like this does not exist inside the model itself. The model needs a way to retrieve it from external systems, and that’s where protocols like MCP come into the picture.

Traditionally, giving AI agents access to backend functionality means introducing another layer to maintain. You build the backend, expose it through an MCP server, define tools, connect handlers, and keep everything in sync whenever the backend changes.

Graftcode starts from a different place; Instead of creating a separate MCP representation of your application, Gateway discovers the public methods you've already exposed and makes them available through MCP.

The backend stays as the source of truth, while AI agents become another consumer of those capabilities.

What is Graftcode?

Graftcode is a tool that makes public backend methods callable across languages, processes, and machines without the need to write API or MCP layer. You write normal business code. Graftcode Gateway loads that code, finds its public methods, and makes them available to consumers, including AI agents over MCP.

It was built around a simple idea: business logic should be written once and reused by different consumers. Instead of exposing backend functionality through manually maintained integration layers, Graftcode treats public methods as the gateway to work with your backend.

For example, a backend service may already have all the business logic an application needs. Customer management systems contain methods for retrieving account information. Payment/checkout systems have methods for calculating invoices. Support platforms contain methods for searching documentation and knowledge bases.

But we can have those applications use generated Grafts or AI agents via MCP rather than the traditional approach that requires creating additional integration layers such as REST APIs, RPC services, or other custom integrations.

There are two sides to this model:

Receiver: the module that contains your public methods.
Caller: the application or AI agent that consumes those methods.

The Caller talks to the Receiver through a generated package called a Graft, or through MCP if the Caller is an AI client.

Graftcode Vs. Custom MCP Server

Feature	Custom MCP Server	Graftcode Gateway
Tool definitions	Written and maintained as an additional layer	Discovered automatically from your code
Keeping tools in sync with the backend	Manual, on every change	Automatic
Extra integration layer	Yes	No
Who owns the source of truth	The MCP server's tool schema	The backend method itself

Use Cases for Graftcode and MCP

Customer support agents that need account, subscription, or order details.
Internal assistants that need to search a knowledge base.
Sales agents that want to verify subscription or billing status before replying to customers.
Operations agents that need to call existing internal systems.

How Does Graftcode Work?

When you host a module through Graftcode Gateway, it reads your backend, loads the modules, discovers their public methods, and exposes the package. Those methods become callable in two ways at once: via a generated Graft for regular applications and through MCP for AI agents.

There's no separate MCP implementation sitting between the Gateway and your backend. The public methods are the capabilities.

Benefits of Using Graftcode

Less integration code: You skip writing tool schemas and handlers manually
One backend, two consumers: The same methods serve regular applications through a Graft and AI agents through MCP
The backend stays the source of truth: Update the method once, and both consumers see the change
Deliberate exposure: You choose which classes and methods are callable, so you're not handing an agent more information than it needs

Graftcode Gateway and the MCP Endpoint

When Gateway hosts a module, it opens two ports:

Port 80 for regular service calls (Grafts).
Port 81 for Graftcode Vision and the MCP endpoint at /mcp.

No OpenAPI spec, no manually defined MCP tool, and no custom server. Gateway does the discovery for you.

Filtering What Gets Exposed

You don't have to expose every method in a module. Gateway supports filtering with flags like --types and --methods:

gg ./service \
  --types SupportService \
  --methods getCustomerProfile,getSubscriptionDetails,searchKnowledgeBase

This matters more with AI agents than almost anywhere else. Giving an agent access to a method means giving it a capability, so keep the exposed surface small and intentional.

For MCP clients that send a bare method name, Gateway can resolve the right class with --mcpBaseClass. Browser-based or edge MCP clients may also need CORS headers set through a cors.config file passed with --corsConfig.

How to Implement MCP with Graftcode

Step 1: Create and initialize the Backend Service

mkdir customer-support-ai
cd customer-support-ai
npm init -y

Create an index.js file:

class SupportService {
  static getCustomerProfile(customerId) {
    const customers = {
      "customer-1001": {
        id: "customer-1001",
        name: "Sarah Johnson",
        email: "sarah@example.com",
        plan: "Professional",
        status: "active"
      },
      "customer-1002": {
        id: "customer-1002",
        name: "James Wilson",
        email: "james@example.com",
        plan: "Starter",
        status: "active"
      }
    };

    return customers[customerId] ?? {
      error: "Customer not found"
    };
  }

  static getSubscriptionDetails(customerId) {
    const subscriptions = {
      "customer-1001": {
        customerId,
        plan: "Professional",
        billingCycle: "monthly",
        renewalDate: "2026-10-01",
        status: "active"
      },
      "customer-1002": {
        customerId,
        plan: "Starter",
        billingCycle: "monthly",
        renewalDate: "2026-09-20",
        status: "active"
      }
    };

    return subscriptions[customerId] ?? {
      error: "Subscription not found"
    };
  }

  static searchKnowledgeBase(query) {
    const articles = [
      {
        title: "How subscription renewals work",
        content: "Subscriptions automatically renew at the end of each billing period."
      },
      {
        title: "Changing your subscription",
        content: "Customers can change their subscription plan from the billing settings."
      },
      {
        title: "Cancelling a subscription",
        content: "Customers can cancel their subscription before the next renewal date."
      }
    ];

    const searchTerm = query.toLowerCase();

    return articles.filter((article) =>
      `${article.title} ${article.content}`
        .toLowerCase()
        .includes(searchTerm)
    );
  }
}

module.exports = { SupportService };

This code has nothing MCP-specific in it. No decorators, no tool schemas, no handlers. That's the point. The backend doesn't need to know that an AI agent will use it later.

Step 2: Install and Run Graftcode Gateway

Now that we have our backend service, we need a way to expose its public methods so they can be consumed by applications and AI agents.

The easiest way to get started is by installing Graftcode Gateway using the official one-line installer.

Windows

iwr https://grft.dev/get|iex

Linux / macOS

curl -fsSL https://grft.dev/get |sh

Once installed, you can verify the Gateway is available:

gg --help

Graftcode Gateway is responsible for loading your module, discovering its public methods, exposing them through Graftcode, and automatically making them available through MCP.

After installation, you can host your service by pointing Gateway at your project:

gg ./package.json

After installation, we need to host the module through Graftcode Gateway.

Graftcode Gateway is the runtime host that loads the module, discovers its public callable surface, and exposes it to consumers.

In this tutorial, we'll use Docker to work with Graftcode Gateway. Firstly, let’s create a Dockerfile:

FROM node:24

ARG TARGETARCH

WORKDIR /usr/app

COPY . /usr/app/

RUN apt-get update \
 && apt-get install -y wget \
 && wget -O /usr/app/gg.deb "https://github.com/grft-dev/graftcode-gateway/releases/latest/download/gg_linux_${TARGETARCH}.deb" \
 && dpkg -i /usr/app/gg.deb \
 && rm /usr/app/gg.deb \
 && apt-get clean \
 && rm -rf /var/lib/apt/lists/*

EXPOSE 80
EXPOSE 81

CMD ["gg", "./package.json"]

Build and run it:

docker build --no-cache --pull -t customer-support-ai:test .

docker run -d \
  -p 80:80 \
  -p 81:81 \
  --name graftcode_support_demo \
  customer-support-ai:test

At this point, the MCP endpoint is already live. You haven't written an MCP server, defined a tool, or written an OpenAPI spec.

Step 3: Inspect the Service with Graftcode Vision

Open:

http://localhost:81/GV

You should see the methods Gateway found; SupportService, getCustomerProfile, getSubscriptionDetails, and searchKnowledgeBase.

Vision also lets you try each method directly, so you can confirm what's exposed before connecting an AI agent.

Graftcode Vision is useful because it allows developers to inspect what the Gateway has actually discovered. It also lets you try each method directly, so you can confirm what's exposed before connecting an AI agent.

Before integrating a frontend application or AI client, you can verify:

Which classes are exposed
Which methods are callable
Which parameters they accept
What values they return

This creates a feedback loop that is much easier than repeatedly modifying prompts or MCP configurations while debugging.

Step 4: Connect an AI Client

Cursor. Add this to .cursor/mcp.json:

{
  "mcpServers": {
    "customer-support": {
      "url": "http://localhost:81/mcp"
    }
  }
}

Claude Desktop. Claude Desktop only supports stdio, and Gateway exposes MCP over HTTP, so bridge the two with mcp-remote:

{
  "mcpServers": {
    "customer-support": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "http://localhost:81/mcp"
      ]
    }
  }
}

Restart the client after saving the config.

Step 5: Test and Query the Agent

Ask your AI client: “What subscription does customer-1001 have?”

The agent should call getSubscriptionDetails("customer-1001") and return the real result from your backend:

{
  "customerId": "customer-1001",
  "plan": "Professional",
  "billingCycle": "monthly",
  "renewalDate": "2026-10-01",
  "status": "active"
}

Now try asking a question that needs more than one method; for example, “What plan is customer-1001 using, when does it renew, and how do renewals work?

To answer that, the agent needs to call getSubscriptionDetails() and searchKnowledgeBase(), then combine the results. If it does, your setup is working.

Best Practices and Tips for Graftcode and MCP

Keep the exposed surface small. Use --types and --methods to expose only what the agent actually needs.
Don't skip authorization. Graftcode removes integration plumbing, not the need for access control. Decide carefully which methods, like account deletion, should never be exposed to an agent.
Use a Project Key outside local development. It gives you a stable MCP URL, a stable registry URL, portal visibility, and access control.
Let the backend stay the source of truth. Update the method, not a separate tool definition or prompt.

Best Use Cases for Graftcode

Customer support tools that need real account and subscription data
Assistants built around an existing knowledge base or documentation system
Operational tooling that calls existing internal services instead of duplicating their logic
AI features added to an existing SaaS app without rewriting the backend that already powers it

Conclusion

MCP gives AI agents a standard way to call external tools, but building a custom MCP server for every backend adds a second integration layer to maintain. Graftcode starts from the backend instead. Write the capability once, host it through Gateway, and let both regular applications and AI agents call the same methods.

The interesting part of MCP is not the protocol itself; it’s rather what it enables. Agents become more useful when they can work with systems instead of relying so much on prompts and fine-tuned data.

Instead of building a custom MCP and connecting it to existing agents, developers can now expose existing business logic with Graftcode Gateway. Those capabilities become available to both traditional applications and AI agents while keeping your backend/logic as the source of truth.

For teams already maintaining customer services, internal tools, knowledge bases, billing systems, or operational platforms, this can reduce the amount of integration work required when introducing AI capabilities into an existing application stack.

If you already have backend functionality an AI agent could use, try exposing one of your own services through Graftcode's MCP quick start.

Top 5 AI Governance Tools for Enterprises (2026)

Opemipo Disu — Mon, 14 Sep 2026 13:29:28 +0000

AI governance has already become one of the most important parts of running AI in production. As enterprises deploy AI agents, retrieval systems, and LLM applications, they need ways to control access, manage risk, monitor behavior, apply policies, and prove compliance.

The best AI governance tools help organizations answer a simple question: “Can we scale AI across the company properly?”

If you're evaluating the best AI governance tools in 2026, these are the platforms that are worth looking at:

Tool	Best For	Pricing
Bifrost	Enterprise teams building AI applications that need governance at scale	Free OSS + Custom Enterprise
Credo AI	AI compliance and risk programs	Custom
Fiddler AI	AI observability and model monitoring	Free tier + Usage-based + Enterprise
OneTrust	Enterprise AI risk and compliance management	Custom
Speakeasy	AI access governance and permissions management	Custom

Each of these platforms approaches AI governance from a different angle; each also has its own strengths. Some focus primarily on compliance and risk management, while others focus on observability, access control, or the infrastructure layer that processes AI requests.

Of all the platforms in this guide, Bifrost has a different approach to AI governance. It goes beyond governance workflows and compliance documentation; it works as an AI gateway that sits between applications and AI providers, allowing organizations to enforce policies, access controls, routing rules, and observability directly in the request path.

Bifrost is also open source, allowing teams to inspect the implementation and contribute through the GitHub repository.

How We Compared These Tools

We looked at each tool from the perspective of an enterprise team that needs to control how AI is used:

Governance coverage: does it provide controls for AI inventory, policies, risk management, approvals, and ongoing governance rather than focusing on only one part of the AI stack?
Access and policy enforcement: can teams control which users, teams, applications, and models, and enforce those policies at runtime?
Security and compliance: does it help organizations manage sensitive data, audit activity, maintain evidence, and align AI usage with frameworks?
Observability and Auditing: can 88 see AI requests, model usage, costs, prompts, outputs, tool calls, and policy decisions, with enough logs to investigate what happened?
Deployment and data control: can the tools fit into an enterprise environment, and what data needs to leave the organization's environment?
Pricing posture: is pricing based on seats, AI inventory, usage, traces, or a custom enterprise agreement, and how predictable is that model as adoption grows?
Operational burden: how much work is required to deploy, integrate, configure, and maintain the platform across an organization's existing AI stack?

What Are AI Governance Tools?

AI governance tools are platforms that help organizations manage the operational, security, compliance, and risk aspects of AI systems. They provide help managing AI models, applications, users, data, and vendors while giving security and compliance teams visibility into how AI is being used.

Now, let’s have a look at the best AI governance tools, their features, pricing, and the teams they’re best fit for.

1. Bifrost

Open-source AI gateway and enterprise control plane for LLMs, agents, and MCP tools

Pricing: Bifrost has a free open-source edition for self-managed deployments. Enterprise pricing is custom, with a 14-day Enterprise trial.

Deployment: Self-hosted through Docker, Kubernetes, or a Go binary, with Enterprise deployment options including VPC, on-premises, and air-gapped environments.

Bifrost provides a central gateway between applications and AI providers, where access, routing, budgets, and governance policies can be applied.

Bifrost was developed by Maxim AI and takes an infra-level approach to AI governance. Instead of operating only as a risk or compliance system alongside the AI stack, Bifrost can sit between applications and AI providers and act as a control panel for model access, routing, budgets, observability, and policy enforcement.

Bifrost extends its governance model beyond standard LLM requests. Its MCP Gateway provides a central place to manage MCP tool connections, authentication, security, and policy enforcement, which becomes increasingly relevant as AI agents gain the ability to interact with external systems. More details are available in the Bifrost documentation.

The platform also provides OpenTelemetry support and built-in observability, alongside budgeting, provider fallback, virtual key management, and a unified interface for multiple AI providers. The current Bifrost site says the platform supports 25+ providers and more than 10,000 AI models, including custom-deployed models.

Key features

Access profiles: teams can create reusable policies defining permitted models, budgets, rate limits, and MCP tools, then attach those profiles to user roles, teams, or business units.
Virtual keys: each key can be restricted to specific providers, models, and MCP tools, while also being associated with a team or business unit for more controlled access and cost attribution.
RBAC and SSO: Bifrost supports fine-grained roles and permissions and can connect to enterprise identity providers through SSO and SCIM provisioning.
Budgets and rate limits: organizations can establish spending limits across business units, teams, virtual keys, and providers, while rate limits can control token and request usage.
Audit logs: requests can be recorded with details such as the user, virtual key, model, cost, and policy decision, with logs exportable to systems including S3, GCS, Datadog, and BigQuery.
MCP Gateway: MCP connections can be centralized so organizations can apply governance, security, authentication, and tool-level policies instead of allowing every application to manage MCP access independently.
Observability: OpenTelemetry support and built-in dashboards provide visibility into AI traffic and usage without requiring a separate observability layer for basic gateway monitoring.
Provider fallback: applications can automatically fail over between providers, helping maintain availability when a model or provider becomes unavailable.
Guardrails: Bifrost Enterprise includes guardrails designed to detect and block unsafe model outputs and enforce runtime policies across agents.

Strengths:

Infrastructure-level governance gives engineering teams a central enforcement point between applications and AI providers.
The open-source edition can be self-hosted, while Enterprise deployments can run in VPC, on-premises, or air-gapped environments, giving organizations full control over data, access, and execution while supporting enterprise security, policy enforcement, and governance requirements.
Governance covers both model traffic and MCP tool usage, which makes the platform relevant to agentic AI architectures as well as conventional LLM applications.
Budgeting, access control, virtual keys, routing, audit logs, and observability are handled through the same gateway rather than requiring separate controls in every application.

Don't use if:

You primarily need an AI risk and compliance management system for maintaining AI inventories, risk assessments, regulatory mappings, and governance workflows rather than controlling runtime AI traffic.
Your organization has only a small number of AI applications and models, so introducing a centralized gateway would add more infrastructure than value.

Learn more about Bifrost

Bifrost is available as an open-source project under Apache 2.0, with documentation covering gateway configuration, MCP governance, routing, observability, virtual keys, and deployment options. You can check the OSS version on GitHub.

2. Credo AI

AI governance and risk management for enterprise AI systems

Pricing: Custom enterprise pricing.

Setup time: Depends on the organization’s AI inventory, governance workflows, and integrations.

Credo AI is focused on governing AI across its lifecycle, from discovery and inventory through risk assessment, policy management, compliance, monitoring, and reporting. Its platform provides a centralized registry for AI systems, models, agents, applications, vendors, and shadow AI, giving governance teams a single place to track what is being used across the organization.

The platform also provides policy packs and risk workflows mapped to different frameworks. Credo AI supports governance workflows such as approvals, risk assessments, evidence generation, and continuous monitoring, making it more focused on enterprise AI governance and risk management than on being an AI gateway.

Strengths

AI inventory: Centralizes models, applications, agents, vendors, and other AI systems so teams can see what is being used.
Risk management: Provides AI-specific risk assessments, risk registers, controls, and mitigation workflows.
Policy and compliance: Maps governance requirements to major frameworks and provides policy packs and audit-ready evidence.
Enterprise governance: Supports governance workflows across AI, data, compliance, and business teams.

Don’t use if

You mainly need runtime AI traffic control: Credo AI is primarily a governance and risk platform rather than an infrastructure gateway for routing model requests.
You need a lightweight developer observability tool: Its broader governance workflow may be more than a small engineering team needs.

Deployment options: Enterprise SaaS and integrations with existing AI, data, security, and governance tooling.

3. Fiddler AI

AI observability, evaluation, and runtime safety

Pricing: Free tier; Developer is $0.002 per trace; Enterprise pricing is custom.

Setup time: Depends on the integrations and deployment model.

Fiddler focuses on understanding how AI systems behave in production. Its platform provides AI observability, testing, experiments, custom evaluators, and visualization for AI applications and agentic systems.

It also provides runtime guardrails for risks including hallucinations, toxicity, PII/PHI exposure, prompt injection, and jailbreak attempts. Enterprise customers can use SaaS, VPC, or on-premises deployment options.

Strengths

AI observability: Gives teams visibility into AI behavior and performance across production systems.
Runtime guardrails: Detects risks such as hallucinations, PII/PHI, prompt injection, and jailbreak attempts.
Evaluation workflows: Supports tests, experiments, custom evaluators, and bring-your-own judges.
Enterprise deployment: Enterprise supports SaaS, VPC, and on-premises deployment.

Don’t use if

You need a full AI governance registry: Fiddler is more focused on observability, evaluation, and safety than enterprise AI inventory and regulatory governance.
You need an AI gateway: Fiddler is not primarily designed as a centralized model/provider routing layer.

Deployment options: SaaS, VPC, or on-premises for Enterprise.

4. OneTrust

Enterprise AI inventory, risk, compliance, and runtime governance

Pricing: Custom pricing, based on admin users and AI inventory.

Setup time: Depends on the scope of the AI governance program and integrations.

OneTrust brings AI discovery, inventory, risk assessment, policy management, monitoring, and compliance workflows into one platform. It can track AI systems, models, agents, datasets, vendors, projects, and use cases, while applying risk assessments and governance workflows across the AI lifecycle.

OneTrust also extends governance into runtime environments. Its capabilities include monitoring AI behavior, detecting sensitive data and policy violations, applying controls to prompts and outputs, and governing agent permissions and MCP tool access.

Strengths

AI inventory: Provides a central system of record for AI systems, models, agents, datasets, and vendors.
Risk and compliance: Supports frameworks including the EU AI Act, NIST AI RMF, and ISO 42001.
Governance workflows: Provides intake, approvals, attestations, evaluation gates, and audit-ready evidence.
Runtime controls: Can detect policy violations and apply actions such as blocking, allowing, redacting, escalating, or routing.

Don’t use if

You only need an AI gateway: OneTrust's broader governance and risk capabilities may be unnecessary if the main requirement is model routing and spend control.
You want a developer-first observability platform: Its focus is broader enterprise governance rather than AI observability alone.

Deployment options: Enterprise deployment with integrations into supported AI platforms and runtime environments.

5. Speakeasy

AI control plane for agents, MCP servers, tools, and enterprise access

Pricing: Enterprise pricing is tailored to the organization.

Setup time: Speakeasy says most teams can be up and running within a day.

Speakeasy takes an access-control approach to AI governance. Its control plane provides a catalog of approved agents, MCP servers, and Skills, while access can be scoped by team and role through an organization's existing identity provider. Every governed action can be recorded in an audit trail.

The platform also checks prompts, responses, and tool calls against policy in real time. Speakeasy is designed to enforce least-privilege access for agents and can block threats such as prompt injection, PII exposure, and leaked credentials before they reach connected systems.

Strengths

Agent access control: Gives each agent an identity and controls what it can access based on roles and policies.
MCP governance: Provides a governed path for MCP servers and tools used by AI agents.
Runtime enforcement: Checks prompts, responses, and tool calls against policy before actions reach connected systems.
Auditability: Records allow-or-deny decisions and agent activity for investigation and compliance.

Don’t use if

You need a traditional AI GRC platform: Speakeasy is focused on AI access, security, agents, and runtime control rather than being a broad AI risk-management registry.
You mainly need model evaluation: Its core strength is controlling AI access and actions rather than model-quality evaluation.

Deployment options: Cloud or self-hosted deployment, including deployment in an organization's own cloud or on-premises environment.

Comparison of AI Governance Tools

Tool	Best fit	AI governance capabilities	Runtime / policy enforcement	Deployment options	Pricing posture
Bifrost	Enterprise teams that need AI gateway, governance, observability, and runtime policy enforcement	Model access, virtual keys, RBAC, budgets, rate limits, audit logs, MCP governance, observability, and guardrails	✅ Yes, policies can be enforced before AI requests reach providers	Self-hosted; Enterprise VPC, on-prem, and air-gapped	Free/open source; Enterprise custom
Credo AI	Enterprise AI governance and risk programs	AI inventory, agent registry, risk management, policy packs, compliance, monitoring, governance workflows	✅ Governance policies, controls, and trace-level policy enforcement	Enterprise platform with integrations across the AI stack	Custom enterprise pricing
Fiddler AI	AI observability, evaluation, and runtime safety	AI observability, evaluations, tests, experiments, custom evaluators, guardrails	✅ Real-time guardrails for hallucinations, toxicity, PII/PHI, prompt injection, and jailbreaks	SaaS; Enterprise VPC or on-premises	Free; $0.002/trace Developer; Enterprise custom
OneTrust	Enterprise AI inventory, risk, compliance, and runtime governance	AI inventory, risk assessment, policy management, approvals, monitoring, audit evidence	✅ Runtime controls across prompts, outputs, data access, and AI actions	Enterprise deployment with integrations into AI environments	Custom; based on admin users and AI inventory
Speakeasy	AI agents, MCP tools, and enterprise AI access control	MCP governance, tool catalog, RBAC, identity, audit trails, observability, threat detection	✅ Real-time inspection and policy enforcement across prompts, responses, and tool calls	Cloud; self-hosted data plane in your VPC	Made for enterprises only

Pricing note: Pricing and packaging change frequently, particularly for usage-based products and enterprise agreements. The figures above reflect publicly available vendor information checked in September 2026. Verify the current vendor pricing page before buying.

Which AI Governance Tool Should You Choose?

The right platform depends on where governance challenges exist inside your organization.

If compliance documentation and regulatory alignment are your biggest concerns, Credo AI and OneTrust are likely strong candidates.

If monitoring and production visibility matter most, Fiddler is difficult to ignore.

If access governance is your primary objective, Speakeasy deserves consideration.

For engineering teams building AI products, agents, and infrastructure, Bifrost offers a different perspective. Instead of focusing exclusively on compliance workflows, it introduces governance directly into the AI request path where costs, permissions, routing decisions, observability, and policy enforcement can be managed centrally.

FAQs

What are AI governance tools?

AI governance tools help organizations manage AI risk, security, compliance, observability, and operational controls.

Why do enterprises need AI governance?

Governance helps organizations safely scale AI usage while maintaining compliance, visibility, and control.

What is the difference between AI governance and AI observability?

Governance focuses on policies, controls, and compliance. Observability focuses on monitoring system behavior and performance.

What is the best AI governance tool?

The best choice depends on your team’s priorities. Compliance teams often evaluate Credo AI and OneTrust. Observability teams evaluate Fiddler. Infrastructure teams often evaluate Bifrost.

Can AI governance tools reduce AI costs?

Yes. Many platforms include budgets, quotas, spending controls, and cost monitoring. For example, Bifrost includes budgeting, virtual keys, rate limits, and provider-level controls that can help organizations manage AI spend across teams and applications.

Do AI governance tools support AI agents?

Most times, yes (depending on the tool). Modern governance platforms are starting to have models that support agents and MCP-based workflows. For example, Bifrost includes MCP governance capabilities designed to help organizations manage how agents access external tools and systems.

Are AI governance tools required for compliance?

While not always legally required, they can significantly simplify regulatory compliance and audit preparation.

Can startups benefit from AI governance?

Yes. Governance helps organizations establish good operational practices before AI usage scales. Platforms like Bifrost introduce controls such as budgets, access policies, observability, and auditability early, making growth easier to manage later.

Calling a TypeScript Backend Without Integration Code - A Simple Task Tracker with Graftcode

Opemipo Disu — Thu, 20 Aug 2026 09:26:08 +0000

Most developers building frontend applications spend a lot of time writing code that communicates with their backend due to the traditional approach (using APIs).

This is not because the logic is hard to implement, but because the communication itself is complex. When using standard APIs, we build routes, define request and response models, generate clients, and keep multiple layers on track with application updates.

Instead of exposing backend functionality through REST endpoints and consuming it through HTTP clients, Graftcode exposes backend methods directly and generates packages that applications can install and use as dependencies. The result is a communication model that is like you are calling a library rather than consuming an API with strongly typed clients. Working with Graftcode is very simple: install your library and call its functions.

In this article, we'll be building a simple task tracker or to-do list application using React and a TypeScript backend to see what working with Graftcode looks like.

In this blog post, we will learn the following:

Why API layers require you to maintain APIs manually
How Graftcode exposes backend functionality through Graftcode Gateway
How Graftcode Vision helps discover backend capabilities
Familiarity with APIs and fetch() requests
How React applications can use TypeScript backend logic without building API routes
Why strongly-typed backend packages can improve developer experience

Prerequisites

Let’s get our hands a bit dirty, but before we do, there are some need-to-haves to get you started. Let’s have a look at that in this section:

Latest Node version installed on your machine
Basic knowledge of React and TypeScript
Familiarity with how APIs and fetch requests work (for understanding how easy Graftcode’s approach is)
A Graftcode account
Graftcode gateway installed on your local machine

With these prerequisites, you’ll first understand why most to-do list applications rely heavily on APIs for their logic and what challenges that approach can introduce.

Why Do To-Do List Applications Rely on APIs?

To-do list applications require some logic for functionality. However, most developers are familiar with exposing backend functionality through APIs and consuming that functionality from frontend applications. As much as task management applications are easy to build, they are also one of the most common examples of frontend-backend communication.

The reason why even a simple to-do application needs logic is to:

Create tasks
Retrieve tasks
Update task status
Delete tasks

In a to-do list application that uses an API, the frontend doesn't communicate directly with the logic responsible for creating, updating, or retrieving tasks. Instead, every interaction goes through different layers before reaching the actual functionality.

When a user creates a task, the frontend typically sends a request using the fetch() function or another HTTP client. That request is received by an API endpoint, processed by a controller or route handler, forwarded to the appropriate business logic, and often persisted to a database before a response is returned to the user.

This architecture is widely used in the developer ecosystem and works well, but it also means developers need to maintain more than just the feature they’re trying to implement. Every new feature often requires additional routes, request validation, response handling, documentation updates, and frontend integration work. As applications grow, the communication layer can even become as complicated as the initial logic.

For context: when working with APIs, some endpoints get exposed - here are examples:

POST /tasks
GET /tasks
PATCH /tasks/{id}
DELETE /tasks/{id}

Delving into Graftcode

Rather than creating another application with traditional APIs, we'll build a task tracker that communicates directly with backend functionality exposed through Graftcode (a tool that runs your backend as a package).

The application will allow users to create new tasks, view existing tasks, mark tasks as completed, delete tasks, and view task status updates instantly.

The goal isn't necessarily to build the most advanced task management application. But rather to understand how a React frontend can interact with backend logic without building API routes.

Use Case for Graftcode: To-do List Application with Graftcode

In this section, we’ll take a look at how to work with Graftcode and when you should use it.

Graftcode works particularly well when frontend and backend applications are developed together and benefit from a strongly typed integration layer. Instead of maintaining API routes, request models, and generated clients, developers can consume backend functionality through generated packages.

This can be useful for internal tools, full-stack applications, prototypes, and systems where backend functionality is primarily consumed by trusted applications.

We will be building a task tracker application without writing API routes, controllers, or integration boilerplate. To be clear, we need to create a project first:

npm create vite@latest graftcode-todolist-app -- --template react-ts
cd graftcode-todolist-app
npm install
npm install tailwindcss @tailwindcss/vite
npm install vite-plugin-node-polyfills

After doing this, you need to update your vite.config.ts to enable the polyfills.

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import tailwindcss from "@tailwindcss/vite";
import { nodePolyfills } from "vite-plugin-node-polyfills";
import { resolve } from "path";

export default defineConfig({
  plugins: [
    react(),
    tailwindcss(),
    nodePolyfills({ exclude: ["crypto"] }),
  ],
  resolve: {
    alias: {
      crypto: resolve("./src/crypto-shim.js"),
    },
  },
});

Then in src/index.css, put this code there:

@import "tailwindcss";

After doing this, create a crypto-shim.js file in the src/ directory:

export const randomUUID = () => window.crypto.randomUUID();
export default { randomUUID };

Create the Backend Module

Now, this is where everything begins. We need to work on configuring the backend module.

Let's start with the backend service that will manage our tasks. Inside the project folder, create a task-backend/ directory and initialize it for the project’s backend logic:

mkdir task-backend
cd task-backend
npm init -y
mkdir backend

After initializing the backend project, we need to tell Graftcode Gateway where the backend entry point is located.

The gateway reads the main field from package.json to find and load your backend service. Since our service will live inside backend/index.js, update your package.json file and add the following main property:

{
  "name": "task-backend",
  "version": "1.0.0",
  "main": "./backend/index.ts"
}

Inside the backend/ directory, create an index.ts file with the following code:

import { randomUUID } from "crypto";

interface Task {
  id: string;
  title: string;
  description: string;
  completed: boolean;
  createdAt: number;
}

export class TaskService {
  private static tasks: Task[] = [];

  static createTask(
    title: string,
    description: string = ""
  ): string {
    const task: Task = {
      id: randomUUID(),
      title,
      description,
      completed: false,
      createdAt: Date.now(),
    };

    TaskService.tasks.push(task);

    return JSON.stringify(task);
  }

  static getTasks(): string {
    return JSON.stringify(TaskService.tasks);
  }

  static completeTask(id: string): string {
    const task = TaskService.tasks.find(
      (task) => task.id === id
    );

    if (!task) {
      return JSON.stringify(null);
    }

    task.completed = true;

    return JSON.stringify(task);
  }

  static deleteTask(id: string): boolean {
    const before = TaskService.tasks.length;

    TaskService.tasks = TaskService.tasks.filter(
      (task) => task.id !== id
    );

    return TaskService.tasks.length < before;
  }
}

That’s the entire backend logic for the to-do list application. As you can see, it’s very straightforward - we didn’t have to call any APIs, define routes, nor requests. Instead, we're focusing on the capabilities the application actually needs.

We defined the TaskService class with static methods. The class keeps tasks in memory, creates new tasks with a UUID, returns the full list, marks a task as complete, and deletes tasks when needed. Because everything lives in one exported class, Graftcode can expose those methods directly without us defining controllers or routes around them.

The service exposes four methods:

createTask()
getTasks()
deleteTask()
completeTask()

Exposing the Service Through Graftcode Gateway

Now that the backend logic exists, the next thing is to find a way for other applications to use it. In Graftcode, the way to do this is to use its gateway.

Graftcode Gateway (gg) is the runtime that exposes your application's public methods for consumption. It can be installed using the official Docker image or directly from the releases page on the Graftcode Gateway GitHub repository.

gg ./package.json --projectKey YOUR_PROJECT_KEY --port 8080

To get the project key, do the following in your Graftcode dashboard:

Head over to the Vision panel
Create a new gateway
In the deployment options section, hit the “I already have Graftcode Gateway” button: This skips the download process and automatically generates a new project key for you.

The gateway reads your package.json, finds the main entry point, loads TaskService, and registers all four methods automatically.

Once running, the gateway prints the exact install command for your project. The package name is generated automatically by the gateway. Copy the exact install command printed in your terminal:

npm install --registry https://grft.dev/YOUR_PROJECT_ID__graftcode @graft/npm-task-backend@1.0.0

Copy the command exactly as printed, alongside the project ID in the URL, which is specific to your account.

Once the gateway is running, open the Graftcode Vision URL displayed in the terminal output. This launches Graftcode Vision, where you can inspect your backend classes, methods, and installation details.

Exploring Your Backend In Graftcode Vision

Graftcode Vision is the discovery layer for your backend. Instead of reading through Swagger docs or manually checking endpoint definitions, you can inspect the actual classes, package installation, and methods exposed by the service in Graftcode Vision.

When Vision loads, you should see your TaskService class and the methods it provides.

In Graftcode Vision, you can inspect:

Installation/Configuration
Available methods
Parameters
Return types
Method descriptions

Install the Configured Package

In the project’s root, configure the @graft registry so npm knows where to find the generated package:

echo "@graft:registry=https://grft.dev/YOUR_PROJECT_ID__graftcode" >> .npmrc

Be sure to always replace your actual project ID as shown in your Graftcode portal. Then install the generated package using the exact command the gateway printed when it started - so this is wrapped into Graftcode now:

npm install --registry https://grft.dev/YOUR_PROJECT_ID__graftcode @graft/npm-task-backend@1.0.0

You can also test methods directly before connecting them to your frontend. That becomes useful as your service grows and exposes more functionality.

Creating the React Frontend

Now that the backend is ready, let's build the frontend. In your App.tsx file, import the generated package and configure the gateway host. You can have a look at your Graftcode Vision’s configuration and find the best route for importing:

import { GraftConfig } from "@graft/npm-task-backend";
GraftConfig.host = `ws://localhost:8080/ws`;

The GraftConfig.host is the WebSocket URL of your running gateway. Ensure the backend is currently running in a separate terminal. That is the entire connection setup you need to work with Graftcode. You don’t need any base URLs, HTTP clients, or middleware.

After doing this, all you need to do is call your backend methods like regular functions in your frontend. You can paste this in your App.tsx file:

import { GraftConfig, TaskService } from "@graft/npm-task-backend";

GraftConfig.host = "ws://localhost:8080/ws";

const fetchTasks = async () => {
  const tasks = await TaskService.getTasks();
  return tasks;
};

When the frontend loads, it automatically calls fetchTasks() to get the current list of tasks from TaskService.getTasks().

With the backend connection in place, we can build the rest of the task tracker. The complete App.tsx file below uses the generated Graft package to retrieve tasks, create new ones, mark them as completed, and delete existing items.

import { useState, useEffect } from "react";
import { GraftConfig, TaskService } from "@graft/npm-task-backend";

GraftConfig.host = "ws://localhost:8080/ws";

interface Task {
  id: string;
  title: string;
  description: string;
  completed: boolean;
  createdAt: number;
}

export default function App() {
  const [tasks, setTasks] = useState<Task[]>([]);
  const [title, setTitle] = useState("");
  const [description, setDescription] = useState("");
  const [submitting, setSubmitting] = useState(false);
  const [error, setError] = useState<string | null>(null);
  const [actionLoading, setActionLoading] = useState<string | null>(null);

  const fetchTasks = async () => {
    try {
      let data: any = await TaskService.getTasks();

      if (typeof data === "string") {
        try {
          data = JSON.parse(data);
        } catch {}
      }

      setTasks(Array.isArray(data) ? data : []);
    } catch (e: any) {
      console.error("getTasks error:", e);
      setError(e?.message || "Failed to fetch tasks");
    }
  };

  useEffect(() => {
    fetchTasks();
  }, []);

  const handleCreate = async (e: React.FormEvent) => {
    e.preventDefault();

    if (!title.trim()) return;

    setSubmitting(true);
    setError(null);

    try {
      await TaskService.createTask(title.trim(), description.trim());

      setTitle("");
      setDescription("");

      await fetchTasks();
    } catch (e: any) {
      setError(e?.message || "Failed to create task");
    }

    setSubmitting(false);
  };

  const handleComplete = async (id: string) => {
    setActionLoading(id + "-complete");

    try {
      await TaskService.completeTask(id);
      await fetchTasks();
    } catch (e: any) {
      setError(e?.message || "Failed to complete task");
    }

    setActionLoading(null);
  };

  const handleDelete = async (id: string) => {
    setActionLoading(id + "-delete");

    try {
      await TaskService.deleteTask(id);
      await fetchTasks();
    } catch (e: any) {
      setError(e?.message || "Failed to delete task");
    }

    setActionLoading(null);
  };

  const completed = tasks.filter((task) => task.completed).length;

  return (
    <div className="min-h-screen bg-gray-50 p-5">
      <div className="max-w-lg mx-auto space-y-4">

        {/* Header */}
        <div className="flex items-center justify-between">
          <h1 className="text-lg font-semibold text-gray-900">
            Task Tracker
          </h1>

          <span className="text-xs text-gray-400">
            {completed}/{tasks.length} done
          </span>
        </div>

        {/* Create Form */}
        <form
          onSubmit={handleCreate}
          className="bg-white border border-gray-200 rounded-xl p-4 space-y-2"
        >
          <input
            type="text"
            placeholder="Task title"
            value={title}
            onChange={(e) => setTitle(e.target.value)}
            className="w-full bg-gray-50 border border-gray-200 rounded-lg px-3 py-2 text-sm text-gray-900 placeholder-gray-400 focus:outline-none focus:border-gray-400 transition-colors"
          />

          <input
            type="text"
            placeholder="Description (optional)"
            value={description}
            onChange={(e) => setDescription(e.target.value)}
            className="w-full bg-gray-50 border border-gray-200 rounded-lg px-3 py-2 text-sm text-gray-900 placeholder-gray-400 focus:outline-none focus:border-gray-400 transition-colors"
          />

          <button
            type="submit"
            disabled={submitting || !title.trim()}
            className="w-full bg-gray-900 hover:bg-gray-700 disabled:opacity-30 text-white py-2 rounded-lg text-sm font-medium transition-colors"
          >
            {submitting ? "Adding..." : "Add Task"}
          </button>
        </form>

        {/* Error */}
        {error && (
          <div className="text-xs text-red-500 px-1">
            {error}
          </div>
        )}

        {/* Task List */}
        <div className="space-y-2">
          {tasks.length === 0 && (
            <div className="text-center text-gray-400 text-sm py-8">
              No tasks yet.
            </div>
          )}

          {[...tasks].reverse().map((task) => (
            <div
              key={task.id}
              className={`bg-white border border-gray-200 rounded-xl px-4 py-3 flex items-center gap-3 ${
                task.completed ? "opacity-50" : ""
              }`}
            >
              {/* Complete */}
              <button
                onClick={() =>
                  !task.completed && handleComplete(task.id)
                }
                disabled={
                  task.completed ||
                  actionLoading === task.id + "-complete"
                }
                className="flex-shrink-0"
              >
                {task.completed ? (
                  <div className="w-4 h-4 rounded-full bg-gray-900 flex items-center justify-center">
                    <svg
                      className="w-2.5 h-2.5 text-white"
                      fill="none"
                      stroke="currentColor"
                      strokeWidth={3}
                      viewBox="0 0 24 24"
                    >
                      <path
                        strokeLinecap="round"
                        strokeLinejoin="round"
                        d="M5 13l4 4L19 7"
                      />
                    </svg>
                  </div>
                ) : (
                  <div className="w-4 h-4 rounded-full border-2 border-gray-300 hover:border-gray-500 transition-colors" />
                )}
              </button>

              {/* Content */}
              <div className="flex-1 min-w-0">
                <div
                  className={`text-sm ${
                    task.completed
                      ? "line-through text-gray-400"
                      : "text-gray-900"
                  }`}
                >
                  {task.title}
                </div>

                {task.description && (
                  <div className="text-xs text-gray-400 truncate">
                    {task.description}
                  </div>
                )}
              </div>

              {/* Delete */}
              <button
                onClick={() => handleDelete(task.id)}
                disabled={
                  actionLoading === task.id + "-delete"
                }
                className="text-gray-300 hover:text-red-400 disabled:opacity-30 transition-colors flex-shrink-0"
              >
                <svg
                  className="w-4 h-4"
                  fill="none"
                  stroke="currentColor"
                  strokeWidth={2}
                  viewBox="0 0 24 24"
                >
                  <path
                    strokeLinecap="round"
                    strokeLinejoin="round"
                    d="M6 18L18 6M6 6l12 12"
                  />
                </svg>
              </button>
            </div>
          ))}
        </div>
      </div>
    </div>
  );
}

The app lets users create, complete, and delete tasks by calling the backend methods like createTask(), completeTask(), and deleteTask() Instead of using API requests via fetch(). After each action, it refreshes the task list so the UI stays up to date. It also handles loading and error states, so the user gets feedback while actions are happening.

After this, you can run your frontend in a separate terminal:

npm install
npm run dev

You should have this UI in your browser and should be able to create tasks, delete them, and check if they are complete:

What really stands out here is how little friction there is between the frontend and backend. With Graftcode, the backend feels less like a separate system you have to manually integrate with and more like a typed extension of your app. That means less boilerplate, fewer moving parts, and a much smoother development experience.

A Quick Breakdown

At a high level, the entire application follows a straightforward flow:

Initialize the backend connection by setting the Graftcode host.
Define the task shape with a TypeScript interface so the UI knows what data to expect.
Call backend methods directly to create, complete, and delete tasks.
Refresh the UI after each action so the displayed data always matches the backend state.
Show loading and error feedback to keep the experience clear and responsive.

What makes this approach compelling is that the frontend never has to manage API routes, write request wrappers, or keep track of endpoint URLs. Instead, it interacts with backend functionality in a much more direct way, which keeps the component focused on UI behavior rather than network plumbing.

That’s a big deal if you’ve ever spent too much time stitching together frontend and backend code just to move data around. Graftcode removes a lot of that friction. For teams that want to move faster without sacrificing type safety, that’s a pretty attractive tradeoff.

An interesting fact about using Graftcode is its developer experience: the fact that you’re able to select classes and methods from the IDE with the code completion feature in IDEs, which even makes it easy for people to use.

Conclusion

And that’s it; we’ve built a simple task tracker that shows how React can work directly with a TypeScript backend through Graftcode without the usual API layer in between.

Instead of spending time creating routes, controllers, request handlers, and client-side fetch() calls, we were able to expose backend functionality as methods and use them like a package. That makes the development experience feel direct, especially for applications where frontend and backend are tightly connected.

What is incredible is how you don’t need much setup once the backend is exposed via Graftcode Gateway. As mentioned in this blog post, with Graftcode Vision, you can inspect the available methods, understand their inputs and outputs, and install the generated package into your frontend with strong typing and better discoverability. That means less guessing, fewer integration bugs, and a much nicer developer experience overall.

By extending this project, you’ll get a better feel for how Graftcode fits into real-world development workflows and where it can simplify your stack. The more you use it, the more obvious the benefits become: less boilerplate, stronger typing, faster iteration, and a cleaner path from backend logic to frontend UI.

If you found this useful, try building your own small app with Graftcode and see how it changes the way you connect frontend and backend logic. Once you experience how direct the workflow feels, it’s pretty hard to go back to writing fetch calls for everything.

Stop Using Fetch() in React: A Better Way To Call Your Backend

Opemipo Disu — Mon, 25 May 2026 08:44:57 +0000

Developers have an ‘unspoken struggle’ when communicating with APIs. When working on an interactive application, developers constantly need to communicate their frontend to their backend logic.

The hassle of writing logic, connecting routes, and defining endpoints is a huge part of building that developers would prefer to avoid. With tools like Graftcode, developers can install a strongly-typed backend package that connects directly to their backend, instead of manually writing API clients, routes, and endpoint integration code.

What You’ll Learn

Why using fetch() can be a complex approach
How Graftcode removes the need for building APIs
How to expose your own backend logic through Graftcode Gateway
How to call backend modules can be used in React applications as dependencies without writing APIs

Prerequisites

This tutorial assumes the reader has the following:

Node >= 22 or higher installed on their local development machine
npx 7.2 or higher is installed on their local development machine
Basic understanding of how to work with fetch() or REST APIs
A basic knowledge of JavaScript and React
A Stripe account with in test mode

Once you have these prerequisites, you’re ready to begin this tutorial. In this blog post, you’ll learn how Graftcode works and how to use Graftcode as a connector between your React frontend and Node.js backend without manually building an API. This blog post/tutorial includes a demo that shows how to build an interactive application by just building your application’s logic through an imported backend.

Why Do Developers Still Use `fetch()` in React?

Most applications still rely on the regular pattern of using fetch() or other HTTP clients. Here’s the most common approach React applications use when communicating with their backend:

Image Credit: Babar saad

This approach works, but it increases workload and introduces friction, and, unknowingly to most developers, it creates problems such as:

Repeated boilerplate for every endpoint
Manual serialization and parsing
Increased workload when building new features

API layers are not necessary for many applications, but it’s common practice and introduces the issues listed above.

There is an alternate way to call your backend apart from using fetch() and other HTTP-based clients. With this option, you don’t need to worry about creating requests, API routes, and managing them. An alternate option is to use Graftcode, which is what this blog post will be all about.

What Is Graftcode?

Graftcode is a tool that lets you call backend functions and methods from another runtime without manually building REST APIs, writing HTTP client code, or creating custom SDKs. Instead of treating your backend as a collection of endpoints, Graftcode packages backend logic as a strongly-typed, installable dependency.

Graftcode uses its Gateway to expose selected backend classes and methods and generates a package, called a Graft, that you can install directly in your application. Once installed, you can import backend modules and call their methods like regular functions, while Graftcode handles the communication between your application and the backend runtime.

This works whether your frontend and backend are written in different languages or the same language. When they are different, Graftcode bridges runtimes so one side can call methods from the other. When they are the same, as in this React and Node.js example, the main benefit is removing the manual REST/API layer, routes, and fetch() calls between them.

In practice, Graftcode changes how interactive applications are built. Instead of configuring endpoints, maintaining client code, and managing API integration logic, you expose backend methods through Graftcode Gateway, install the generated Graft package, import the module you need, and call the method directly.

For example, here’s a traditional way to call Stripe’s SDK with React:

fetch('/api/create-intent') -> Express route -> Stripe SDK

When using Graftcode to call Stripe’s SDK through React, here’s what you do:

StripeService.createPaymentIntent() -> [WebSocket] -> Node.js

With Graftcode, you just call functions; you do not need Express, routes, or even fetch().

Use Case for Graftcode: Stripe Dashboard without a REST API

In this section, we’ll take a look at how to work with Graftcode and when you should use it.

We will be building an interactive Stripe dashboard in React. Yes - without a single API! This isn’t just a simple example; this is an interactive application that does three things:

Create a payment intent with Stripe
Generate payment links
List your most recent transactions
Displays your Stripe’s revenue summary

All these will be done without using a single REST endpoint. However, since we’re using Stripe Node.js SDK, which requires a secret key and cannot run in the browser, we will have the SDK as a backend and expose it through Graftcode Gateway.

This section has been broken down into different steps to make it easy to understand how to build applications with Graftcode using React.

Step 1: Create a React Project

Firstly, we’ll create a React application from scratch using Vite:

npm create vite@latest graftcode-demo -- --template react
cd graftcode-demo
npm install

Step 2: Install Hypertube NodeJS SDK

Navigate to the project within your CLI and install hypertube-nodejs-sdk - It’s needed for the Websocket transport layer as it uses Node.js built-in features that don’t exist in the browser. Vite needs to polyfill them; to do this, install the SDK and the polyfill plugin:

npm install hypertube-nodejs-sdk vite-plugin-node-polyfills

After doing this, you need to update your vite.config.js to enable the polyfills.

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import { nodePolyfills } from 'vite-plugin-node-polyfills';
import { resolve } from 'path';

export default defineConfig({
  plugins: [
    react(),
    nodePolyfills({ exclude: ['crypto'] }),
  ],
  resolve: {
    alias: {
      crypto: resolve('./src/crypto-shim.js'),
    },
  },
});

After doing this, create a crypto-shim.js file in the src/ directory:

export const randomUUID = () => window.crypto.randomUUID();
export default { randomUUID };

Step 3: Create the Backend Module

Now, this is where the real work begins; we need to work on configuring the backend module, as we can’t import certain backend modules like the one we want to work with, for now (Graftcode is in its beta version).

Inside the project folder, create a backend/ directory and initialize it as its own Node.js project:

mkdir backend
cd backend
npm init -y
npm install stripe dotenv

In the directory, create an index.js file inside the backend/ directory with a class that has your Stripe logic:

require("dotenv").config();
const Stripe = require("stripe");
const stripe = Stripe(process.env.STRIPE_SECRET_KEY);

class StripeService {
  static async createPaymentIntent(amount, currency) {
    amount = amount ?? 1000;
    currency = currency ?? "gbp";
    const intent = await stripe.paymentIntents.create({ amount, currency });
    return JSON.stringify({
      id: intent.id,
      amount: intent.amount,
      currency: intent.currency,
      status: intent.status,
      client_secret: intent.client_secret,
    });
  }

  static async createPaymentLink(amount, currency, name) {
    amount = amount ?? 1000;
    currency = currency ?? "gbp";
    name = name ?? "Payment";
    const price = await stripe.prices.create({
      currency,
      unit_amount: amount,
      product_data: { name },
    });
    const link = await stripe.paymentLinks.create({
      line_items: [{ price: price.id, quantity: 1 }],
    });
    return JSON.stringify({ id: link.id, url: link.url, active: link.active });
  }

  static async listTransactions() {
    const result = await stripe.paymentIntents.list({ limit: 5 });
    return JSON.stringify(
      result.data.map((pi) => ({
        id: pi.id,
        amount: pi.amount,
        currency: pi.currency,
        status: pi.status,
        description: pi.description || "Payment intent",
      }))
    );
  }

  static async getRevenueSummary() {
    const result = await stripe.paymentIntents.list({ limit: 100 });
    const succeeded = result.data.filter((pi) => pi.status === "succeeded");
    const totalRevenue = succeeded.reduce((sum, pi) => sum + pi.amount, 0);
    return JSON.stringify({
      totalRevenue,
      avgTransaction: succeeded.length > 0 ? Math.round(totalRevenue / succeeded.length) : 0,
      successRate: Math.round((succeeded.length / result.data.length) * 100),
      counts: { succeeded: succeeded.length, total: result.data.length },
    });
  }
}

module.exports = { StripeService };

In the code snippet above, the plan was to create a normal Node.js class without decorators, frameworks, and special annotations. The pattern is a class with static methods ****exported by name. That is how Graftcode discovers and registers your backend logic.

Note that the method returns JSON.stringify() rather than plain objects. Graftcode's transport layer wraps the object return values as remote references and returns a JSON string as the platform requires it.

Create a .env in the same backend directory:

STRIPE_SECRET_KEY=sk_test_your_key_here

You can get the Stripe secret key from your dashboard. To get this:

Head over to Stripe’s Test account Dashboard
Hit the Developers panel
Select API Keys
Get your secret key from the Standard Keys panel

Step 3: Expose the Backend With Graftcode Gateway

In this section, we’ll be doing a bit more work on the backend - read this guide to learn more about exposing your backend with Graftcode’s gateway.

To begin with, run it against your backend:

gg ./package.json --projectKey YOUR_PROJECT_KEY --port 8080

To get the project key, do the following in your Graftcode dashboard:

Head over to the Vision panel
Create a new gateway
In the deployment options section, hit the “I already have Graftcode Gateway” button: This skips the download process and automatically generates a new project key for you.

The gateway reads your package.json, finds the main entry point, loads StripeService, and registers all four methods automatically.

Once running, the gateway prints the exact install command for your project. It looks like this:

npm install --registry https://grft.dev/YOUR_PROJECT_ID__graftcode @graft/npm-backend@1.0.0

Copy the command exactly as printed, alongside the project ID in the URL, which is specific to your account.

Step 4: Install the Configured Package

In the project’s root, configure the @graft registry so npm knows where to find the generated package:

echo "@graft:registry=https://grft.dev/YOUR_PROJECT_ID__graftcode" >> .npmrc

npm install @graft/npm-backend@1.0.0

Step 5: Import the Backend From Your React Application

The next step after configuring your backend is to import it into your frontend. In your App.jsx, import the generated package and configure the gateway host.

You can retrieve the gateway host URL from Graftcode Vision. Open your project in the Vision portal, navigate to your running gateway, and copy the WebSocket endpoint shown for your deployment. When running locally, this will usually look like ws://localhost:8080/ws.

import { GraftConfig, StripeService } from "@graft/npm-backend";
GraftConfig.host = "ws://localhost:8080/ws";

In the code snippet above, the GraftConfig.host is the WebSocket URL of your running gateway. Ensure the backend is currently running on a separate terminal. That is the entire connection setup you need to work with Graftcode. You don’t need any base URLs, HTTP clients, or middleware.

All you need to call your backend methods like regular functions like this:

const raw = await StripeService.createPaymentIntent(1000, "gbp");

const raw2 = await StripeService.createPaymentLink(1000, "gbp", "demo Product");

const raw3 = await StripeService.listTransactions();

const raw4 = await StripeService.getRevenueSummary();

Each function call moves over WebSocket to the gateway, which runs it in Node.js, where the Stripe SDK is wrapped, and returns the result. What Graftcode eliminates is all the code you would normally write around it, and the direct contact the SDK has with your browser.

You can compare this approach to the traditional approach. To work with Stripe traditionally, you’ll be working with endpoints directly, which is a stressful approach. Here’s an example of what you’ll be doing normally:

const res = await fetch("/api/create-intent", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ amount: 1000, currency: "gbp" }),
});
const intent = await res.json();

With this, you need to ensure there’s a configured endpoint for the create-intent. Whereas, in Graftcode, all you need to do is call functions. In fact, in your IDE, when you type your function, it raises suggestions based on the imported module; this way, it’s easy for you to use Graftcode.

With the traditional approach, you would need the Express route, the request validation, the response shape, the error handling, and you would maintain them. With Graftcode, you write the function once and call it.

Step 6: Exploring Backend Methods with Graftcode Vision

Now, the React application has been connected to a backend without writing any API routes. But there’s another part of the Graftcode experience that makes this workflow even more interesting: Graftcode Vision.

Unlike working with API workflows, where you rely on documentation, Swagger specs, or tools like Postman, Graftcode Vision lets you see your backend in modules. When you open it in the browser, you’re not looking at endpoints or routes. You are looking at actual classes and methods; the actual ones you imported.

In the portal, you can inspect the module’s classes, see every method it exposes, understand the parameters it expects, and even test those methods live. It removes the guesswork that developers usually deal with when integrating APIs.

Step 7: Run Your Entire Application

As mentioned earlier, you need to start the gateway from the backend/ directory in one terminal:

cd backend
gg ./package.json --projectKey YOUR_PROJECT_KEY --port 8080

Start your React application from your project’s root in a separate terminal:

npm run start OR npm run dev

Click any button in the application - they perform different functions. When a button is clicked, a call goes over WebSocket to Node.js, hits the Stripe API, and returns a response without a REST API, endpoints, or fetch().

In your Stripe dashboard, you should see recent interactions with your Stripe.

A Deeper Look at Graftcode

The code looks simple and also looks like an easier path to making things work, but there’s a bigger change than the simplicity.

In a normal setup, your frontend and backend communicate through an API that you manually built.

The four methods we configured in StripeService: createPaymentIntent, createPaymentLink, listTransactions, getRevenueSummary , would normally be an Express route. You would define the route, its request shape, response shape, and the error handling. You would write fetch() calls on the React side and keep both in sync.

Here, you expose them through the gateway, gg. The auto-generated @graft/npm-backend package is what React imports and calls. The most interesting thing is: instead of writing routes and fetch() calls, you write functions and let Graftcode handle the communication.

Conclusion

If you look back at the application you built in this tutorial, the most interesting part is the fact that none of it required an API.

There were no routes to define or anything to write, and no requests to construct. The entire interaction between frontend and backend was reduced to a simple method call, without losing any capability.

Thank you for taking the time to read this blog post. If you enjoyed this blog post, you can do well to try out Graftcode and check out some of its resources that will be listed in the references section.

If you have any questions, leave them in the comments section below. See you in the next blog post!

References

Expose your backend with Graftcode (JavaScript) - Learn how to expose backend logic and connect it to your frontend using Graftcode.
Graftcode Modules Portal - Browse and install backend modules that can be used directly in your applications.
Graftcode Documentation - Explore detailed tutorials and explanations of how Graftcode works.

Are AI Observability Tools Actually Helping?

Opemipo Disu — Mon, 30 Mar 2026 13:03:35 +0000

Observability tools have been feeling very different lately.

Almost every platform now claims to offer some “AI-powered” feature, such as anomaly detection, root cause analysis, automated insights, and even suggested fixes.

But I’m not sure how much of it is actually useful in workflows.

From what I’ve seen, most teams still deal with:

Too many alerts
Jumping between logs, metrics, and traces
Spending so much time figuring out root causes

And even with AI features, a lot of tools still feel like:

“Here’s more data… just slightly reorganized”

At the same time, there are some interesting improvements:

automatic correlation between signals
faster incident investigation
less manual digging in some cases

So it’s not all hype, but it also doesn’t feel like a complete shift yet.

Curious about real usage

Are you actually using AI features in your observability stack?
Has it reduced alert fatigue at all?
Or are you mostly ignoring those features?

I recently looked into this while comparing a bunch of AI-powered observability tools and how they’re evolving.

If anyone’s interested in the full breakdown, I put it here:

https://metoro.io/blog/best-observability-tools-with-ai

Feels like we’re in that phase where:

The idea is solid, but the execution is still catching up

It would be interesting to hear what others are seeing in production.

[Boost]

Opemipo Disu — Sat, 20 Dec 2025 13:45:53 +0000

A Practical Guide to Building Your First Automation Workflow

Opemipo Disu ・ Dec 19

#programming #ai #beginners #tutorial

A Practical Guide to Building Your First Automation Workflow

Opemipo Disu — Fri, 19 Dec 2025 11:38:08 +0000

Recently, I’ve been exploring the world of automation basically because I got tired of working with tools and handling tasks manually by writing scripts to make things happen. However, I wanted an easier approach; something visual and flexible, and my search led me to the world of automation workflows.

Along the way, I found a life-changing tool for workflow automation, ByteChef, that enabled me to integrate different tools and build workflows in a straightforward way.

What is ByteChef?

Bytechef is an open-source workflow automation and integration tool that lets you work with APIs and tools; it’s a tool that visually and seamlessly orchestrates connections with your favorite tools. With ByteChef, you can easily work with your best tools without necessarily writing a single line of code.

So, instead of manually working with data from different tools, or creating complex processes, ByteChef provides an interactive interface and robust capabilities to bring your automation ideas to life.

ByteChef’s capabilities aren't just limited to building workflow automations, it also enables you to work with different APIs of your choice. For example, you can connect APIs into your application with ByteChef. In this blog post, we won’t be focusing on this feature as we will have a deep look into the workflow automation feature.

ByteChef can be ran in two ways: cloud (we manage it for you) and self-hosted (you run it on Docker). Cloud is easier to start with. If you want to self-host, you can check the GitHub repo for setup steps. For this guide, we'll use the Cloud approach, but everything works the same on both.

Before moving to the next section of this article, I just dropped a video on YouTube where you can see how to create your first workflow in ByteChef. In this video, you’ll learn about ByteChef and how to work with it - you can see it as a video version of this blog post.

Key Features of ByteChef

Even while ByteChef provides the workflow automation feature, there are other great features that work with the workflow automation feature. In this section of the article, we’ll have a look at features that makes up the workflow automation:

Multi-Application Integration: With ByteChef, you can work with over 200+ tools including Gmail, Slack, Google Drive, and OpenAI. The fun of this integration is that you're not locked into a single ecosystem. Whether you're using productivity tools like Google Workspace, communication platforms like Slack, or AI services like OpenAI, ByteChef connects them all seamlessly.
Visual Workflow Builder: ByteChef lets you design and configure workflows using an interactive interface without writing code. This doesn’t mean you aren’t allowed to write code; while using Bytechef, you don’t need to write complex code - in fact, writing code is optional when you’re using ByteChef. The main work while using ByteChef is just adding components, triggers, and configuring them.
Flow Logic: ByteChef enables you to create smart workflows with branching logic, conditions, and decision points. This is what transforms workflows from simple into smart automation. You can create complex decision trees with multiple conditions; in ByteChef, we have different flows:
Condition: Here’s a very basic flow; it checks something (for example; if something is urgent or not) and goes left if true, right if false. Pretty simple.
Branch: This flow is very similar to condition, but handles more than just true/false. You can have multiple different paths.
Each: When you have a list of things, this flow runs the same steps for each item. For example, if you have 10 emails, it processes all 10 the same way.
Loop (In Progress): Repeats the same thing over and over until something changes. Useful if you need to keep trying until it works.
Map (In Progress): It takes a list and transforms every item in it. Changes the format or adds information to each item.
Fork/Join: It helps run multiple things at the same time instead of one after another. Also help save time by doing parallel work.
Parallel: This flow is quite similar to fork/join. It runs multiple tasks at once.
Error Handler: If something breaks, this flow catches it and does something else instead of crashing.
Wait for Approval: Pauses and waits for a user’s approval before moving forward. Good for important decisions.
Subflow (In progress): This flow calls another workflow from within your workflow and helps organize complex workflows into smaller pieces.

For the conditions themselves, ByteChef uses SpEL (Spring Expression Language) to create and manage them. You can do simple stuff like checking if something equals something, or more complex stuff like math. An example of condition expressions are: anthropic_1.urgent == true and email.from == 'boss@company.com'.

Trigger-Based Automation: This compliments workflows to take actions automatically based on certain events for example; taking new emails, form submissions, or scheduled times.
Data Transformation: Process and transform data as it moves between applications using built-in tools.
AI Integration: Leverage AI capabilities to make your workflows smarter and more intelligent.

Core Concepts Of ByteChef

Before building your first workflow, there are things you need to know about the basic pieces that makes up a workflow in ByteChef, let’s have a look at them in this section of the blog post:

Triggers: These are events that start your workflow; it’s the first thing after creating your workflow. An example of a trigger is when a new email arrives, a form being submitted, or a scheduled time is reached. Triggers are just like the "when" of your automation; it initiates automations.
Actions: Actions are similar to triggers, but these are tasks each component performs. An action could be sending a message, creating a file, analyzing text with AI, or updating a record. Actions are the specific task a component should perform. In ByteChef, the action you want depends on the component you’re working with. Some components even enable you to create custom actions.
Components: These are the building blocks, you can also refer to them as nodes. Each component connects to an external app (like OpenAI, Google Drive, or even Spotify) and lets you use that app within a workflow. Components have two parts: triggers and actions; to work with a component, you need to connect with the tool and configure properties.
Projects: Projects are like folders that hold your workflows - it’s a place where you can keep all your workflows. A project can hold as many workflows as you want.
Workflows: In ByteChef, workflows are the actual automation. A workflow is a series of steps and triggers that work together to automate something. It's the whole thing here, but the automation process itself.
Connections: ByteChef uses connections to work with services, they’re like authentication links to third-party applications, allowing ByteChef to interact with your accounts securely. With ByteChef, you can connect services once, and ByteChef remembers it so workflows can use them securely.

These are are the major concepts of ByteChef and all you need to know before building your first workflow in ByteChef - now, let’s put what we know to work!

Setting Up Your First Workflow: An Email and AI Triage Example

Now, let’s build an actual workflow. In this guide, we will be building an automated email system that checks incoming emails for urgency and routes them to different Slack channels through the flows and Anthropic AI for smart decision making. This workflow will showcase the capabilities of the key concepts you'll use in building basic and complex automations.

Step 1: Create a New Project

As mentioned earlier, a project in ByteChef is the folder where the workflow lives.

In the dashboard, head over to the Projects tab
Click on the New Project button at the top right corner.
Fill the necessary credentials such as its name, category, description, and tags.

Create project modal via ByteChef’s Dashboard.

Step 2: Create a New Workflow

When done creating your project, you can create a new workflow by clicking the + Workflow button in the project’s pane. When clicked, a modal should pop up requesting for the name and description of your workflow - this workflow will be saved in the project where it was created.

Create new workflow modal via ByteChef’s Dashboard.

Step 3: Set Up Your Trigger

After creating the workflow, the first step is to configure the trigger in the workflow. The configurable manual trigger is the first thing you see in the workflow, now the first thing to do is to change the trigger and make configurations.

Click the replace icon when you hover on the trigger button
Because of what we’ll be working on, search for and select "Gmail" when you want to replace the trigger
Choose the trigger type: "New Email"
Connect to Gmail’s OAuth.
Configure the trigger parameters:
- Format: Simple (for straightforward configuration)
- Topic Name: Based on what is configured in your Google Pub/Sub.

This setup means your workflow will be activated whenever a new email arrives.

Step 4: Add a new component

Now that emails are triggering your workflow, let's add the Anthropic component to determine if each email is urgent.

Click the + icon button to add a new task
Search for and select "Anthropic" (the AI provider)
Connect Anthropic using the your client ID (API Key)
Select "Ask" as the action type
Configure the AI task in the properties pane:
- Model: Choose any Anthropic models of your choice
- Format: Simple
- Response Format: Structured Data
- Max Models: The maximum number of token to generate in the chat completion.
- User Prompt: Create an instruction like:
```
Analyze this email and determine if it is urgent with "This is urgent" or "This is not urgent"
Email Subject: ${trigger_1.subject}
Email From: ${trigger_1.from}
Email Body: ${trigger_1.bodyPlain}
```

The ${trigger_1} syntax references data from your Gmail trigger.
In the Anthropic component, create a schema for the incoming conditional flow.
Add a new data pill and select Boolean as the pill type - give it a title.

This action sends each email to Claude for analysis, which will respond with a clear classification.

Step 5: Add Conditional Flow

With the urgency classified in the Anthropic component, now we need to route emails to different destinations based on the result.

Click the add icon in the workflow
Select "Condition" in the flows tab as the flow type
Configure the condition:
- Set "Raw Expression" to TRUE to enable custom logic
- Enter the expression: anthropic_1.isUrgent from what we created in the schema builder
- This checks if the AI response equals "URGENT".

This creates a branch point in your workflow. Depending on whether the condition is true or false, different actions will execute.

Step 6: Define the True Branch (Urgent Emails)

Here’s for emails classified as urgent:

Under the "True" section, add a new component
Search and select the "Slack" component
Choose "Send Channel Message" for the action
Configure:
- Give the component a name
- Channel: Select your "urgent-emails" channel (or create a channel where you want urgent emails to be delivered)
- Message: Create an informative message like:
```
URGENT EMAIL

*From:* ${trigger_1.from}
*Subject:* ${trigger_1.subject}
*Classification:* 
*Reason:* 

Requires immediate attention
```

Step 6: Define the False Branch (Non-Urgent Emails)

For emails classified as not urgent:

In the "Case False" section, add a new task
Select "Slack" and "Send Channel Message"
Configure:
- Give the component a name
- Channel: Select your "routine-emails" channel (or any other channel where you want unimportant messages to be delivered)
- Message: Create a message like:
```
New Email Received

*From:* ${trigger_1.from}
*Subject:* ${trigger_1.subject}
*Classification:* 
*Reason:* 
```

Now, your workflow should look like this:

Step 7: Test Your Workflow

Before activating your workflow:

Review the entire flow to ensure it makes sense
Click the "Test" button at the top-right corner of the workflow, to test the workflow with sample data
Check that the flow follows the correct path
Verify that messages are formatted correctly
When testing, you should see something like this in the Slack channel where you want non-urgent messages to be delivered:

New Email Received
From: sample from
Subject: sample subject
Classification:
Reason:

Step 8: Publish and Deploy

Once you're satisfied with the workflow:

Click the Publish button
Navigate to the Deployments tab in the dashboard
Click New Deployment
Select the project you want to deploy, the version, and add other necessary credentials
Ensure the connections are configured properly
Enable the workflow
Send a test urgent/non-urgent email to your configured email address
Monitor the configured Slack channels to verify emails are being routed correctly
Check the workflow logs to see execution history and identify any issues

If a message is urgent, it’ll drop in the expected channel in this format:

Additionally, to monitor the deployment, you can check your logs in the workflow executions section of the dashboard

Now that you have your first workflow running, there are ways to make the most of it. You can add error handling to catch failures, so if something breaks, your workflow knows what to do instead of just stopping.

To achieve this, you can try creating a loop to process multiple emails at once if you want to batch operations, or even instruct your LLM to make sentiment detection and content categorization to make your workflow even smarter.

Conclusion

ByteChef enables you to automate routine tasks and create smart workflows that save time and reduce errors. Your first workflow is just the beginning. You can create more workflows to be better with automation. In ByteChef, the best way to understand the platform better is by playing around with it - as you become more comfortable with the platform, you'll discover countless ways to streamline your work and work with your favourite applications.

The best way to successful automation is starting simple, testing thoroughly, and gradually building more complex workflows as your confidence and needs grow.

Thanks for taking the time to learn about workflow automation with ByteChef in this blog post. Please, do well to use ByteChef and join the community, can’t wait to have you join the community.

Lastly, if you ever have any issues navigating ByteChef, refer to the documentation.

Happy automating! 🛠️

Incident Event Pipelines for Real-Time Notifications with Windmill and Checkly

Opemipo Disu — Fri, 17 Oct 2025 13:10:38 +0000

When applications and APIs have a downtime, customers are usually affected as operations remain broken. However, engineers do their job by fixing the broken operation - but a big question often comes up in engineering teams is how to tell users what exactly is happening without spamming or sending duplicate messages. That's where building a well-structured incident notification pipeline comes in.

In this article, we'll explore how to build an event pipeline for real-time notifications using Windmill. There are a bunch of monitoring tools like Sentry, New Relic, and even Grafana, for generating raw incidents but turning alerts into clear and reliable alerts for users means you need to orchestrate the alerts, clean them up, and make sure they always gets delivered.

We will show how to use Windmill to gather incident events from a monitoring tool, apply routing rules, and deliver notifications through various channels. With this piece, you'll know how to orchestrate a production-ready pattern for ensuring that updates are sent to users without duplications or delay.

This is not an alert from Windmill, please. 😂

System Architecture: From Incidents to Alerts

Now that we’ve set the context and had a little laugh with that caption 😅, let’s get straight to the point and look at how this whole system fits together. The goal of this workflow is simple: when something breaks within an application, users should be able to get real-time alerts only once. To make this work, we will integrate a monitoring tool with Windmill for orchestration and notification delivery. Now, let's have a deeper look at the major components of this workflow:

Monitoring Tool: While there are many tools such as Grafana, Sentry, and Prometheus, we will be using Checkly to detect when something goes wrong within an application. These tools can fire a webhook or alert when things break.
Windmill: Windmill sits in the middle of the workflow as the orchestrator as it helps ingest incident events from the monitoring tool (Checkly, in this context), and normalize them into a consistent schema so all the alerts are in the right destination. Windmill will also decide the destination of each type of alerts (whether they're critical, warnings, or minor). Lastly, we'll be ensuring there's a high level of reliability and deduplication with alerts.
Notification Channels: Once the orchestration with Windmill is done, it can deliver notifications through various channels like Slack, email, SMS, or webhook endpoints to other services.
Feedback Loop: Some alerts might not appear at the expected destination the first time. Windmill allows you to implement retry flows to reattempt delivery or escalate the issue to another channel.

Gathering Events From Checkly in Windmill

The first step of this workflow is collecting incident events from the monitoring tool. Since we're using Checkly as our monitoring tool, we'll integrate Checkly with Windmill for orchestration and notification delivery whenever an error or downtime occurs within an application.

Step 1: Create a Webhook in Windmill

Windmill lets you expose a flow as a webhook, which Checkly can call whenever something breaks. We need to work with Windmill for the webhook trigger configuration as this we'll need the incident pipeline for Checkly's webhook configuration.

Create a Windmill account and log into your Windmill workspace via Windmill Cloud or the self-hosted versions.
In your Windmill dashboard, create a new Flow from the Home tab.
In the flow editor, give the flow a name and add a trigger.
Select the Webhook Trigger option.
- This automatically generates an endpoint that accepts POST requests.
Next, inspect the incoming data and add a step to log the payload (so you can see what you want Checkly to send).
Add a preprocessor module to handle incoming webhook events (click the "+" button after the trigger node) - once this is done, select TypeScript as the language.

In the preprocessor editor, you can access the webhook’s payload. In this case, we will be replacing the template with the following code to process the data to ensure that the webhook and payload are working properly:

export async function preprocessor(event: {
  kind: "webhook";
  body: any;
  headers: Record<string, string>;
}) {
  const payload = event.body || {};

  return {
    check_name: payload.check_name,
    status: payload.status,
    error: payload.error,
    region: payload.region,
    run_id: payload.run_id,
    timestamp: payload.timestamp || new Date().toISOString()
  };
}

The script above receives JSON data from Checkly, logs them and returns a confirmation message. If you test the script, you should receive this.

export async function preprocessor(event: {
  kind: "webhook";
  body: any;
  headers: Record<string, string>;
}) {
  const payload = event.body || {};

  return {
    check_name: payload.check_name,
    status: payload.status,
    error: payload.error,
    region: payload.region,
    run_id: payload.run_id,
    timestamp: payload.timestamp || new Date().toISOString()
  };
}

The script above receives JSON data from Checkly, logs them and returns a confirmation message. If you test the script, you should receive this.

Copy your Windmill webhook endpoint. Now, you have to reopen the Trigger node, then you’ll see a URL like this:

https://app.windmill.dev/api/w/[workspace]/jobs/run_wait_result/[flow_path]

Step 2: Configure Checkly to Send Incidents

Create a Checkly account and log into Checkly’s dashboard.
Head over to the Alerts Channels tab.
Click the Add more channels button and select the Webhook option.
Give the Webhook instance a name and paste the Windmill webhook URL you created earlier (be sure to use the POST method).
Save the webhook instance on Checkly and you should get a JSON payload with different fields. If anything fails, Windmill will receive this payload instantly when you start capturing the issues with your monitored services.

Orchestrating Incidents in Windmill

Raw incidents aren’t enough, they’re often noisy and inconsistent and that’s why there’s a need to clean and route them properly. In Windmill’s environment, workflows are like blocks for routing, and providing contexts to alerts. Once Checkly pushes an incident payload, Windmill takes over to make sense of it.

A basic orchestration pattern includes the following components:

Normalization: Convert Checkly’s raw JSON payload format into a consistent schema. Each monitoring tool has its own format of displaying schemas. Normalization in this context ensures every incident follows a predictable format like this:

{
  "service": "coderoflagos-check",
  "severity": "critical",
  "message": "Timeout on /register route",
  "region": "eu-west-1",
  "incident_id": "run_8472"
}

This approach makes it easier to work with Slack notifications to process alerts without working with too much logic.

Deduplication: Incidents can be disturbing. For example, if the same check fails 10 times within a minute, you don't want users to be sent 10 alerts on that. In Windmill, you can store or reference previous incidents in a temporary key-value store or even cache and check whether an identical incident already exists before sending another one.
Routing Rules: Not all incidents are the same; there are different classes they fall into. While there are different classes, you can build conditional logic in your Windmill flow to route alerts based on severity, for example:
- Critical: Send immediately via SMS and urgent channels.
- Warning: Forward via email or Slack only.
- Info: Log silently.
This approach ensures developers or end-users only get the right level of attention when something occurs.
Retries and Recovery: Delivery sometimes fails. For example, a notification service might return a network timeout. Windmill allows you to implement retry flows to reattempt delivery or escalate the issue to another channel.

Example normalization step in Windmill

Once your flow receives a payload from Checkly, the next step is to normalize it into your schema and prepare it for notification delivery. Here's how to achieve this:

After your preprocessor, add a new code step that handles normalization:

Click the "+" button after your preprocessor.
Select Code option and choose Python as the language.
Give the step a unique name.
After, you can apply the following code in the code step:

def main(flow_input: dict) -> dict:
    """
    Normalize Checkly data into a consistent incident schema
    """
    # Normalize the incident data
    normalized = {
        "service": flow_input.get("check_name", "Unknown Service"),
        "severity": "critical" if flow_input.get("status") == "failed" else "info",
        "message": flow_input.get("error", "Check completed"),
        "region": flow_input.get("region", "unknown"),
        "incident_id": flow_input.get("run_id"),
        "timestamp": flow_input.get("timestamp"),
        "source": "checkly"
    }

    print(f"Normalized incident: {normalized}")
    return normalized

This step takes the preprocessed Checkly data and normalizes it into a consistent format that can be used by downstream notification steps.

Delivering Notifications

After normalization, you can add steps to deliver notifications through various channels. Here's how Windmill transforms your Checkly incidents into actionable notifications:

Step 3: Add Notification Delivery Steps

You can add multiple notification steps based on your needs. Each step receives the normalized incident data and delivers it through a specific channel:

Slack Notification Step:

Add another code step after your normalization step
Choose Python as the language
Add slack_webhook_url as a parameter
Here’s an example code snippet of what you should have in the code step trigger:

import requests

def main(incident: dict, slack_webhook_url: str) -> dict:
    """
    Send incident notification to Slack
    """
    severity_emoji = "🚨" if incident["severity"] == "critical" else "⚠️"

    slack_message = {
        "text": f"{severity_emoji} Incident Alert",
        "blocks": [
            {
                "type": "section",
                "text": {
                    "type": "mrkdwn",
                    "text": f"*{incident['service']}* is experiencing issues\n*Error:* {incident['message']}\n*Severity:* {incident['severity']}\n*Region:* {incident['region']}\n*Incident ID:* {incident['incident_id']}"
                }
            }
        ]
    }

    response = requests.post(slack_webhook_url, json=slack_message)

    return {
        "status": "success" if response.status_code == 200 else "error",
        "channel": "slack",
        "incident_id": incident["incident_id"],
        "message_sent": f"Notified team about {incident['service']} incident"
    }

This approach ensures that even non-critical incidents still reach your engineering team without repeating emails

Conclusion

Windmill makes it easy to send alerts from Checkly to your team or product users. You can use it to recieve alerts, clean data, and send alerts via Slack, email, or any other destination you prefer. Everything works automatically, so your team can focus on fixing issues instead of managing notifications manually - however, note that with this approach, there are still some efforts you can apply to make things work more efficently.

To get the best results, try using clear alert formats and test your flow often to make sure messages are sent correctly. You can also explore other Windmill features like custom logic and extra integrations to make your system stronger.

Before you go… 😂

Thanks for reading! If this article helped you, check out Windmill’s docs or join Windmill’s community to learn more. Sharing your feedback or building something cool with Windmill helps everyone in the developer community grow together.

[Boost]

Opemipo Disu — Mon, 13 Oct 2025 13:36:23 +0000

Opemipo Disu

Oct 13 '25

Incident Event Pipelines for Real-Time Notifications with Windmill and Checkly

#webdev #programming #ai #tutorial

7 min read

Amazon Bedrock and Retrieval-Augmented Generation (RAG): Building Smarter AI Systems with Context-Aware Responses

Opemipo Disu — Wed, 09 Apr 2025 12:25:38 +0000

In Part 1 of this series, we delved into Amazon Bedrock and how DevOps engineers and developers could build their first generative AI applications and deploy with AWS Lambda. In the last blog post, we also focused on use cases that could be built with Amazon Bedrock even best practices for working with Amazon Bedrock.

Now, we’ll take a step further by showcasing how to address a very important challenge in AI; providing context-aware responses for generating quality and relevant responses.

In this tutorial, you will learn how Amazon Bedrock works with RAG, its structure, and get a practical guide on integrating Amazon Bedrock and RAGs.

What is Retrieval Augmented Generation?

Retrieval Augmented Generation (RAG) is a technique used to improve the quality of responses from LLMs by adding relevant information from external sources. Normally, when working with a traditional LLM, you get responses based on what they’re trained to give back, but with RAG, you get responses from real-time data and more accurate information. Working with standard models can be static, whereas working with RAGs is super dynamic; that’s a major difference.

RAG vs. Standard LLMs

In this section of the tutorial, we will look at some of the differences in features between Standard LLMs and RAG-Enabled LLMs.

Feature	Standard LLM	RAG-Enabled LLM
Knowledge Source	Static / Fine-tuned data	Dynamic / Real-time data
False Information Risk	High (inaccurate or outdated)	Low
Use of Private Data	Limited	Large-scale
Cost Efficiency	Moderate	More efficient with caching

In the table above, you'll see that working with traditional LLMs can be very static, fixed, and inaccurate because they operate based on how humans fine-tune the model. However, RAG-Enabled LLMs work directly with data retrieved from external sources and real-time data.

Use-Cases of RAGs

Chatbots: This is probably the most known use-case for RAGs. With RAGs, you get more accurate and current information as responses for better customer interactions.
Internal Knowledge Search: RAG-enabled models enable users to easily access and utilize articles, guides, documentation, and even other public resources without any manual intervention or worrying if the information generated is relevant.
Support Automation: RAGs could also improve incident resolution by pulling from logs and past tickets. It helps provide quicker and accurate answers for resolving issues faster.
Financial Services: RAG-enabled models can also generate stats reports in different formats based on real-time market data.

How Does Retrieval Augmented Generation Work?

RAG improves AI responses by using information retrieval with language models. For example; when a user submits a query, the system uses an existing knowledge base like S3, Elasticsearch, Pinecone, or OpenSearch to find relevant data. This data is added to the user’s query and sent to the AI model to make the response more accurate.

Here’s an architectural diagram of how RAG works:

Benefits of Using RAG-Enabled LLMs

Lower Risk of Inaccurate Information: Using RAG-Enabled LLMs generates responses based on reliable sources rather than making assumptions. Unlike using standard LLMs, where you have to provide models with data that might be inaccurate.
Improved Accuracy: Using them also ensures AI responses are more accurate and up-to-date by retrieving information from trusted external sources instead of relying on fine-tuned data. This reduces the risk of giving users incorrect information for responses, thereby improving the accuracy of generated content.
Cost Efficiency: They also help save money and reduce API calls by using existing data sources instead of making unnecessary requests.
Security & Compliance: Using RAG-Enabled LLMs even helps provide data privacy by retrieving information only from authorized and secure sources.

AWS Bedrock + RAG: The Perfect Match

AWS Bedrock provides a solid base for RAG-enabled apps by offering various foundation models with built-in tools for storing and retrieving custom data.

Its serverless setup ensures that there is security and compliance while integrating with services like Amazon OpenSearch for search-based retrieval, Amazon S3 for storage, AWS RDS for relational databases, and Amazon Bedrock Knowledge Bases for vector-based retrieval. This setup allows developers to create scalable AI applications easily.

Before delving into implementing RAG into Amazon Bedrock, lets have a look at Amazon Bedrock’s workflow:

How to Implement RAG with AWS Bedrock

Step 1: Store Your Custom Data

Since we will be using Amazon S3 to store our data, follow these steps:

Head over to Amazon S3.
Create an Amazon S3 Bucket to store your data and make necessary configurations. Be sure to enable Bucket Versioning.
Upload to documents to your Amazon S3 bucket.

Step 2: Choose an Embedding Model

Choose any model to work with; your decision on selecting a model should be based on whether it fits the project you're working on. Refer to this guide to find a list of models you can work with.

Step 3: Create a Knowledge Base

Navigate to Amazon Bedrock’s Console
In the side navigation by the left, select "Knowledge bases".
Click "Create knowledge base" and select the “Knowledge Base with Vector Store” option.
Provide the knowledge base details
When providing the knowledge base details, choose the S3 URI location as data source.

Finally, select your embedding model.
Configure the vector store (Amazon OpenSearch Serverless will be used by default).

Step 4: Chunking (Data Preparation):

Head over to the Knowledge Base in the Amazon Bedrock console.
Select Your Knowledge Base From the Knowledge Bases section, choose the knowledge base you want to work with.
Add or Edit a Data Source If you haven't already, add a new data source pointing to your S3 bucket. If you have an existing S3 data source, select it for editing.
Configure Chunking Strategy In the data source settings, look for the "Chunking Configuration" section. Here, you'll find options to set your chunking strategy:
- Fixed-size chunking.
- Hierarchical chunking.
- Semantic chunking.
- No chunking (treats each file as one chunk).

Here’s where to configure that:

Choose and Configure Your Chunking Strategy Select the strategy that fits your data and use case.
- For Fixed-size: Specify the number of tokens per chunk and overlap percentage.
- For Hierarchical: Also define parent and child chunk sizes and overlap.
- For Semantic: Set the maximum tokens, buffer size, and breakpoint percentile threshold.
Review and Save Changes After configuring your chunking strategy, review your settings and save the changes to your data source.

Step 5: Test and Query the Knowledge Base

Before testing, ensure the data is synced; syncing means fetching the data from S3, chunking it, embedding it, and storing it in the vector database.
In the knowledge base console, hit the Test button.
When the panel pops out, enter a question related to your uploaded documents.
Click Run to get AI-generated responses.

Step 6: Verify the Retrieval Process

If Bedrock correctly retrieves relevant data, your RAG setup is working! 🎉

Best Practices & Tips for RAG Pipelines on AWS Bedrock

Optimize Context Window: It's important to keep the context clear and focused on what's needed for the prompt. Too much information can confuse the model, so a great thing to do will be always try to provide only necessary data to get accurate responses.
Balance Cost vs. Accuracy: Retrieving more data also helps improve accuracy, but it can also increase costs. Find a balance by fetching only the necessary data to reduce costs while maintaining the same quality.
Fine-Tune Retrieval Thresholds: Set limits for retrieval relevance to make sure you're only getting the most useful data. This helps prevent overwhelming the model with unnecessary information and keeps responses clear.
Use Caching: Cache frequently used data to speed things up and reduce unnecessary API calls. This makes your pipeline more efficient and reduces costs, especially for common queries.
Secure Data Sources: Protect your data by using IAM policies and encryption for sensitive sources. This practice ensures that only authorized users can access your data, keeping everything safe and compliant.

Best Use Cases for RAG

DevOps & Observability: You can use RAG for retrieving logs and metrics (in real-time) for automated incident resolution.
Product Search & Recommendations: You can use RAG to refine personalized product recommendations.
Enterprise Document QA: You can also use RAG for employees to query company documents with chatbots and AI agents.
E-Commerce: You can also use RAGs to fetch dynamic product descriptions and search results.

RAG vs. Fine-Tuning Decision Framework

Use Case	Best Approach
Static Knowledge	Fine-Tuning
Dynamic Data	RAG
Cost-Sensitive	RAG (less training required)
Data Privacy	RAG (retrieves private data)

What’s Next: RAG-Enabled AI Agents in Production

Now, the next step for you is to create AI agents that automate workflows using Amazon Bedrock and integrate with RAG. To deploy your application, you can use AWS services like ECS, Lambda, or other Bedrock-managed services.

In Part 3 of this series, we’ll explore how to scale RAG architectures in production, improve performance, and ensure seamless integrations.

Conclusion

RAG with AWS Bedrock makes models smarter by adding real-world context to its responses. That being said you’ll get more accurate answers, and reduce costs since you’re only pulling in the data you actually need. Anther thing is that AWS handles the backend, so you don’t have to stress about infrastructure.

Before you go… 🥹

Thank you for taking the time to learn about integrating RAGs with AWS Bedrock. If you found this article helpful, please consider supporting Microtica by creating an account and joining the community. Your support helps us keep improving and offering valuable resources like this, for the developer community!

10 Internal Developer Platforms to Improve Your Developer Workflow 🚀

Opemipo Disu — Fri, 28 Mar 2025 12:34:24 +0000

Internal Developer Platforms (IDPs) are essential tools in the software development process because they deliver the software faster and more efficiently. This means that it boosts the whole process's productivity.

The need for these platforms is increasing because companies tend to find better solutions that will speed up software delivery. As businesses grow, the complexity of the development process is increasing too. That’s why IDPs can help to solve the challenges that a company may face.

This ultimate guide will help you choose the best IDPs including their features, benefits, and functionalities. Understanding these platforms better will transform software development within a business.

What Is the Purpose of an Internal Developer Platform?

Internal developer platforms (IDPs) are tools that help businesses streamline their development procedures. Compared with the traditional approach, IDPs provide a solution that simplifies processes, automates repetitive work, and allows developers to concentrate on what they do best - write code.

These platforms ease the work of the developers, which means they can focus on their main job rather than manage the IT infrastructure. Tasks including configuration, provision, and deployment are all part of the self-services that IDPs offer.

The main goal of an IDP is to increase developers' productivity. By providing enhanced technologies, developers are able to organize their time and focus on producing creative solutions.

Because platform engineering creates an environment that helps both the business and the customers, developers can save time and effort while still providing value to clients. Using all these necessary tools ensures that your development procedures as well as the outcomes will be improved.

Let’s take a closer look at the best platforms to use within your development workflow:

1. Microtica

Microtica is an AI-powered platform that offers better cloud-native app deployment and management. It automates lots of activities, such as deployment pipelines, monitoring, and cost optimization, while providing ready templates for rapid implementation.

In order to improve efficiency, save cloud expenses, and increase monitoring visibility, the platform offers developers the tools they need to manage apps on their cloud accounts. Microtica is suitable for all-size businesses because it also provides insights for operational and cost-saving improvements.

⭐️ Try Microtica For Free ⭐️

2. Qovery

Qovery stands out as a powerful DevOps automation platform that aims to streamline the development process. It provides a comprehensive solution for provisioning, managing repetitive tasks, and maintaining a secure and compliant infrastructure to improve user experience and cost efficiency.

Qovery streamlines deployment workflows while ensuring scalability, and compliance. It reduces the need for manual DevOps tasks by offering self-service tools that ensure the developers will manage and deploy cloud infrastructure efficiently.

⭐️ Try Qovery ⭐️

3. OpsLevel

With OpsLevel, developers can manage all of their tools, services, and systems from a single location using OpsLevel's standardized interface. As an internal developer portal, it offers automated services, helps to speed up the delivery of software quality, and enhances the visibility of the context.

OpsLevel enables businesses to efficiently manage complex structures, while at the same time maintaining outstanding service with its user-friendly interface and powerful monitoring features.

⭐️ Try OpsLevel ⭐️

4. Coherence

Coherence is a platform that helps companies build a strong environment by testing, developing, and deploying web apps, and managing the full SDLC. It enables users to choose the features of the dataset, ensuring accuracy.

Coherence is a helpful IDP because allows development tasks to be delivered faster and with greater accuracy than with conventional techniques.

⭐️ Try Coherence ⭐️

5. Humanitec

Humanitec provides a platform that automates and standardizes infrastructure management for developers. It improves DevOps workflow by enhancing the collaboration between the operations and developers teams to achieve faster and better delivery.

It also focuses on self-service tools that improve deployment automation, and environment management while cutting time and costs.

⭐️ Try Humanitec ⭐️

6. Mia Platform

Mia Platform provides a variety of products for building digital platforms. The platform is associated with several international technological standards and focuses mostly on encouraging the use of Cloud Native and Open Source applications.

Among its services is the main product, the Mia-Platform Console, which is a platform that improves developer experience, accelerates the creation of microservices architectures, and streamlines development procedures.

⭐️ Try Mia Platform ⭐️

7. Appvia

Appvia offers solutions that simplify and secure public cloud distribution. By offering solutions that are safe, affordable, and scalable, they enable businesses to proactively pursue cloud computing.

Among its many features are infrastructure management, automated deployment, and integration with leading cloud providers.

⭐️ Try Appvia ⭐️

8. Portainer

As an open-source tool, Portainer makes it easier to deploy, monitor, and secure systems using Docker, Kubernetes, Swarm, and Podman. Everyone can use it, from small companies to big enterprises, by offering user-friendly interface automation, and developer self-service.

The main goal of Portainer is to streamline operations, enforce best practices, and accelerate container adoption.

⭐️ Try Portainer ⭐️

9. WarpBuild

WarpBuild provides fast, cost-effective GitHub action runners that improve CI/CD performance. The main goal is to offer cloud-based deployment workflow automation and allow developers to manually handle activities like configuration and deployment.

WarpBuild is designed for developers to accelerate deployments while reducing costs, with features such as automated testing and integration with any cloud provider.

⭐️ Try WarpBuild ⭐️

10. Nullstone

Nullstone helps developers faster deploy secure, full-stack applications on their own cloud infrastructure. It supports containers with self-service deployments, automated tools, and strong monitoring.

Nullstone integrates with Terraform, Helm, and third-party services like Datadog and New Relic, providing flexibility and security while enabling faster software delivery, and better software development efficiency.

⭐️ Try Nullstone ⭐️

Things to Consider While Choosing the Best IDP

Choosing the right platform for your business can be challenging due to many factors, such as the best features, procedures, and services they offer. By comparing their characteristics, and what they offer, you can easily find the best one that fits your business needs.

In addition, you should consider several factors, including:

Ease of Use: An effective IDP should be easy to use and provide a smooth experience for developers. Find platforms that have a user-friendly interface, and self-service capabilities that will boost productivity.
Scalability: The IDP should support scalable infrastructure, especially if your team needs to deploy applications across multiple environments or clouds. A flexible platform allows teams to manage complex infrastructures that can easily scale and adapt.
Security: Analyze the security characteristics of each platform. The platform should provide robust compliance features to help teams manage risks, follow regulations, and ensure that only authorized people have access to sensitive resources.
Integration: Consider how well each platform integrates. A good platform integrates with tools, new technologies, and infrastructure. The integration speeds up the software delivery process and improves collaboration.
Cost: It’s essential to evaluate the general and additional costs such as support, training, and other requirements. Each platform offers different features that come with different costs. Choose the one that best fits your company’s budget.
Suitability: All platforms offer different features that may be better for certain applications and processes. Consider platforms that better respond to your requirements and solve your business needs.
Support: When choosing an IDP a main consideration is the quality of customer support they offer. The platform should have a responsive support team, providing 24/7 support, and comprehensive documentation. This will ensure your team will get timely assistance when facing challenges to reduce downtime.

All the factors listed above are essential when choosing the best IDP for your business. By taking into account the cost, ease of use, security scalability, integration, sustainability, and support, you will find the best IDP that will fill your business requirements and bring greater productivity.

Conclusion

Finding the best internal developer platform involves several factors to consider. Each of these platforms provides different features and benefits that meet certain organizational requirements. By carefully evaluating each platform's advantages, disadvantages, and special features, your company may increase developer productivity, optimize processes, and maintain better security and compliance.

Amazon Bedrock: A Practical Guide for Developers and DevOps Engineers

Opemipo Disu — Mon, 24 Mar 2025 13:05:12 +0000

Once upon a time, building AI applications required deep experience with traditional technologies and some Machine Learning expertise. While that was the norm, developers had to configure models to their needs, provide GPUs, and manually optimize performance, which required a lot of effort and costs.

While that approach seemed difficult, the AWS team built Amazon Bedrock, a tool that allows developers to easily create their AI applications through an API or the AWS Management Console using its embedded foundation models. Amazon Bedrock enables developers to build generative AI applications without the stress of directly managing the underlying stack.

In this article, you’ll learn everything about Amazon Bedrock, the prerequisites of using Amazon Bedrock, how to get started with Amazon Bedrock, best practices for working with Amazon Bedrock, and even the core concepts of Amazon Bedrock. Other than that, you’ll also see some code samples of how you can work with AWS’s Bedrock API. So, this article will serve as an A-Z guide for people who are interested in using Bedrock to build their generative AI applications.

Please, support Microtica 😅 🙏

Before moving on, I’d love it if you could support our work at Microtica joining our community! ⭐️

⭐️ Join Microtica’s Discord Community ⭐️

What is Amazon Bedrock?

Amazon Bedrock is a service that lets DevOps engineers and teams build gen AI applications. Instead of building or fine-tuning models manually, Amazon Bedrock uses foundational models from AI infrastructure providers to provide a ready-made API for developers to use easily. This approach removes the complexity that comes with building generative applications and working with underlying stacks.

Benefits of Amazon Bedrock

Before getting in hands with Amazon Bedrock, I just thought it would be nice to share some benefits of Amazon Bedrock and include examples of how these benefits have a positive impact on your development workflow.

Quicker Development: Compared to working manually, where you always have to work with models and fine-tune them, AWS lets you work with a single API. With this approach, you don’t have much to focus on. This approach saves a lot of time as it requires less effort than directly working with models.
- Example: My colleague made an AI Assistant using Amazon Bedrock's text generation models without having to handle any ML models directly, which saved him time. He found this method quicker because he could add AI features in just a few days with an API call instead of spending months or weeks.

Scalability: Amazon Bedrock is built on AWS’s Cloud Infrastructure and uses models from various companies, including AI21 Labs, Anthropic, Cohere, DeepSeek, Luma, Meta, Mistral AI, and Stability AI. This enables teams to scale their applications easily and under heavy workloads, Bedrock ensures excellent application performance without requiring manual intervention.
- Example: An e-commerce service using Amazon Bedrock for product recommendations can easily scale resources during shopping seasons without compromising performance or experiencing downtime.
Integration with AWS Ecosystem: As Amazon Bedrock is an AWS product, it seamlessly integrates with Amazon SageMaker, Lambda, and S3 for building, deploying, and managing applications.
- Example: A bank using Amazon Bedrock for fraud detection can create automated workflows. For instance, AWS Lambda can identify suspicious transactions, save the reports in S3, and use SageMaker to check patterns.
Cost-Effectiveness: Amazon Bedrock has flexible pricing, so you only pay for what you use. Instead of spending a lot on expensive servers and models, you can use any of Bedrock’s models that you think will help save costs while still getting powerful AI features. You can take a look at this page for Amazon Bedrock's pricing models.
- Example: One of my colleagues automated blog posts with Amazon Bedrock and only paid for the API requests she used, saving money on monitoring and fine-tuning AI models.

Getting Started with Amazon Bedrock 🚀

Now, it’s time to prepare to get our hands dirty. In this section, we will look into doing the real work and the things you should have before getting started. Even though Amazon Bedrock can be used to accomplish many tasks, this article is focused only on building generative AI applications easily with the AWS Management Console.

Prerequisites For Using Amazon Bedrock

Before getting started with Amazon Bedrock, here are some things you need to have ready:

Basic Python Knowledge.
An AWS Account: This is primary: to get started, you need to create an AWS account.
AWS Management Console: You need the console to interact with models if you don’t want to write code. Alternatively, you can use:
- AWS CLI: You can use the CLI to create AWS CLI profiles using the API. For instructions on how to use this option, refer to this documentation. This option requires some basic Python knowledge.
IAM Permissions: You also need to assign the required IAM roles needed for Bedrock.

In this article, we will be using the AWS Management Console option for operations. You can use the CLI option to go a bit hands-on.

Basic AI/ML Concepts

Even though Amazon Bedrock helps with removing the complexities that come with building AI applications, a basic understanding of AI and ML is helpful because, even when using Amazon Bedrock, there are things you might encounter, such as:

Foundational Models (FMs): These are the pre-built AI models that Amazon Bedrock provides for operations in generative applications. You might wonder if AWS owns the entire model, but some are from different companies.
Prompt Engineering: This is the process of creating and improving input prompts to help AI models produce accurate and great responses. Good prompt engineering improves the model's understanding and ensures it aligns with the output.
Model fine-tuning: With Amazon Bedrock, it’s possible to fine-tune models to your needs. You can always configure models to fit what you want; the approach for doing this is different from the manual approach.

Core Concepts of Amazon Bedrock

Now, let’s take a look at some key concepts of Amazon Bedrock - by having a glance at them, you’ll have a deeper understanding of how Amazon Bedrock works and how to get the best out of it

Understanding Foundation Models

Let’s take a look at some foundation models that Amazon Bedrock uses and things to consider before using them.

To find the list of models you could work with, their capabilities, and their availability in your region, refer to this guide. In that guide, you’ll see everything about the models and the types of outputs they generate—for example, image, text, or code.

Here are some things you should consider before using any of the models:

Use Case: You should know if the model aligns with your application’s needs. For example, if you’re building a chatbot that generates text for responses, you need to work with one of the models that support text for their outputs.
Performance vs. Cost: Now, this is where the saying "quality over quantity" really matters. You need to think about two things: performance and cost. Some models work quickly but are usually expensive. If you want a model that fits your budget, you might have to find a balance between how well it performs and how much it costs.
Customization: Amazon Bedrock lets you adjust models for some uses. Depending on your needs, you might want a model that can be customized to fit your project.

Amazon Bedrock API

Now, let's explore Amazon Bedrock's API and SDK and learn how to use them. First, we'll have a look at the API and learn how to work with the foundational models.

Overview

Apart from interacting with the service, Amazon Bedrock API allows you to do the following:

Work with the foundation models to generate text, create images, generate code
Adjust the model’s behaviour with settings you can change.
Get information about the model, including its ARN and ID.

Amazon Bedrock APIs use AWS's normal authentication and authorization methods, and that requires IAM roles and permissions for security.

Authentication & Access Control

To use the Bedrock API, you need to install the latest version of AWS CLI and log in with AWS IAM credentials. Make sure your IAM user or role has the required permissions, too.:

{
  "Version": "2012-10-17",
  "Statement": [
      {
          "Sid": "MarketplaceBedrock",
          "Effect": "Allow",
          "Action": [
              "aws-marketplace:ViewSubscriptions",
              "aws-marketplace:Unsubscribe",
              "aws-marketplace:Subscribe"
          ],
          "Resource": "*"
      }
  ]
}

This policy allows you to use the API to run models. To follow up with working with Amazon Bedrock’s APIs, you can refer to and read these guides:

Amazon Bedrock API Reference: In this documentation, you’ll find the service endpoints you’ll likely work with.
Getting Started With Amazon Bedrock API: This documentation will walk you through everything you need to know about Amazon Bedrock’s API—from its installation requirements to the How-tos; it’s a more detailed guide for setup.

AWS SDK Integration

AWS provides SDKs to integrate with your favourite programming languages, such as Python, Java, Go, JavaScript, Rust, etc. Now, let’s have a look at some examples of how they work with different languages.

Python (Boto3):

    import logging
    import json
    import boto3

    from botocore.exceptions import ClientError

    logging.basicConfig(level=logging.INFO)
    logger = logging.getLogger(__name__)

    def list_foundation_models(bedrock_client):

        try:
            response = bedrock_client.list_foundation_models()
            models = response["modelSummaries"]
            logger.info("Got %s foundation models.", len(models))
            return models

        except ClientError:
            logger.error("Couldn't list foundation models.")
            raise

    def main():

        bedrock_client = boto3.client(service_name="bedrock")

        fm_models = list_foundation_models(bedrock_client)
        for model in fm_models:
            print(f"Model: {model['modelName']}")
            print(json.dumps(model, indent=2))
            print("---------------------------\n")

        logger.info("Done.")

    if __name__ == "__main__":
        main()

That’s a clear example of how to list the available Amazon Bedrock models with Python (Boto3). To learn more about how to the Python SDK works, read this guide.

JavaScript Example (AWS SDK for JavaScript v3):

import { fileURLToPath } from "node:url";

import {
          BedrockClient,
          ListFoundationModelsCommand,
        } from "@aws-sdk/client-bedrock";

        const REGION = "us-east-1";
        const client = new BedrockClient({ region: REGION });

        export const main = async () => {
          const command = new ListFoundationModelsCommand({});

          const response = await client.send(command);
          const models = response.modelSummaries;

          console.log("Listing the available Bedrock foundation models:");

          for (const model of models) {
            console.log("=".repeat(42));
            console.log(` Model: ${model.modelId}`);
            console.log("-".repeat(42));
            console.log(` Name: ${model.modelName}`);
            console.log(` Provider: ${model.providerName}`);
            console.log(` Model ARN: ${model.modelArn}`);
            console.log(` Input modalities: ${model.inputModalities}`);
            console.log(` Output modalities: ${model.outputModalities}`);
            console.log(` Supported customizations: ${model.customizationsSupported}`);
            console.log(` Supported inference types: ${model.inferenceTypesSupported}`);
            console.log(` Lifecycle status: ${model.modelLifecycle.status}`);
            console.log(`${"=".repeat(42)}\n`);
          }

          const active = models.filter(
            (m) => m.modelLifecycle.status === "ACTIVE",
          ).length;
          const legacy = models.filter(
            (m) => m.modelLifecycle.status === "LEGACY",
          ).length;

          console.log(
            `There are ${active} active and ${legacy} legacy foundation models in ${REGION}.`,
          );

          return response;
        };

        if (process.argv[1] === fileURLToPath(import.meta.url)) {
          await main();
        }

The code snippet above also shows the listing of the available Bedrock foundation models. To learn more about how to use the JavaScript SDK, read this guide.

There are code samples that showcase how to integrate Bedrock SDKs into your favorite programming languages. You can find them in this guide.

Understanding Amazon Bedrock API Responses

Now, lets have a look at the main API operations that Amazon Bedrock provides for model prediction:

InvokeModel – Sends one prompt and gets a response.
Converse – Allows ongoing conversations by including previous messages.

Additionally, Amazon Bedrock supports streaming responses with InvokeModelWithResponseStream and ConverseStream.

To see the type of responses you’ll get when you submit a single prompt with InvokeModel and Converse, check the following guides:

Converse API: This guide showcases how to use Amazon Bedrock using the Converse API. It also includes how you can make a request with an Amazon Bedrock runtime endpoint and examples of the response you’ll get with either Converse or ConverseStream.
InvokeModel: This guide explains how to use the InvokeModel operation in Amazon Bedrock. It also covers how to send requests to foundation models, set parameters for the best results, and manage responses.

Building A Conversational AI Application With Amazon Bedrock

Now, let's start building our first application in Amazon Bedrock using the AWS Management Console. For this first project, we'll create a conversational AI assistant that works only with text.

Step 1: Get started with Amazon Bedrock in the AWS Management Console

Firstly, sign into the AWS Management Console from the main AWS sign-in URL. When, you’re signed in, you’ll be redirected to the Dashboard. In the dashboard, select the Amazon Bedrock option (search for "Bedrock" in the AWS search bar).

After selecting Amazon Bedrock, head over to the Model Access tab and ensure you have access to any Amazon Titan text generation models by requesting access.

After selecting the model you'd like to work with, hit the Next button. Afterwards, you'll be redirected to a tab where you should submit a request to access the model.

Step 2: Building the Chatbot Using Amazon Titan

Head over to the Playgrounds section in the side navigation and select the Chat / Text section. Enter a prompt in the playground. Click the Run button to generate a response from Titan’s text model.

Step 3: Deploy the Chatbot with AWS Lambda

Now, let’s deploy the chatbot with AWS Lambda as a serverless application! First, we need to create an AWS Lambda Function. Here are some steps to follow to create an AWS Lambda Function:

Navigate to AWS Lambda and Create a Function.

Select the Author from Scratch tab and make deployment configurations. Note that the runtime should be Python 3.10.

Create a role with full access to the Bedrock and CloudWatch permissions.

Create function! 🚀

Add some code to the Lambda function and hit the Deploy button.

import json
import boto3

bedrock = boto3.client('bedrock-runtime')

def lambda_handler(event, context):
    user_input = event['queryStringParameters']['message']

    response = bedrock.invoke_model(
        body=json.dumps({
            "prompt": user_input,
            "maxTokens": 200
        }),
        modelId="amazon.titan-text-lite-v1"
    )

    model_output = json.loads(response['body'].read().decode('utf-8'))

    return {
        "statusCode": 200,
        "headers": {"Content-Type": "application/json"},
        "body": json.dumps({"response": model_output["completions"][0]["data"]["text"]})
    }

Step 4: Deploy the API with API Gateway

Under the Function Overview, click the Add Trigger button and select the API gateway option.
Create HTTP API and configure the security method for your API endpoint.
Deploy the API! 🤘
- Note down your Invoke URL to interact with the chatbot! 🚀

Finally, you can interact with your API’s endpoint and build with it. 😎

Building a Code Generation Tool Using Amazon Bedrock and Anthropic Bedrock

Now, let’s build something more fun and technical. In this section, we will be building a code generation tool using Amazon Bedrock and Anthropic Claude’s 2.0 Model (a model that generates code as its form of response). Don’t fret, we’ll still be working with the AWS Management Console but a basic Python knowledge is required for this use case.

Step 1: Navigate to Bedrock and Select the Anthropic Claude 2.0 Model

Just like we did in the chatbot use case, access Amazon Bedrock in the AWS Management Console. Go to the Chat/Text section under the Playground section.

Under the Select Model dropdown, select the Anthropic Claude 2.0 Model. Once done, you can now enter a code-related prompt in the chat.

It’s a super great model to work with as it doesn’t just generate code; it also explains what the code does and how it works. It’s a super fast and effective model to work with!

Deploy the Code Generation Use-Case With AWS Lambda

Also just as we did in the first use-case, we will also deploy code generation using AWS Lambda.

Create a New Lambda Function

Add some Python code to Lambda Function (Runtime: 3.9):

import json
import boto3

bedrock = boto3.client('bedrock-runtime')

def lambda_handler(event, context):

  prompt = event['queryStringParameters']['prompt']

  response = bedrock.invoke_model(
    body=json.dumps({
      "prompt": f"{prompt}",
      "max_length": 300,
      "temperature": 0.7,
      "k": 0,
      "p": 0.75,
      "frequency_penalty": 0,
      "presence_penalty": 0
    }),
    modelId="arn:aws:bedrock::account:model/claude-v2-20221215"
  )

  output = json.loads(response['body'].read().decode('utf-8'))

  return {
    "statusCode": 200,
    "headers": {"Content-Type": "application/json"},
    "body": json.dumps({"code": output[0]["generated_text"]})
  }

Step 3: Deploy an API for Code Generation

Go to API Gateway and select the HTTP API option.
Integrate it with the code generator.
Deploy the API and get the Invoke URL for interactions.

Best Practices For Working With Amazon Bedrock

When working with Amazon Bedrock you need pay attention to security, cost, and performance. By following these best practices, you can make sure your AI applications are secure, efficient, and cost-effective.

1. Data Security and Privacy

Ideally, you want to keep your data private because AI models often handle sensitive user data, so security is very important in this case. To protect data when using AWS Bedrock, here some practices to follow:

Use IAM Roles and Policies: Follow the least privilege principle to limit access to Bedrock APIs and data storage. This means only giving people the permissions they need and nothing more.
Encrypt Data: You use AWS Key Management Service (KMS) to protect sensitive data both when it's stored and when it's being sent.
Monitor and Audit Access: Enable CloudWatch and AWS Config to keep track of who accesses AI models, data, and logs; and how they’re being accessed.
Mask Data: Before sending data to Bedrock, remove any personally identifiable information to reduce the risk.

2. Cost Optimization (Managing Bedrock Usage and Expenses) 💸

AWS Bedrock uses a pay-per-use pricing model, so it's important to manage costs well. You get billed based on what you use. Here's how can optimize cost using AWS Bedrock:

Choose the Right Foundation Model: Different models cost different amounts; select the one that best fits your needs and budget.
Optimize API Calls: Cut down on unnecessary API requests by using caching and batching when you can.
Monitor Usage: Use AWS Cost Explorer and AWS Budgets to track your spending and set up alerts for any unexpected cost increases.
Use Auto Scaling: When using Bedrock with AWS Lambda, adjust the number of requests to reduce unnecessary API calls.

3. Bias and Fairness

AI models can pick up biases based on the data they are trained on, which can cause problems. To make sure things are fair:

Check Model Responses: Regularly test the model's outputs with prompts to identify any biases or errors.
Use Diverse Data for Fine-Tuning: When adjusting models, make sure the data includes various groups and viewpoints.

4. Performance Tuning

To enhance response times and overall performance, follow these practices:

Tune API Parameters: Adjust settings like temperature and maxTokens to get the best results.
Use an GPU-Optimized Infrastructure: If you are deploying custom models, use AWS Inferentia to boost performance.
Load Balance Requests: If you have a lot of traffic, use AWS Application Load Balancer to distribute requests more efficiently.
Reduce Latency: Place applications closer to users with AWS Global Accelerator or AWS edge services.

Conclusion

AWS Bedrock makes it easier to integrate AI by offering scalable foundation models from Amazon and other infrastructures without the stress of training models and managing infrastructure. To get the best results, developers should focus more on security, cost-effectiveness, and performance improvements without working manually.

To keep exploring AWS Bedrock, developers should try out different models, adjust outputs, and connect with other AWS services. Keeping up with Amazon Bedrock’s guides, blogs and other resources will help make the most of Bedrock and encourage new ideas in AI-powered applications.

Before you go… 🥹

Thank you for taking the time to learn about building AI applications with AWS Bedrock. If you found this article helpful, please consider supporting Microtica by creating an account and joining the community. Your support helps us keep improving and offering valuable resources for the developer community!

Join Microtica for free! 🚀

DEV Community: Opemipo Disu

AI Agents Calling Your Existing Backend Without MCP Development

Why AI Agents Need Backend Access

What is Graftcode?

Graftcode Vs. Custom MCP Server

Use Cases for Graftcode and MCP

How Does Graftcode Work?

Benefits of Using Graftcode

Graftcode Gateway and the MCP Endpoint

Filtering What Gets Exposed

How to Implement MCP with Graftcode

Step 1: Create and initialize the Backend Service

Step 2: Install and Run Graftcode Gateway

Windows

Linux / macOS

Step 3: Inspect the Service with Graftcode Vision

Step 4: Connect an AI Client

Step 5: Test and Query the Agent

Best Practices and Tips for Graftcode and MCP

Best Use Cases for Graftcode

Conclusion

Top 5 AI Governance Tools for Enterprises (2026)

How We Compared These Tools

What Are AI Governance Tools?

1. Bifrost

Key features

Learn more about Bifrost

2. Credo AI

Strengths

Don’t use if

3. Fiddler AI

Strengths

Don’t use if

4. OneTrust

Strengths

Don’t use if

5. Speakeasy

Strengths

Don’t use if

Comparison of AI Governance Tools

Which AI Governance Tool Should You Choose?

FAQs

What are AI governance tools?

Why do enterprises need AI governance?

What is the difference between AI governance and AI observability?

What is the best AI governance tool?

Can AI governance tools reduce AI costs?

Do AI governance tools support AI agents?

Are AI governance tools required for compliance?

Can startups benefit from AI governance?

Calling a TypeScript Backend Without Integration Code - A Simple Task Tracker with Graftcode

Prerequisites

Why Do To-Do List Applications Rely on APIs?

Delving into Graftcode

Use Case for Graftcode: To-do List Application with Graftcode

Create the Backend Module

Exposing the Service Through Graftcode Gateway

Exploring Your Backend In Graftcode Vision

Install the Configured Package

Creating the React Frontend

A Quick Breakdown

Conclusion

Stop Using Fetch() in React: A Better Way To Call Your Backend

What You’ll Learn

Prerequisites

Why Do Developers Still Use fetch() in React?

What Is Graftcode?

Use Case for Graftcode: Stripe Dashboard without a REST API

Step 1: Create a React Project

Step 2: Install Hypertube NodeJS SDK

Step 3: Create the Backend Module

Step 3: Expose the Backend With Graftcode Gateway

Step 4: Install the Configured Package

Step 5: Import the Backend From Your React Application

Step 6: Exploring Backend Methods with Graftcode Vision

Step 7: Run Your Entire Application

A Deeper Look at Graftcode

Conclusion

References

Are AI Observability Tools Actually Helping?

Why Do Developers Still Use `fetch()` in React?