DEV Community: Xavier Portilla Edo

Stop Using Python for Your Gen AI Apps, Use Go and Genkit Instead

Xavier Portilla Edo — Wed, 06 May 2026 03:54:40 +0000

Introduction

For the last few years, every Gen AI tutorial, framework, and "hello world" has assumed one thing: that you are writing Python. It made sense at the start. The research community lives in Python, the model providers ship Python SDKs first, and the notebook culture is hard to beat for prototyping. But there is a quiet, important shift happening in 2026: the teams actually shipping AI features at scale are increasingly moving their production Gen AI workloads off Python, and onto languages built for services.

Go is at the center of that shift. And Genkit Go, the Go flavor of Google's open-source Gen AI framework, is the cleanest path I have seen to build production-ready AI services in Go: typed flows, structured output, built-in HTTP serving, observability, and a Developer UI, all from a single binary.

This article is two things at once. First, an honest argument about why Python is a poor fit for production Gen AI services. Second, a hands-on getting-started with Genkit Go so you can replace that Python microservice this week.

Why Python Hurts in Production Gen AI

Python is great for research and prototyping. But Gen AI applications are not really "AI code", they are mostly I/O-heavy network services that happen to call a model. And that is exactly where Python struggles.

Concurrency is a constant fight

Gen AI workloads are dominated by long, concurrent network calls: streaming completions, tool calls, embedding requests, vector DB lookups, MCP servers. Go's goroutines and channels were literally designed for this. In Python you have a choice between three uncomfortable options: threads (limited by the GIL), asyncio (which infects your entire codebase and breaks the moment one library is sync), or multiprocessing (heavy, awkward, and unfriendly to shared state). None of them feel native. All of them leak through your abstractions.

Cold starts and memory footprint

A Python AI service typically pulls in pydantic, httpx, an SDK or two, and a tokenizer. You are easily looking at 200, 400 MB of resident memory and several seconds of cold start before you serve a single request. A Go binary doing the same job is one statically linked file, tens of MB of RAM, and starts in milliseconds. On Cloud Run, Lambda, Azure Functions, or any autoscaling platform, this difference is not a micro-optimization, it is the difference between a service that scales to zero gracefully and one that does not.

Dependency hell is worse for AI

pip, poetry, uv, conda, venv, requirements.txt, pyproject.toml. Pin a Torch version, break a transitive dep. Upgrade an SDK, break Pydantic v1 vs v2. Every Python AI repo I have inherited has spent at least a day fixing the environment before running a single prompt. Go's module system, with a single go.mod and go.sum, is boring, reproducible, and just works.

Types are optional, and it shows

Structured output, tool calling, and MCP all rely on schemas. In Python, the schema lives in Pydantic models, in docstrings, in comments, and sometimes in your head. In Go, the schema is the struct. The compiler enforces it. Genkit picks it up automatically via JSON schema tags. You cannot ship a flow whose input does not match what the model returns, because it will not compile.

Deployment is a packaging exercise

Python deployments are Dockerfiles full of system packages, base images that drift, and "works on my machine" surprises. Go deploys as a single static binary. FROM scratch, copy the binary, done. For AI services that need to run on Cloud Run, on Kubernetes, on the edge, or as a sidecar, that is a massive operational win.

The performance ceiling is real

Yes, the heavy lifting happens on the model provider's GPUs. But your service still has to parse tokens off a streaming response, fan out tool calls, merge results, enforce timeouts, and push telemetry, per request, at concurrency. Go does that work an order of magnitude more efficiently than CPython, and without you having to think about it.

None of this means Python is wrong for research. It means Python is the wrong default for the service that exposes that research to your users.

Go Is the Best Language for Agentic Coders

There is one more reason to pick Go in 2026 that did not really exist two years ago: agentic coders. Tools like Claude Code, Cursor's agent mode, GitHub Copilot's agent, Gemini Code Assist, Codex, Aider, and the growing ecosystem of autonomous coding agents are now a real part of how software gets written. And it turns out that Go is the language they thrive in.

Why? It comes down to three properties of the language that align almost perfectly with how an LLM-based agent reasons about code:

Strong, static typing closes the feedback loop

Agentic coders work in a tight loop: write code, compile, read the error, fix, repeat. Go's compiler is fast, strict, and brutally honest. When an agent generates a wrong call, the compiler tells it exactly what is wrong and where, in seconds. In Python, the same mistake might only surface at runtime, three layers deep, with a stack trace that requires the agent to spend tokens reasoning about dynamic behavior. Strong typing turns "guess and pray" into "verify and continue".

There is usually one obvious way to do something

Python has at least four HTTP clients, three async paradigms, two type systems, and an opinion war about every major design decision. An agent has to choose, and choices cost tokens and increase the chance of going off the rails. Go is famously opinionated: one formatter (gofmt), one module system, one idiomatic way to handle errors, one standard layout. Less surface area means less ambiguity, which means less token consumption and more correct code per iteration.

Tooling is built for machines, not just humans

go build, go test, go vet, gopls, and staticcheck produce structured, parseable output. Agents can read it directly without heuristics. Combine that with go doc and the standard library being uniformly documented, and you give an agent a self-describing environment it can navigate without hallucinating.

And then Genkit Go takes it one level further

Genkit Go leans into the same properties:

Flow inputs and outputs are Go structs, the schema is the type. An agent generating a new flow knows exactly what shape the data has, because the compiler will reject anything else.
The API surface is small and consistent: genkit.Init, genkit.DefineFlow, genkit.DefineTool, genkit.GenerateData, genkit.Handler. There is one obvious way to define a flow, one obvious way to expose it, one obvious way to call a model.
Tool definitions are typed end-to-end, so an agent writing a new tool gets compile-time guarantees that its signature matches what the runtime expects.

The net effect is that an agentic coder pointed at a Genkit Go codebase will produce more correct code, in fewer iterations, with fewer tokens than the same agent pointed at an equivalent Python codebase. In a world where you are increasingly going to be the reviewer of agent-generated code rather than the author, that compounds fast.

Why Genkit Go Specifically

If you accept the premise that Go is the better runtime for Gen AI services, the next question is: which framework? You can absolutely call the Gemini, OpenAI, or Anthropic SDKs directly from Go. But you will quickly end up rebuilding the same primitives every Genkit user already has for free.

Here is what Genkit Go gives you out of the box, and what you would otherwise have to write yourself:

| Feature | Without Genkit | With Genkit Go |
||||
| Call a model | Hand-rolled HTTP client per provider, manual JSON, manual streaming | genkit.Generate(...), one call, multi-provider |
| Structured output | Parse raw JSON, custom unmarshaling, validate by hand | genkit.GenerateData[MyStruct], typed Go struct returned |
| Expose as an API | net/http boilerplate per endpoint, request/response wiring | genkit.Handler(flow), auto HTTP endpoint |
| Tool calling | Parse function call payloads, dispatch, re-submit | genkit.DefineTool(...), automatic execution loop |
| Observability | Wire OpenTelemetry, define spans, ship metrics | Built-in tracing, metrics, latency, zero config |
| Local dev | curl, Postman, manual harnesses | Genkit Developer UI, visual flow runner, traces, prompt playground |
| Multi-provider | Different SDKs, different auth, different schemas | Unified plugin interface (Google AI, Vertex, OpenAI, Anthropic, Bedrock, Azure, Ollama, ...) |

It is the same philosophy as Genkit Java and the JavaScript flavor I covered in my 2026 JS/TS Gen AI frameworks comparison: a thin, opinionated, cloud-agnostic layer that turns "AI logic" into a typed function you can call, test, deploy, and observe.

What We Are Going to Build

A Go service exposing a single AI flow that generates a structured recipe from a main ingredient and optional dietary restrictions. It will:

Accept a typed RecipeInput as input.
Call Gemini 3 Pro via the Google AI plugin.
Return a strongly-typed Recipe struct (no manual JSON parsing).
Be served as an HTTP endpoint on :3400.
Be testable visually in the Genkit Developer UI.

All in a single main.go file. No web framework. No code generation. Just Go.

Prerequisites

Go 1.24+ (install)
Node.js 18+ (only required for the Genkit CLI / Developer UI)
A Google GenAI API key (free, no credit card, from Google AI Studio)

Install the Genkit CLI

The Genkit CLI is your local companion for running and inspecting flows in the Developer UI:

curl -sL cli.genkit.dev | bash

Verify it:

genkit --version

Set Up the Project

Create a fresh module:

mkdir genkit-go-recipes && cd genkit-go-recipes
go mod init example/genkit-go-recipes

Install the Genkit Go package:

go get github.com/firebase/genkit/go

Set your API key:

export GEMINI_API_KEY=<your API key>

The Code: a Single `main.go`

Create main.go with the following content. This is the entire service.

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "log"
    "net/http"

    "github.com/firebase/genkit/go/ai"
    "github.com/firebase/genkit/go/genkit"
    "github.com/firebase/genkit/go/plugins/googlegenai"
    "github.com/firebase/genkit/go/plugins/server"
)

// Input schema, picked up automatically by Genkit and the Dev UI.
type RecipeInput struct {
    Ingredient          string `json:"ingredient" jsonschema:"description=Main ingredient or cuisine type"`
    DietaryRestrictions string `json:"dietaryRestrictions,omitempty" jsonschema:"description=Any dietary restrictions"`
}

// Output schema, returned directly by the model as a typed Go struct.
type Recipe struct {
    Title        string   `json:"title"`
    Description  string   `json:"description"`
    PrepTime     string   `json:"prepTime"`
    CookTime     string   `json:"cookTime"`
    Servings     int      `json:"servings"`
    Ingredients  []string `json:"ingredients"`
    Instructions []string `json:"instructions"`
    Tips         []string `json:"tips,omitempty"`
}

func main() {
    ctx := context.Background()

    // Initialize Genkit with the Google AI plugin and a default model.
    g := genkit.Init(ctx,
        genkit.WithPlugins(&googlegenai.GoogleAI{}),
        genkit.WithDefaultModel("googleai/gemini-3-pro"),
    )

    // Define a typed flow: (RecipeInput) -> (Recipe, error)
    recipeGeneratorFlow := genkit.DefineFlow(g, "recipeGeneratorFlow",
        func(ctx context.Context, input *RecipeInput) (*Recipe, error) {
            dietary := input.DietaryRestrictions
            if dietary == "" {
                dietary = "none"
            }

            prompt := fmt.Sprintf(`Create a recipe with the following requirements:
                Main ingredient: %s
                Dietary restrictions: %s`, input.Ingredient, dietary)

            // Structured generation: Gemini returns a Recipe directly.
            recipe, _, err := genkit.GenerateData[Recipe](ctx, g,
                ai.WithPrompt(prompt),
            )
            if err != nil {
                return nil, fmt.Errorf("failed to generate recipe: %w", err)
            }
            return recipe, nil
        },
    )

    // Smoke-test the flow once at boot.
    recipe, err := recipeGeneratorFlow.Run(ctx, &RecipeInput{
        Ingredient:          "avocado",
        DietaryRestrictions: "vegetarian",
    })
    if err != nil {
        log.Fatalf("could not generate recipe: %v", err)
    }
    out, _ := json.MarshalIndent(recipe, "", "  ")
    fmt.Println("Sample recipe generated:")
    fmt.Println(string(out))

    // Expose the flow as an HTTP endpoint.
    mux := http.NewServeMux()
    mux.HandleFunc("POST /recipeGeneratorFlow", genkit.Handler(recipeGeneratorFlow))

    log.Println("Starting server on http://localhost:3400")
    log.Println("Flow available at: POST http://localhost:3400/recipeGeneratorFlow")
    log.Fatal(server.Start(ctx, "127.0.0.1:3400", mux))
}

Take a moment to count what is not in this file:

No web framework.
No JSON parsing of the model output.
No manual OpenTelemetry setup.
No request/response DTO duplication.
No Dockerfile yet (we will not need much).

The struct is the contract. The flow is the endpoint. The compiler enforces both.

Run It

go run .

You should see a structured recipe printed as JSON, then the server logging that it is listening on :3400.

In another terminal, hit it with curl:

curl -X POST "http://localhost:3400/recipeGeneratorFlow" \
  -H "Content-Type: application/json" \
  -d '{"data": {"ingredient": "tomato", "dietaryRestrictions": "vegan"}}'

You will get back a fully structured JSON recipe. That is it, you have a production-shaped Gen AI microservice in one file.

Test It Visually with the Developer UI

The Genkit Developer UI is one of the strongest reasons to adopt Genkit, regardless of language. It gives you a local web app to run flows, inspect traces, tweak prompts, and debug tool calls.

From the project root:

genkit start -- go run .

Open http://localhost:4000, pick recipeGeneratorFlow, paste:

{
  "ingredient": "avocado",
  "dietaryRestrictions": "vegetarian"
}

Click Run. You will see the typed output and a full trace of the model call: tokens, latency, prompt, response. This is the kind of inner loop Python frameworks are still catching up on.

Deploying It

Because it is Go, deployment is almost anticlimactic. A minimal Dockerfile:

FROM golang:1.24 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /out/server .

FROM gcr.io/distroless/static
COPY --from=build /out/server /server
ENV PORT=3400
EXPOSE 3400
ENTRYPOINT ["/server"]

That is your entire production image. Deploy it to Cloud Run, Cloud Run Jobs, Kubernetes, AWS Lambda (via container image), Azure Container Apps, or any platform that runs containers. No Python runtime to vendor. No pip install at build time. No virtual environment. Just a binary.

If you want to see the same pattern applied to other clouds and languages, I have already covered:

Genkit Go fits the same mold, with the smallest runtime footprint of all of them.

"But What About..."

A few honest objections worth addressing.

"All the cool research libraries are in Python." True. Keep them in Python, behind a small Python service that does only the research-y bit. Put your product surface (the part your users actually call) in Go. That separation is healthy.
"My team only knows Python." Go is famously the easiest "real" backend language to learn. A Python developer can be productive in Go in days, and Genkit's API surface is small enough that the learning curve is mostly Go itself, not the framework.
"What about LangChain / LlamaIndex features?" Most of what those frameworks give you (flows, tools, RAG, prompts, evaluation, observability) Genkit Go gives you too, with a fraction of the surface area and without the abstraction tax. See my 2026 frameworks comparison for the long version.
"Is Genkit Go production-ready?" It powers Gen AI features at Google and a growing list of companies. The Go SDK shares the same core philosophy and plugin model as the JS and Java SDKs. It is stable enough to bet on, and the iteration speed is high.

Wrapping Up

Python earned its place as the language of AI research. It did not earn its place as the language of AI services. Those are different problems with different constraints, and the constraints of production services, concurrency, footprint, deployment, types, observability, all favor Go.

Genkit Go is the framework that finally makes that switch painless. You get a typed, observable, multi-provider Gen AI service in one file, one binary, and one deploy. If you are still maintaining a Python microservice whose only job is to call an LLM and return structured JSON, you are paying a tax you do not need to pay.

Try it on your next flow. Replace one Python service. See how much smaller the resulting system is, in code, in memory, and in operational surface area.

References

Top JavaScript/TypeScript Gen AI Frameworks for 2026: A Hands-On Comparison" description

Xavier Portilla Edo — Tue, 05 May 2026 02:58:12 +0000

Introduction

The Generative AI tooling ecosystem has exploded over the past two years. What started as a handful of Python libraries has grown into a rich, opinionated landscape of frameworks spanning multiple languages, deployment targets, and philosophy bets. As a developer who has shipped production applications using all five of the frameworks covered in this article, Genkit, Vercel AI SDK, Mastra, LangChain, and Google ADK, I want to offer a practical, hands-on view of where each one excels, where each one falls short, and what I would reach for depending on the project I'm building.

This is not a benchmark post. Tokens per second and latency numbers go stale within weeks. Instead, this is a developer experience and architecture comparison, the kind of thing that matters when you're deciding what framework will carry your product through 2026 and beyond.

A quick note on scope: all five frameworks are in active development and moving fast. Code samples in this article use the APIs as of April 2026.

Genkit

History and Direction

Genkit was announced by Google at Google I/O 2024 as an open-source framework designed to bring production-ready AI tooling to full-stack developers, regardless of their cloud provider. At the time, the JavaScript/TypeScript ecosystem lacked a coherent story for building AI-powered features with the kind of developer ergonomics you'd expect from, say, a Next.js app. Firebase's team set out to fix that, building Genkit not as a proprietary Firebase product but as a cloud-agnostic SDK with first-class support for plugins.

By mid-2024, Genkit had already attracted a community plugin ecosystem covering AWS Bedrock, Azure OpenAI, Ollama, Cohere, and a growing list of vector stores. The framework reached its 1.0 milestone in late 2024 and shipped major expansions in 2025, most notably adding Python (preview), Go, and Dart (preview) SDKs alongside the primary TypeScript runtime. This multi-language vision is central to Genkit's story: it aspires to be the framework you reach for no matter what stack you're running. As of 2026, the Dart SDK has matured notably, making Genkit one of the very few AI frameworks with meaningful Flutter support, giving mobile developers a first-class path into generative AI that no other framework on this list can match. It is also important to note that Genkit has a unofficial Java SDK, maintained by the community, which has been used in production but is not officially supported by the Genkit team.

The team's declared direction is to deepen Genkit's role as a full-stack AI layer: strong observability primitives baked into the runtime, composable workflow abstractions (flows), and an expanding model plugin ecosystem. The ambition is not just to be a bridge to a single model provider but to be the connective tissue that lets you swap providers, mix modalities, and trace every hop in your pipeline, all from one coherent API. Of course, Adding more campabilities to its DEV UI is also a major focus, with the goal of making it the best local development experience for AI applications, regardless of where they deploy.

What Makes Genkit Stand Out

Genkit occupies a unique position among the frameworks in this comparison: it is the only one that provides multiple levels of abstraction in a single, coherent API. You can call a model directly (vanilla generation), compose steps into a typed flow, or wire up a fully autonomous agent, and you can mix all three in the same application. Most other frameworks force you to choose a lane.

Supported languages: TypeScript/JavaScript (primary, stable), Python (preview), Go, Dart/Flutter (preview)

import { genkit } from 'genkit';
import { googleAI } from '@genkit-ai/google-genai';

const ai = genkit({ plugins: [googleAI()] });

// Vanilla generation — no abstraction needed
const { text } = await ai.generate({
  model: googleAI.model('gemini-flash-latest'),
  prompt: 'What is the capital of France?',
});
console.log(text);

Flows — Composable, Typed Pipelines

Flows are Genkit's first-class pipeline primitive. They are strongly typed, observable end-to-end, and automatically traced in the Dev UI. You define them once and can invoke them from CLI, HTTP, or the Dev UI without any extra scaffolding.

import { genkit, z } from 'genkit';
import { googleAI } from '@genkit-ai/google-genai';

const ai = genkit({ plugins: [googleAI()] });

const summarizeFlow = ai.defineFlow(
  {
    name: 'summarizeArticle',
    inputSchema: z.object({ url: z.string().url() }),
    outputSchema: z.object({ summary: z.string(), keyPoints: z.array(z.string()) }),
  },
  async ({ url }) => {
    const { output } = await ai.generate({
      model: googleAI.model('gemini-flash-latest'),
      prompt: `Summarize the article at ${url} and list the key points.`,
      output: {
        schema: z.object({ summary: z.string(), keyPoints: z.array(z.string()) }),
      },
    });
    return output!;
  }
);

Agent Abstractions

For agents, Genkit uses definePrompt with tools and a system prompt to define specialized agents, along with tool calling via defineTool and conversation memory, all integrated with the same tracing and observability infrastructure that flows use. The agent model is deliberate: it gives you control over how much autonomy you hand over to the model.

import { genkit, z } from 'genkit';
import { googleAI } from '@genkit-ai/google-genai';

const ai = genkit({ plugins: [googleAI()] });

const weatherTool = ai.defineTool(
  {
    name: 'getWeather',
    description: "'Returns current weather conditions for a given city.',"
    inputSchema: z.object({ city: z.string() }),
    outputSchema: z.object({ temperature: z.number(), condition: z.string() }),
  },
  async ({ city }) => {
    // Real implementation would call a weather API
    return { temperature: 22, condition: 'Sunny' };
  }
);

const travelAgent = ai.definePrompt(
  {
    name: 'travelAdvisor',
    description: "'Travel Advisor can help with trip planning and weather-based advice',"
    model: googleAI.model('gemini-flash-latest'),
    tools: [weatherTool],
    system: 'You are a helpful travel advisor. Use available tools to give accurate advice.',
  }
);

// Start a chat session with the agent
const chat = ai.chat(travelAgent);
const response = await chat.send('Should I pack a jacket for my trip to Lisbon?');
console.log(response.text);

The Dev UI — Where Genkit Truly Shines

The Genkit Developer UI is, frankly, the killer feature. No other framework in this comparison comes close to what Genkit offers locally. You launch it with a single command:

npx genkit start

The Dev UI gives you:

Flow runner — execute any flow with a custom input, inspect the typed output, and view the full execution trace.
Model playground — invoke any registered model directly, tweak prompt templates, compare outputs.
Tool testing — stub and test individual tools in isolation before wiring them into an agent.
Trace explorer — every generate, flow, and agent call is traced with latency breakdowns, token counts, and the exact prompts and completions sent to the model. This is OpenTelemetry-compatible telemetry, exportable to Cloud Trace, Langfuse, or any OTEL collector.
Dotprompt editor — Genkit's .prompt files (Dotprompt) are editable live in the UI, with real-time preview and variable injection.
Session replay — replay any traced session end-to-end to reproduce bugs without re-running the full application.

This local observability loop collapses what normally requires a deployed tracing backend (LangSmith, Langfuse, Weave) into a zero-config experience that runs entirely offline. For development speed, this is enormous.

Vercel's Developer Tool, by comparison, is a lightweight panel primarily for inspecting HTTP streaming responses. It doesn't offer flow visualization, trace exploration, or tool testing. It's functional but basic, the kind of thing you'd expect as a starting point, not a full developer experience.

Broad Model Support — Provider Neutral by Design

Genkit ships official plugins for Google AI (Gemini), Google Vertex AI, OpenAI, Anthropic Claude, Cohere, Mistral, Ollama (local models), AWS Bedrock, and more. The community has extended this to xAI, DeepSeek, Perplexity, and Azure OpenAI. Every model, regardless of provider, is accessed through the same ai.generate() interface, and every call is automatically traced.

import { genkit } from 'genkit';
import { anthropic } from 'genkitx-anthropic';
import { openAI } from 'genkitx-openai';

const ai = genkit({ plugins: [anthropic(), openAI()] });

// Switch between providers without changing downstream code
const { text: claudeResponse } = await ai.generate({
  model: anthropic.model('claude-sonnet-4-5'),
  prompt: 'Explain transformer attention in one paragraph.',
});

const { text: gptResponse } = await ai.generate({
  model: openAI.model('gpt-4o'),
  prompt: 'Explain transformer attention in one paragraph.',
});

Pros and Cons

✅ Pros	❌ Cons
Best-in-class Dev UI with local tracing and flow visualization	Dart/Python SDKs still in preview
Multiple abstraction levels: vanilla, flows, and agents	Smaller community than LangChain
Truly provider-neutral with broad plugin ecosystem	Some advanced patterns require deeper framework knowledge
Strong Flutter/Dart support for mobile AI
Idiomatic TypeScript API
Firebase, Cloud Run, or self-hosted deployment
OpenTelemetry-compatible observability built in

Vercel AI SDK

History and Direction

The Vercel AI SDK was born out of a practical need: Vercel builds the infrastructure that powers a large portion of the modern web, and as developers started shipping AI features inside Next.js apps in 2023, the friction of integrating streaming LLM responses into React was painfully apparent. Vercel released the initial AI SDK as an open-source library to standardize streaming, provider integration, and UI hooks across their ecosystem.

The SDK grew quickly, adding support for Vue, Svelte, SolidJS, and plain Node.js, but its DNA remains deeply tied to the Vercel and Next.js stack. Version 3 in 2024 introduced streamUI, which lets you stream React components as model output, a paradigm-shift for building truly generative user interfaces. Version 4, shipping in late 2024, brought generateObject and streamObject with Zod schemas, structured output across all providers, and an expanded agent API. By 2026, AI SDK v6 has established itself as the go-to choice for teams that live in the Vercel/React ecosystem and want the lowest-friction path from a prompt to a production UI.

Vercel's direction is clear: deeper integration between AI, edge compute, and the frontend. The AI Gateway, launched in 2025, acts as a provider proxy with load balancing and fallback, another layer of lock-in dressed as a convenience. The SDK is intentionally lower-level than Genkit or Mastra, favoring simplicity and composability over opinionated abstractions.

What Makes the Vercel AI SDK Stand Out

The Vercel AI SDK's greatest strength is its seamless integration with React and the web UI layer. useChat, useCompletion, and useObject hooks wire directly into streaming AI responses with built-in state management, loading indicators, and error boundaries. If you're building a Next.js app and want to add a chat interface or a streaming form, nothing gets you there faster.

Supported languages: TypeScript/JavaScript (primary). Node.js, React, Next.js, Nuxt, SvelteKit, SolidStart, Expo (React Native).

// app/api/chat/route.ts (Next.js App Router)
import { streamText } from 'ai';
import { openai } from '@ai-sdk/openai';

export async function POST(req: Request) {
  const { messages } = await req.json();

  const result = await streamText({
    model: openai('gpt-4o'),
    messages,
  });

  return result.toDataStreamResponse();
}

// app/page.tsx — chat UI with one hook
'use client';
import { useChat } from 'ai/react';

export default function Chat() {
  const { messages, input, handleInputChange, handleSubmit } = useChat();

  return (
    <div>
      {messages.map(m => (
        <div key={m.id}><b>{m.role}:</b> {m.content}</div>
      ))}
      <form onSubmit={handleSubmit}>
        <input value={input} onChange={handleInputChange} placeholder="Say something..." />
        <button type="submit">Send</button>
      </form>
    </div>
  );
}

Structured Generation and Agent Patterns

The SDK provides clean primitives for structured output and tool use, though the abstractions are deliberately minimal. You get generateText, streamText, generateObject, streamObject, and a simple maxSteps loop for agentic behavior. There is no high-level "flow" abstraction or graph, you compose these primitives yourself.

import { generateObject } from 'ai';
import { openai } from '@ai-sdk/openai';
import { z } from 'zod';

const { object } = await generateObject({
  model: openai('gpt-4o'),
  schema: z.object({
    recipe: z.object({
      name: z.string(),
      ingredients: z.array(z.object({ name: z.string(), amount: z.string() })),
      steps: z.array(z.string()),
    }),
  }),
  prompt: 'Generate a recipe for a vegan chocolate cake.',
});

Genkit vs. Vercel AI SDK — Abstraction Levels

Compared to Genkit, the Vercel AI SDK operates at a lower level of abstraction. This is by design, Vercel wants to give you sharp, composable tools, not an opinionated framework. The trade-off is that you assemble more boilerplate yourself. Want to trace a multi-step agent? Wire up OpenTelemetry manually. Want a typed pipeline? Build it yourself. Genkit bakes these in.

Conversely, Vercel's deep UI integration, streaming RSC, useChat, generative UI patterns, is something Genkit does not attempt to own. For Flutter-based applications, Genkit's Dart SDK fills this role, but in the web domain, Vercel wins on integration depth.

Pros and Cons

✅ Pros	❌ Cons
Unmatched React/Next.js/Edge integration	Primarily TypeScript/JavaScript only
Minimal API surface, easy to learn	No built-in flow or pipeline abstraction
`useChat` / `useCompletion` hooks are best-in-class	Developer Tool is basic (no trace explorer, no flow runner)
Generative UI with RSC streaming	Observability requires external tooling
Broad provider support via official adapters	Deeper use cases accumulate boilerplate quickly
Idiomatic TypeScript throughout	Vercel-ecosystem bias (AI Gateway, templates)

Mastra

History and Direction

Mastra is the youngest framework in this comparison, founded in 2024 by the team behind Gatsby (Cade Diehm and Sam Bhagwat). Coming from a background of developer experience tooling and static-site generation, Mastra's founders approached AI framework design with a strong bias toward TypeScript ergonomics, workflow-first thinking, and integrated tooling. The name "Mastra" (Swahili for "master") reflects the team's ambition to be the definitive TypeScript-native AI orchestration layer.

Mastra reached public beta in late 2024 and gained significant traction in early 2025 among TypeScript developers frustrated with LangChain's Python-ported patterns. The framework's distinct feature, a built-in Studio UI, arrived in early 2025 and quickly became its marquee differentiator. Mastra Studio is a web-based visual interface for defining, testing, and running agents and workflows, accessible locally or in the cloud. By mid-2025, Mastra had secured seed funding and announced hosted cloud infrastructure for deploying Mastra agents directly from the Studio.

Mastra's direction is firmly in the TypeScript/JavaScript ecosystem. The team has shown no signs of pursuing multi-language support; instead, they are doubling down on deep integrations with popular TypeScript meta-frameworks like Next.js, Astro, SvelteKit, and Hono. Think of Mastra as the opinionated, batteries-included agent framework for TypeScript developers who want to spin up production agents as fast as possible, without writing any platform glue.

What Makes Mastra Stand Out

Mastra is purpose-built for one thing: spinning up agents fast. It is an agent-only framework, you will not find vanilla model calls or a "flow" primitive. Everything in Mastra is modelled around agents, tools, memory, and workflows. If you know exactly what you need (an agent with memory and tool access), Mastra gets you there in fewer lines of code than any other framework here.

Supported languages: TypeScript/JavaScript exclusively. Integrations with Next.js, Astro, SvelteKit, Hono, Express.

import { Mastra, Agent } from '@mastra/core';
import { openai } from '@mastra/openai';

const researchAgent = new Agent({
  name: 'researcher',
  model: openai('gpt-4o'),
  instructions: `You are a research assistant. 
    Find relevant information, synthesize key points, 
    and present clear, well-structured summaries.`,
  tools: {
    // Tools added here
  },
});

const mastra = new Mastra({ agents: { researchAgent } });

const response = await mastra.getAgent('researcher').generate([
  { role: 'user', content: 'Summarize the latest developments in quantum computing.' },
]);

console.log(response.text);

Workflows

Mastra's workflow primitive lets you chain agent steps into typed, directed graphs, useful when you need a mix of deterministic logic and LLM reasoning.

import { Workflow, Step } from '@mastra/core';
import { z } from 'zod';

const contentPipeline = new Workflow({
  name: 'contentPipeline',
  triggerSchema: z.object({ topic: z.string() }),
});

contentPipeline
  .step({
    id: 'research',
    execute: async ({ context }) => {
      const { topic } = context.triggerData;
      // Agent call to research the topic
      return { research: `Key facts about ${topic}` };
    },
  })
  .then({
    id: 'draft',
    execute: async ({ context }) => {
      const { research } = context.getStepResult('research');
      // Agent call to draft the article
      return { draft: `Article draft using: ${research}` };
    },
  })
  .commit();

Pros and Cons

✅ Pros	❌ Cons
Fastest path to a production-ready agent in TypeScript	Agent-only: no flows, no vanilla generation primitives
Excellent Studio UI for visual workflow building	TypeScript/JavaScript only
Idiomatic TypeScript API with strong type inference	Younger ecosystem, fewer plugins
Good memory and tool-calling primitives	Observability still maturing
Integrates well with popular JS meta-frameworks	No mobile/cross-platform story

LangChain

History and Direction

LangChain is, by a significant margin, the most widely used AI framework in the world, but its story is complicated. Harrison Chase created LangChain in October 2022 as a Python library for chaining LLM calls, and it spread virally through the developer community in early 2023 as everyone scrambled to experiment with GPT-3 and GPT-4. Its key insight, that useful AI applications require structured chains of calls, retrieval augmentation, and tool integration, was correct and arrived at the right moment. GitHub stars and npm downloads shot to the top of every chart.

The JavaScript port, langchain on npm, arrived shortly after and has tracked the Python library closely in both API design and feature parity. This is the source of one of LangChain's most persistent criticisms: the JavaScript SDK feels like Python idioms force-translated into TypeScript. Patterns like BaseChain, runnable pipelines with .pipe(), and the LCEL (LangChain Expression Language) make perfect sense coming from Python's compositional patterns but feel unnatural to TypeScript developers accustomed to async/await and module-based composition.

LangChain the company raised $35M in 2023 and has since built a growing platform around LangSmith (observability and evaluation) and LangGraph (graph-based orchestration). This is where the tension lies: LangChain's open-source SDK and LangSmith are designed to complement each other. Getting the best observability experience requires using LangSmith. While you can configure other backends, the seamless experience is on their platform. The framework is excellent and featureful, but its commercial direction is unmistakably pointed toward LangSmith adoption.

In 2025, LangChain reorganized its JavaScript library around a cleaner agent API (create_agent) and introduced Deep Agents, pre-built agent implementations with built-in context compression and subagent spawning. LangGraph remains the recommended framework for complex multi-step workflows, and LangSmith continues to be the best-in-class platform for production LLM observability.

LangChain's Position: Agent-First, Platform-Tied

LangChain is squarely an agent framework. Its sweet spot is spinning up capable agents quickly, particularly for teams coming from the Python AI ecosystem who want to move to or stay in JavaScript without losing the LangChain mental model. It is the most feature-complete framework here in terms of raw agent capabilities, RAG patterns, and integrations, but that breadth comes with complexity.

Supported languages: Python (primary, feature-complete), JavaScript/TypeScript (JS port, near-parity). Note: the JS SDK carries Python-style patterns.

import { createAgent } from 'langchain/agents';
import { ChatOpenAI } from '@langchain/openai';

function getWeather(city: string): string {
  // Real implementation would call a weather API
  return `It's always sunny in ${city}!`;
}

const model = new ChatOpenAI({ model: 'gpt-4o', temperature: 0 });

const agent = createAgent({
  model,
  tools: [
    {
      name: 'get_weather',
      description: 'Get weather for a given city.',
      func: getWeather,
    },
  ],
  systemPrompt: 'You are a helpful assistant.',
});

const result = await agent.invoke({
  messages: [{ role: 'user', content: 'What is the weather in Madrid?' }],
});
console.log(result.messages.at(-1)?.content);

LangSmith Observability

LangSmith is LangChain's answer to the observability problem. It provides trace visualization, dataset management, prompt versioning, and LLM evaluation, all polished and production-grade. The integration with LangChain is seamless: set LANGSMITH_TRACING=true and every run is captured automatically.

The catch is that LangSmith is a SaaS platform. Genkit's Dev UI provides comparable local observability with zero cloud dependency. If you need hosted, team-scale observability, LangSmith is arguably the best option in the market. If you need local, zero-config development tracing, Genkit wins.

Pros and Cons

✅ Pros	❌ Cons
Largest community and integration ecosystem	JavaScript SDK feels like Python ported to TS
LangSmith is best-in-class for production observability	Tight coupling to LangSmith for full observability
Feature-complete agent, RAG, and chain primitives	Complex API surface, steep learning curve
Excellent Python SDK for Python teams	LangGraph required for complex graph workflows
Deep AgentS provide batteries-included patterns	Heavy bundle size in browser/edge environments
LangGraph for advanced workflow orchestration	Commercial platform pressure

Google ADK (Agent Development Kit)

History and Direction

Google ADK was announced at Google Cloud Next 2024 as Google's opinionated take on a production-grade agent framework, specifically targeting enterprise deployments on Google Cloud. Unlike Genkit, which is cloud-agnostic and full-stack, ADK was designed from day one around Vertex AI and Google Cloud's agent infrastructure, including Agent Engine, Cloud Run, and GKE. It is the framework Google recommends when you're building agents that will live in a Google Cloud environment at scale.

ADK's initial release was Python-only, which told the story clearly: this was a framework for the enterprise Python AI developer, data scientists, ML engineers, and cloud architects who think in agents and workflows and are already committed to Google Cloud. The TypeScript, Go, and Java SDKs followed in 2025, with ADK Go 1.0 and ADK Java 1.0 shipping in early 2026. This multi-language expansion signals that Google is positioning ADK as more than a Python script runner, it wants to be the enterprise agent runtime for any Google Cloud workload.

ADK 2.0, released in 2026, brought significant refinements: graph-based workflow APIs, a visual Web UI builder, enhanced evaluation tooling (including user simulation and environment simulation for testing agents end-to-end), and deeper A2A (Agent-to-Agent) protocol support. The A2A protocol is an open standard that allows ADK agents to communicate with agents built on other frameworks, a meaningful interoperability effort in a fragmented ecosystem.

Google's direction with ADK is unmistakable: this is enterprise AI infrastructure for Google Cloud customers. If your organization runs on GCP and needs reliable, scalable, observable agent deployments with enterprise support, ADK is Google's answer. If you need to be cloud-agnostic, look elsewhere.

ADK's Position: Agent-First, Enterprise-Grade

Like LangChain and Mastra, ADK is an agent-only framework, its reason for existing is to make building, evaluating, and deploying agents fast and reliable. Unlike Mastra (which targets indie developers and startups), ADK is purpose-built for enterprise scenarios: multi-agent systems, graph-based orchestration, agent evaluation at scale, and deployment to Google's managed infrastructure.

Supported languages: Python (primary, feature-complete), TypeScript/JavaScript, Go, Java. Note: the API design and documentation are heavily Python-first; TypeScript and other SDKs track but sometimes lag the Python feature set.

# Python — ADK's primary language
from google.adk import Agent
from google.adk.tools import google_search

research_agent = Agent(
    name="researcher",
    model="gemini-flash-latest",
    instruction="You help users research topics thoroughly and accurately.",
    tools=[google_search],
)

# Run locally
result = research_agent.run("What are the latest developments in fusion energy?")
print(result.text)

// TypeScript ADK
import { Agent } from '@google/adk';
import { googleSearch } from '@google/adk/tools';

const researchAgent = new Agent({
  name: 'researcher',
  model: 'gemini-flash-latest',
  instruction: 'You help users research topics thoroughly and accurately.',
  tools: [googleSearch],
});

const result = await researchAgent.run(
  'What are the latest developments in fusion energy?'
);
console.log(result.text);

Multi-Agent Systems

ADK's multi-agent support is one of its strongest features. You can compose agents hierarchically, assign them different models, and let them collaborate via the A2A protocol.

from google.adk import Agent
from google.adk.agents import SequentialAgent, ParallelAgent

researcher = Agent(name="researcher", model="gemini-flash-latest", instruction="Research the topic.")
writer = Agent(name="writer", model="gemini-pro-latest", instruction="Write a clear article from the research.")
editor = Agent(name="editor", model="gemini-flash-latest", instruction="Polish and format the article.")

content_pipeline = SequentialAgent(
    name="contentPipeline",
    agents=[researcher, writer, editor],
)

result = content_pipeline.run("Write an article about the impact of quantum computing on cryptography.")

Vertex AI Lock-In

ADK's evaluation, deployment, and production observability features lean heavily on Vertex AI Agent Engine, Cloud Trace, and Google's managed infrastructure. You can run ADK locally and even deploy to Cloud Run or GKE independently, but to get the full ADK experience, including agent evaluation, performance dashboards, and managed scaling, you're on Google Cloud. This is similar to how LangSmith is the intended observability backend for LangChain: technically optional, practically expected.

Frameworks like Genkit, Vercel AI SDK, and Mastra were designed from the ground up to be cloud-neutral. ADK and LangChain, by contrast, have strong ecosystem gravity toward their respective platforms.

Pros and Cons

✅ Pros	❌ Cons
Enterprise-grade agent infrastructure	Strongly tied to Vertex AI and Google Cloud
Multi-language: Python, TypeScript, Go, Java	Python-first: TS/Go/Java APIs lag in features
Best-in-class multi-agent and A2A support	Brings Python coding patterns to JS developers
Graph-based workflows and evaluation tools	Less suitable for cloud-agnostic deployments
Direct integration with Google Search, Vertex Search	Heavier setup and operational complexity
Agent evaluation with user simulation	Not a full-stack framework (agent-only)

Head-to-Head Comparison

Developer Experience

Framework	DX Highlights	Shortcomings
Genkit	Dev UI is unparalleled for local debugging. Idiomatic TypeScript. Multi-level abstractions.	Less prescriptive, more choices to make upfront
Vercel AI SDK	Frictionless React/Next.js integration. Minimal API.	Assembles boilerplate for complex scenarios
Mastra	Fastest path to a working agent. Great Studio UI.	Agent-only, JS-only
LangChain	Vast documentation and community. Battle-tested patterns.	Python idioms in TypeScript, complex API
ADK	Powerful multi-agent tooling. Strong eval story.	GCP-centric, Python-first

Abstraction Levels

Genkit is the only framework that gives you all three levels in one SDK: vanilla generation, typed flows (pipelines), and agents. Vercel AI SDK lives at the lower end, it gives you clean generation and tool-calling primitives but no flow abstraction. Mastra, LangChain, and ADK are agent frameworks: they optimize for spinning up agents quickly but don't offer a coherent story for when you just want to generate text or structure a pipeline without agent autonomy.

Observability

Framework	Local Dev Observability	Production Observability
Genkit	Built-in Dev UI, trace explorer, Dotprompt editor	OTEL-compatible, Cloud Trace, Langfuse
Vercel AI SDK	Basic Developer Panel	OTEL, Vercel Observability (platform-tied)
Mastra	Studio UI for workflows	Still maturing
LangChain	Minimal without LangSmith	LangSmith (best-in-class, SaaS)
ADK	ADK Web UI	Cloud Trace + Vertex (GCP-tied)

Language Support

Framework	Primary	Additional
Genkit	TypeScript	Python (preview), Go, Dart/Flutter (preview), Java (Unofficial)
Vercel AI SDK	TypeScript	Node.js runtimes, Edge
Mastra	TypeScript	JS runtimes only
LangChain	Python	TypeScript (near-parity, Python idioms)
ADK	Python	TypeScript, Go, Java

Framework Neutrality

Genkit, Vercel AI SDK, and Mastra were built from the ground up to be provider-neutral. They support OpenAI, Anthropic, Google, and others through a unified API, and they deploy to any infrastructure.

LangChain and ADK are platform-influenced. LangChain's full power unlocks with LangSmith; ADK's full power unlocks on Google Cloud. This is not a dealbreaker, both platforms are excellent, but it is an architectural commitment you should make consciously.

Idiom and Code Style

Genkit, Mastra, and Vercel AI SDK feel natively TypeScript: async/await everywhere, Zod schemas for validation, module-based composition, and no runtime class inheritance chains to navigate.

LangChain and ADK's TypeScript SDKs carry the weight of their Python origins. You'll find class-heavy APIs, .pipe() chains, and patterns that feel natural if you've written LangChain Python but unfamiliar if you're coming from the TypeScript world. This is not a quality judgment, it's a cultural fit question.

Which Framework Should You Choose?

After building with all five, here's my honest take:

Choose Genkit if:

You want to iterate on your AI fast and get feedback with less back and forth — Genkit was built from the ground up for powerful local tooling and observability.
You need to mix vanilla generation, typed pipelines (flows), and agents in the same app.
Provider neutrality is important now or likely to be important later.
You're building a Flutter/Dart mobile app and need AI capabilities.
You want OpenTelemetry-compatible tracing without configuring a separate backend.

Choose Vercel AI SDK if:

You're building a React/Next.js app and want the lowest-friction path to streaming AI UI.
Simplicity and minimal API surface matter more than built-in abstractions.
You're already on the Vercel platform and want native integration.
Your use case maps well to the UI hooks (useChat, useCompletion, generative UI).

Choose Mastra if:

You're a TypeScript developer who wants to spin up a production agent as fast as possible.
You want a clean, idiomatic TypeScript agent API without Python-ported patterns.
The visual Studio UI for workflow design appeals to your team.
You're building in the Next.js/SvelteKit/Hono ecosystem.

Choose LangChain if:

Your team is coming from the Python AI ecosystem and wants cross-language continuity.
You need the broadest possible integration ecosystem (the most integrations of any framework).
You're investing in LangSmith for production observability and want a cohesive platform.
LangGraph's graph-based orchestration matches your workflow complexity.

Choose ADK if:

You're building enterprise-grade multi-agent systems on Google Cloud.
Vertex AI's infrastructure (Agent Engine, Cloud Trace, Vertex Search) is already in your stack.
You need battle-tested multi-language support including Go and Java.
Agent evaluation at scale (user simulation, custom metrics) is a core requirement.

Conclusion

The Generative AI framework landscape in 2026 is not a winner-take-all market. Each of the five frameworks covered here has a legitimate use case, a growing community, and an active development team.

If I had to crown one framework as the most versatile choice for teams that haven't already committed to a cloud platform, it would be Genkit. Its combination of multi-level abstractions, provider neutrality, and, above all, the Developer UI creates a development experience that genuinely accelerates iteration. The fact that it is expanding to Dart/Flutter, Python, and Go while keeping its TypeScript SDK as the best-in-class experience is a sign of a team thinking about the long game.

That said, none of these frameworks is going away. LangChain's ecosystem depth, ADK's enterprise footprint, Vercel's UI ergonomics, and Mastra's TypeScript-native speed all serve real needs. The most important thing is to make the choice deliberately, understanding what you're trading when you pick a platform-tied framework, and what you're gaining when you pick a more opinionated one.

Happy building.

Last updated: April 2026. Framework versions referenced: Genkit 1.x, Vercel AI SDK 6.x, Mastra 0.x (latest), LangChain JS 0.3.x, Google ADK 2.0.

Top Gen AI Frameworks for Java in 2026: A Hands-On Comparison

Xavier Portilla Edo — Tue, 05 May 2026 02:46:01 +0000

Introduction

Java has always been a serious language for production systems, and in 2026, the Generative AI ecosystem has finally caught up. For years, Java developers watched from the sidelines as Python and TypeScript accumulated framework after framework for building LLM-powered applications. Today, the picture is very different. Java has multiple mature, actively maintained AI frameworks, each with its own philosophy and trade-offs.

This article covers the four frameworks I have personally used to ship Java AI applications: Genkit Java, Spring AI, LangChain4j, and Google ADK Java. Each one represents a meaningfully different bet on what a Java AI framework should be, and understanding those differences will save you from picking the wrong tool.

Genkit Java

History and Direction

Genkit started life as a TypeScript-first framework launched by Google at I/O 2024. The Java SDK arrived as a community-maintained effort, built and maintained by developers within the Google ecosystem who wanted to bring the same developer experience to Java that Genkit had established in TypeScript. As of 2026, Genkit Java is unofficial, it is not an official Google product, but it is actively maintained, follows the core Genkit design closely, and ships its own plugin ecosystem.

The framework's first stable release landed in early 2026 after months of preview use. Its ambition mirrors the TypeScript SDK's: bring Genkit's multi-level abstractions (vanilla generation, typed flows, agents), its broad provider-neutral plugin model, and, crucially, the Genkit Developer UI to Java developers. The Java SDK ships with Spring Boot and Jetty server plugins, making it a natural fit for teams that already run Java services in production. The Javadoc and architecture are clean and idiomatic Java, this does not feel like a port; it feels designed for the language.

The direction is clear: maintain parity with the TypeScript Genkit SDK's abstractions while embracing Java idioms (builder patterns, typed schemas via Java classes, annotation-free configuration). Support for evaluation, MCP (Model Context Protocol), RAG with pgvector and Pinecone, and multi-agent patterns is already in place.

What Makes Genkit Java Stand Out

Like its TypeScript counterpart, Genkit Java provides three levels of abstraction in a single SDK: direct model calls, typed flows (observable pipelines), and agents. This is unique in the Java AI space, no other Java framework gives you all three in one coherent API.

Supported languages: Java 21+ (primary). Deploys to Spring Boot, Jetty, or Firebase Cloud Functions.

Vanilla Generation

import com.google.genkit.Genkit;
import com.google.genkit.ai.GenerateOptions;
import com.google.genkit.plugins.googlegenai.GoogleGenAIPlugin;

Genkit genkit = Genkit.builder()
    .plugin(GoogleGenAIPlugin.create())
    .build();

String text = genkit.generate(GenerateOptions.builder()
    .model("googleai/gemini-flash-latest")
    .prompt("Explain the CAP theorem in two sentences.")
    .build()).getText();

System.out.println(text);

Typed Flows — Observable Pipelines

Flows are the heart of Genkit Java. They wrap your AI logic in a named, typed, traceable unit that is automatically exposed as an HTTP endpoint and visible in the Dev UI.

import com.google.genkit.Genkit;
import com.google.genkit.flow.FlowOptions;
import com.google.genkit.plugins.googlegenai.GoogleGenAIPlugin;
import com.google.genkit.plugins.jetty.JettyPlugin;
import com.google.genkit.plugins.jetty.JettyPluginOptions;

record TranslateRequest(String text, String targetLanguage) {}
record TranslateResponse(String translation, String detectedLanguage) {}

JettyPlugin jetty = new JettyPlugin(JettyPluginOptions.builder().port(8080).build());

Genkit genkit = Genkit.builder()
    .plugin(GoogleGenAIPlugin.create())
    .plugin(jetty)
    .build();

genkit.defineFlow(
    FlowOptions.<TranslateRequest, TranslateResponse>builder()
        .name("translateText")
        .inputClass(TranslateRequest.class)
        .outputClass(TranslateResponse.class)
        .build(),
    (ctx, request) -> {
        var response = genkit.generate(GenerateOptions.builder()
            .model("googleai/gemini-flash-latest")
            .prompt("Translate '%s' to %s. Return JSON with 'translation' and 'detectedLanguage'."
                .formatted(request.text(), request.targetLanguage()))
            .outputClass(TranslateResponse.class)
            .build());
        return response.getOutput(TranslateResponse.class);
    }
);

jetty.start();

Tools and Agents

import com.google.genkit.ai.tool.ToolDefinition;

var weatherTool = genkit.defineTool(
    ToolDefinition.<String, String>builder()
        .name("getWeather")
        .description("Returns current weather for a city.")
        .inputClass(String.class)
        .outputClass(String.class)
        .build(),
    (ctx, city) -> "Sunny, 24°C in " + city
);

// Use the tool inside a flow or agent
var result = genkit.generate(GenerateOptions.builder()
    .model("googleai/gemini-flash-latest")
    .prompt("What's the weather like in Tokyo?")
    .tools(List.of(weatherTool))
    .build());

The Dev UI — Same Power as TypeScript

One of Genkit Java's most compelling features is that the same Genkit Developer UI used by the TypeScript SDK works directly with Java applications. You install the Genkit CLI (Node.js-based) and start your Java app through it:

npm install -g genkit
genkit start -- mvn exec:java

The Dev UI opens at http://localhost:4000 and gives you:

Flow runner — execute any flow interactively with custom inputs and inspect typed outputs.
Trace explorer — full OpenTelemetry traces for every generate and flow call, showing latency, token counts, and exact prompts.
Model playground — test any registered model directly.
Tool testing — stub and test tools in isolation.
Dotprompt editor — edit .prompt files live with variable injection.

This is the single biggest advantage Genkit Java has over every other Java AI framework: a zero-config, local developer UI that replaces the need for LangSmith or Grafana during development.

Provider Support

Genkit Java ships plugins for: Google GenAI (Gemini), OpenAI, Anthropic (Claude), AWS Bedrock, Azure AI Foundry, Ollama, xAI (Grok), DeepSeek, Cohere, Mistral, and Groq. All accessed through the same genkit.generate() interface.

Vector store plugins cover: Firebase Firestore, Weaviate, PostgreSQL (pgvector), Pinecone, and a local in-memory store.

Pros and Cons

✅ Pros	❌ Cons
Best-in-class Dev UI with local trace explorer	Unofficial/community-maintained (not a Google product)
Multi-level abstractions: vanilla, flows, agents	Artifacts on GitHub Packages (requires auth to pull)
Broadest provider support in Java ecosystem	Java 21+ required
Spring Boot and Jetty deployment plugins	Smaller community than LangChain4j or Spring AI
OpenTelemetry built in	Still SNAPSHOT versioned (1.0.0-SNAPSHOT)
Idiomatic Java with builder patterns

Spring AI

History and Direction

Spring AI was announced by the Spring team (Broadcom) in mid-2023 and reached its 1.0 GA release in mid-2024. It is the most enterprise-grade option in this comparison, built by the same team that maintains Spring Framework, Spring Boot, and Spring Data, which together underpin a vast proportion of the world's Java server-side applications.

The founding premise of Spring AI is that AI integration in Java applications should feel like every other Spring integration: auto-configured, testable, portable, and production-ready out of the box. The project draws inspiration from LangChain and LlamaIndex but explicitly avoids being a port, it is designed from the ground up to be idiomatic Spring. If you have written Spring applications, Spring AI will feel immediately familiar: @Autowired AI clients, Spring Boot starters, application.properties configuration, and Advisor patterns that mirror Spring's existing interception model.

Spring AI's direction through 2025 and into 2026 has been to deepen its observability story (Micrometer-native metrics and traces), expand its ChatClient fluent API, and ship more vector store integrations. The framework is now the de facto standard for teams that are already invested in the Spring ecosystem and want to add AI capabilities without introducing a foreign dependency philosophy.

What Makes Spring AI Stand Out

Spring AI's killer feature is Spring Boot integration depth. There is no framework on this list, in any language, that integrates AI capabilities as seamlessly into an existing application framework as Spring AI does with Spring Boot. Auto-configuration, conditional beans, health indicators, Actuator endpoints for AI metrics, everything a Spring developer expects, applied to AI.

Supported languages: Java (primary). Also supports Kotlin (via Spring's Kotlin DSL). Runs anywhere Spring Boot runs: embedded Tomcat, Jetty, Undertow, GraalVM native images.

// application.properties
// spring.ai.openai.api-key=${OPENAI_API_KEY}
// spring.ai.openai.chat.options.model=gpt-4o

import org.springframework.ai.chat.client.ChatClient;
import org.springframework.web.bind.annotation.*;

@RestController
public class ChatController {

    private final ChatClient chatClient;

    public ChatController(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    @GetMapping("/chat")
    public String chat(@RequestParam String message) {
        return chatClient.prompt()
            .user(message)
            .call()
            .content();
    }
}

Structured Output

Spring AI's BeanOutputConverter maps model responses directly to Java POJOs, using the class schema to generate format instructions automatically.

import org.springframework.ai.chat.client.ChatClient;
import org.springframework.ai.converter.BeanOutputConverter;

record MovieReview(String title, int rating, String summary, List<String> pros) {}

BeanOutputConverter<MovieReview> converter = new BeanOutputConverter<>(MovieReview.class);

MovieReview review = chatClient.prompt()
    .user(u -> u.text("Review the movie Inception. {format}")
        .param("format", converter.getFormat()))
    .call()
    .entity(MovieReview.class);

System.out.println(review.title() + " — " + review.rating() + "/10");

RAG with Advisors

Spring AI's Advisors API is one of its most elegant features. Advisors wrap ChatClient calls with cross-cutting concerns, RAG retrieval, chat memory, logging, guardrails, in a declarative, composable way.

import org.springframework.ai.chat.client.ChatClient;
import org.springframework.ai.chat.client.advisor.QuestionAnswerAdvisor;
import org.springframework.ai.vectorstore.VectorStore;

@Service
public class DocumentQAService {

    private final ChatClient chatClient;

    public DocumentQAService(ChatClient.Builder builder, VectorStore vectorStore) {
        this.chatClient = builder
            .defaultAdvisors(new QuestionAnswerAdvisor(vectorStore))
            .build();
    }

    public String answerQuestion(String question) {
        return chatClient.prompt()
            .user(question)
            .call()
            .content();
    }
}

Observability

Spring AI ships with Micrometer integration out of the box. Every chat call generates spans (Spring Boot tracing) and metrics (prompt token count, completion token count, model latency) visible in any Micrometer-compatible backend: Prometheus, Grafana, Zipkin, or Datadog. There is no separate Dev UI, observability is handled by your existing Spring Boot infrastructure.

Broad Vector Store and Model Support

Spring AI supports 10+ model providers (OpenAI, Anthropic, Google Vertex AI, Amazon Bedrock, Azure OpenAI, Mistral, Ollama, Groq, and more) and 20+ vector stores (PGVector, Pinecone, Weaviate, Redis, Elasticsearch, MongoDB Atlas, Chroma, and more), the broadest integration coverage of any Java AI framework.

Pros and Cons

✅ Pros	❌ Cons
Deepest Spring Boot integration, feels native	No standalone Dev UI for flow inspection
Micrometer-native observability	Agent abstractions are less mature than LangChain4j
Broadest model and vector store integrations	Advisors pattern has a learning curve
Production-tested by the Spring ecosystem	Heavier spring context overhead for simple use cases
GraalVM native image support	No flow/pipeline abstraction like Genkit
Idiomatic Java and Kotlin support

LangChain4j

History and Direction

LangChain4j was started in early 2023 by a small community of Java developers who noticed that the LLM framework explosion happening in Python had no Java equivalent. Despite the name, the project is not a mechanical port of LangChain Python, it is a fusion of ideas from LangChain, Haystack, LlamaIndex, and original innovation, packaged in a way that makes sense for Java.

It grew quickly through 2023 and 2024, driven by its comprehensive integration list (20+ LLM providers, 30+ vector stores) and its clean two-level abstraction model: low-level primitives for maximum control and high-level AI Services for rapid development. The AI Services pattern, where you define an interface with annotations and LangChain4j implements it for you at runtime, became the framework's signature feature and arguably the most Java-idiomatic approach to LLM integration in the ecosystem.

By 2025, LangChain4j had formal integrations with Quarkus, Spring Boot, Micronaut, and Helidon, covering every major Java application framework. The team's direction in 2026 is focused on deepening agentic capabilities (multi-step tools, planning loops, MCP support) and improving the observability story, which has historically been a weaker point compared to Spring AI's Micrometer integration or Genkit's Dev UI.

What Makes LangChain4j Stand Out

LangChain4j's AI Services pattern is its defining feature. Instead of writing imperative LLM call code, you declare an interface, annotate it with @SystemMessage, @UserMessage, and memory annotations, and LangChain4j generates the implementation. The result is AI code that reads like a Java service contract, clean, testable, and completely familiar to Java developers.

Supported languages: Java (primary). Kotlin extensions available (coroutine-based async support). Integrates with Spring Boot, Quarkus, Micronaut, Helidon.

import dev.langchain4j.service.AiServices;
import dev.langchain4j.service.SystemMessage;
import dev.langchain4j.model.openai.OpenAiChatModel;

interface TranslationAssistant {
    @SystemMessage("You are a professional translator. Translate text accurately and naturally.")
    String translate(@UserMessage String text, @V("language") String targetLanguage);
}

var model = OpenAiChatModel.withApiKey(System.getenv("OPENAI_API_KEY"));

TranslationAssistant assistant = AiServices.builder(TranslationAssistant.class)
    .chatLanguageModel(model)
    .build();

String result = assistant.translate("The quick brown fox jumps over the lazy dog", "Spanish");
System.out.println(result);

Memory and Streaming

import dev.langchain4j.memory.chat.MessageWindowChatMemory;
import dev.langchain4j.service.MemoryId;

interface ConversationalAssistant {
    @SystemMessage("You are a helpful assistant.")
    String chat(@MemoryId String userId, @UserMessage String message);
}

ConversationalAssistant assistant = AiServices.builder(ConversationalAssistant.class)
    .chatLanguageModel(model)
    .chatMemoryProvider(memoryId -> MessageWindowChatMemory.withMaxMessages(20))
    .build();

// Each userId gets its own isolated memory
assistant.chat("user-42", "My name is Alice.");
String response = assistant.chat("user-42", "What's my name?");
// Returns: "Your name is Alice."

RAG Pipeline

import dev.langchain4j.data.document.loader.UrlDocumentLoader;
import dev.langchain4j.data.document.splitter.DocumentSplitters;
import dev.langchain4j.store.embedding.inmemory.InMemoryEmbeddingStore;
import dev.langchain4j.rag.content.retriever.EmbeddingStoreContentRetriever;

// Ingest documents
var documents = UrlDocumentLoader.load("https://example.com/docs");
var splitter = DocumentSplitters.recursive(500, 50);
var segments = splitter.splitAll(documents);

var embeddingModel = OpenAiEmbeddingModel.withApiKey(apiKey);
var embeddingStore = new InMemoryEmbeddingStore<TextSegment>();
EmbeddingStoreIngestor.ingest(segments, embeddingStore, embeddingModel);

// Build RAG-enabled assistant
interface DocsAssistant {
    String answer(@UserMessage String question);
}

var retriever = EmbeddingStoreContentRetriever.builder()
    .embeddingStore(embeddingStore)
    .embeddingModel(embeddingModel)
    .maxResults(3)
    .build();

DocsAssistant assistant = AiServices.builder(DocsAssistant.class)
    .chatLanguageModel(model)
    .contentRetriever(retriever)
    .build();

Two Abstraction Levels

LangChain4j explicitly offers two levels:

Low level — ChatModel, UserMessage, AiMessage, EmbeddingStore: full control, more code.
High level — AiServices: declarative interfaces, minimal boilerplate.

This mirrors what Genkit Java achieves differently. Where Genkit gives you flows and agents as pipeline concepts, LangChain4j uses interface-based AI Services as its high-level abstraction, very idiomatic in Java terms.

Pros and Cons

✅ Pros	❌ Cons
AI Services pattern is uniquely Java-idiomatic	No built-in Dev UI or trace explorer
Largest integration ecosystem (20+ models, 30+ stores)	Observability requires external tooling (no Micrometer by default)
Two clear abstraction levels (low and high)	Agent capabilities still maturing (2026)
Spring Boot, Quarkus, Micronaut, Helidon integrations	Large number of modules can be overwhelming
Kotlin coroutine support	Less opinionated, more choices to make yourself
Strong RAG tooling out of the box

Google ADK Java

History and Direction

Google ADK (Agent Development Kit) launched in 2024 as a Python-first agent framework targeting enterprise deployments on Google Cloud. Java was a late addition to the multi-language roadmap, with ADK Java 1.0 shipping in early 2026 alongside ADK Go 1.0. The Java SDK arrival was significant: it signaled that Google views ADK as a serious enterprise runtime, not just a Python scripting tool.

ADK Java follows the same design philosophy as the Python SDK: everything is an agent, workflow, or tool. The framework is optimized for building reliable, evaluatable, production-grade multi-agent systems and deploying them to Google Cloud infrastructure, primarily Vertex AI Agent Engine, Cloud Run, and GKE. Like its Python counterpart, ADK Java carries the weight of Google Cloud gravity. The best developer experience, the smoothest deployment path, and the most mature observability story all assume you are running on GCP.

ADK Java 1.0 includes the full agent runtime (LLM agents, sequential/loop/parallel workflow agents), tool calling, MCP support, A2A (Agent-to-Agent) protocol, session/memory management, and streaming. The Java API closely mirrors the Python API in structure, which means the mental model transfers well, but also means the Java SDK carries a style that reflects Python-first design decisions.

ADK Java's Position: Agent-Only, Enterprise-Grade

Like its Python counterpart, ADK Java is an agent framework, it has no vanilla generation primitive or flow abstraction outside the agent model. Its raison d'être is spinning up reliable, evaluatable agents and deploying them at enterprise scale. If you are building a multi-agent system on Google Cloud and Java is your language of choice, ADK Java 1.0 is Google's recommended path.

Supported languages: Java (with ADK Java 1.0). Also: Python (primary), TypeScript, Go.

import com.google.adk.agents.LlmAgent;
import com.google.adk.tools.GoogleSearchTool;
import com.google.adk.runner.InMemoryRunner;
import com.google.genai.types.Content;

var researchAgent = LlmAgent.builder()
    .name("researcher")
    .model("gemini-flash-latest")
    .instruction("You help users research topics thoroughly and accurately.")
    .tools(List.of(new GoogleSearchTool()))
    .build();

var runner = new InMemoryRunner(researchAgent);

var session = runner.sessionService().createSession(
    researchAgent.name(), "user-1"
).blockingGet();

var userMessage = Content.fromParts(Part.fromText(
    "What are the latest developments in fusion energy?"
));

runner.runAsync(researchAgent.name(), session.id(), userMessage)
    .blockingForEach(event -> {
        if (event.finalResponse()) {
            System.out.println(event.stringifyContent());
        }
    });

Multi-Agent Orchestration

ADK Java's multi-agent capabilities match the Python SDK's, including sequential, parallel, and loop orchestration.

import com.google.adk.agents.SequentialAgent;

var researcher = LlmAgent.builder()
    .name("researcher")
    .model("gemini-flash-latest")
    .instruction("Research the given topic and provide key facts.")
    .build();

var writer = LlmAgent.builder()
    .name("writer")
    .model("gemini-flash-latest")
    .instruction("Write a clear, well-structured article from the research provided.")
    .build();

var editor = LlmAgent.builder()
    .name("editor")
    .model("gemini-flash-latest")
    .instruction("Polish and format the article for publication.")
    .build();

var pipeline = SequentialAgent.builder()
    .name("contentPipeline")
    .subAgents(List.of(researcher, writer, editor))
    .build();

Vertex AI Lock-In

ADK Java's production deployment story is built around Vertex AI Agent Engine and Google Cloud. While you can run ADK Java locally (via the ADK CLI or directly) and deploy to Cloud Run or GKE independently, the managed evaluation tools, performance dashboards, and enterprise support all assume GCP. This is the clearest example in the Java AI space of a framework built to serve a platform rather than being platform-neutral.

Pros and Cons

✅ Pros	❌ Cons
Official Google support with production SLA	Tightly coupled to Vertex AI and GCP
Best multi-agent orchestration in Java	Agent-only framework, no vanilla generation or flows
A2A protocol for agent interoperability	Python-first design reflected in Java API style
Full evaluation tools (user simulation, custom metrics)	Requires GCP for full observability and deployment features
Scales to enterprise on Google Cloud	Youngest Java SDK (1.0 released 2026)
Streaming support (Gemini Live API)

Head-to-Head Comparison

Developer Experience

Framework	DX Highlights	Shortcomings
Genkit Java	Dev UI for local tracing is unmatched. Idiomatic Java builder API.	GitHub Packages auth friction; unofficial status
Spring AI	Feels native to any Spring Boot codebase. Zero-surprise API.	No visual Dev UI; observability via Micrometer only
LangChain4j	AI Services pattern is the cleanest Java-native AI abstraction	No Dev UI; agent features still maturing
ADK Java	Powerful multi-agent tooling. Official Google support.	GCP-centric; Python-style reflected in Java API

Abstraction Levels

Genkit Java is the only Java AI framework that provides all three levels: vanilla generation, typed flows (pipelines), and agents. Spring AI covers generation and a basic agent model via tools, but lacks a flow abstraction. LangChain4j provides two levels (low-level primitives and high-level AI Services) but is agent/service focused. ADK Java is agent-only.

Observability

Framework	Local Dev	Production
Genkit Java	Dev UI with trace explorer	OTEL-compatible export
Spring AI	Logs and Actuator endpoints	Micrometer (Prometheus, Grafana, Datadog)
LangChain4j	Logging only	Manual OTEL setup
ADK Java	ADK Web UI	Cloud Trace + Vertex (GCP)

Framework Neutrality

Genkit Java and LangChain4j are built to be provider-neutral: they support every major model and deploy to any infrastructure. Spring AI is similarly neutral on model providers, though it carries Spring's opinionated application framework as a dependency, a worthwhile trade for most Java shops. ADK Java carries the heaviest platform dependency: its full value is unlocked on Google Cloud.

Java Ecosystem Fit

Framework	Spring Boot	Quarkus	Micronaut	Native Image
Genkit Java	✅ Plugin	❌	❌	❌
Spring AI	✅ Native	❌	❌	✅ GraalVM
LangChain4j	✅ Module	✅ Extension	✅ Module	Partial
ADK Java	❌	❌	❌	❌

Which Framework Should You Choose?

Choose Genkit Java if:

You want to iterate on your AI fast and get feedback with less back and forth — Genkit was built from the ground up for powerful local tooling and observability, and the Dev UI is genuinely transformative.
You need multiple abstraction levels (vanilla calls, typed flows, and agents) in one SDK.
Provider neutrality matters: you need to swap or mix Gemini, Claude, OpenAI, and Bedrock.
Your team also writes TypeScript and wants a consistent framework story across both stacks.

Choose Spring AI if:

You are already running Spring Boot and want AI to feel like any other Spring integration.
Micrometer-native metrics and traces plugging into your existing Prometheus/Grafana stack are a priority.
You need the broadest model and vector store coverage with production-grade auto-configuration.
GraalVM native images are a requirement for your deployment targets.

Choose LangChain4j if:

You want the most Java-idiomatic high-level AI abstraction: interface-based AI Services with annotations.
You need the largest integration ecosystem and don't want to be tied to any application framework.
Your team works across Spring Boot, Quarkus, Micronaut, and Helidon, LangChain4j is the most framework-agnostic.
RAG pipelines with rich document ingestion and retrieval are a core use case.

Choose ADK Java if:

You are building enterprise-grade multi-agent systems and Google Cloud is your runtime.
You need official Google support and SLA-backed infrastructure for agent deployment.
Multi-agent orchestration (sequential, parallel, loop) and the A2A interoperability protocol matter.
Your team is already using the ADK Python SDK and wants to extend to Java services.

Conclusion

Java's AI framework landscape in 2026 is surprisingly rich. The four frameworks covered here serve genuinely different needs, and unlike in the JavaScript world where Genkit, Vercel, Mastra, LangChain, and ADK overlap significantly, the Java options each occupy a clearer niche.

For enterprise Spring Boot teams, Spring AI is the obvious choice, zero friction, production-ready observability via Micrometer, and the broadest integration matrix. For teams that value developer experience above all, Genkit Java's Dev UI is a category apart and worth the unofficial status trade-off. For framework-agnostic Java developers who want the most idiomatic Java AI service abstraction, LangChain4j's AI Services pattern is hard to beat. And for Google Cloud enterprise workloads that need reliable multi-agent orchestration at scale, ADK Java 1.0 is where Google is putting its weight.

The most important thing is that you no longer have an excuse to reach for Python just because it has better AI tooling. Java's time in generative AI has arrived.

Last updated: April 2026. Framework versions referenced: Genkit Java 1.0.0-SNAPSHOT, Spring AI 1.x, LangChain4j 0.36.x, Google ADK Java 1.0.

It Has Never Been This Easy to Build Gen AI Features in Java

Xavier Portilla Edo — Tue, 10 Feb 2026 22:24:35 +0000

Introduction

Building generative AI applications in Java used to be a complex, boilerplate-heavy endeavor. You'd wrestle with raw HTTP clients, hand-craft JSON payloads, parse streaming responses, manage API keys, and stitch together observability, all before writing a single line of actual AI logic. Those days are over.

Genkit Java is an open-source framework that makes building AI-powered applications in Java as straightforward as defining a function. Pair it with Google's Gemini models and Google Cloud Run, and you can go from zero to a production-deployed generative AI service in minutes, not days.

This is a complete, working example. Clone it, set your API key, and run.

Why Genkit Java?

If you're a Java developer, you've probably watched the Gen AI revolution unfold mostly in Python and TypeScript. The tooling, the frameworks, the tutorials, all skewed toward those ecosystems. Java developers were left to either build everything from scratch or use verbose, low-level SDKs.

What We're Building

A Java application with a translation AI flow powered by Gemini via Genkit, showcasing:

Typed flow inputs, TranslateRequest class with @JsonProperty annotations as the flow input
Structured LLM output, Gemini returns a TranslateResponse Java object directly (no manual JSON parsing)
Typed flow outputs, The flow returns a fully typed TranslateResponse to the caller

All of this in a single Java file + two model classes. No Spring Boot. No annotations soup. No XML configuration. Just clean, readable, type-safe code.

Prerequisites

Java 21+ (Eclipse Temurin recommended)
Maven 3.6+
Node.js 18+ (for the Genkit CLI)
A Google GenAI API key (free from Google AI Studio)
Google Cloud SDK (only for Cloud Run deployment)

Install the Genkit CLI

The Genkit CLI is your command-line companion for developing and testing AI flows. Install it globally:

npm install -g genkit

Verify the installation:

genkit --version

The CLI is what powers the Dev UI and provides a seamless development experience, more on that below.

Project Structure

genkit-java-getting-started/
├── src/
│   └── main/
│       ├── java/
│       │   └── com/example/
│       │       ├── App.java                # ← The main application
│       │       ├── TranslateRequest.java   # ← Typed flow input
│       │       └── TranslateResponse.java  # ← Typed flow + LLM output
│       └── resources/
│           └── logback.xml                 # Logging configuration
├── pom.xml                                 # Maven config with Genkit + Jib
├── run.sh                                  # Quick-start script
└── README.md                               # This article

Getting Started

1. Clone and Set Your API Key

git clone https://github.com/xavidop/genkit-java-getting-started.git
cd genkit-java-getting-started

export GOOGLE_API_KEY=your-api-key-here

2. Run with the Genkit Dev UI (Recommended)

genkit start -- mvn compile exec:java

That's it. Two commands. Your AI-powered Java server is running on http://localhost:8080, and the Genkit Dev UI is available at http://localhost:4000.

3. Or Run Directly (Without Dev UI)

mvn compile exec:java

The Code, It's Stupidly Simple

Step 1: Define Typed Input/Output Classes

Instead of using raw Map or String, define proper Java classes with Jackson annotations. Genkit uses these annotations to generate JSON schemas that tell Gemini exactly what structure to return.

TranslateRequest.java, the flow input:

import com.fasterxml.jackson.annotation.JsonProperty;
import com.fasterxml.jackson.annotation.JsonPropertyDescription;

/**
 * Input for the translate flow.
 */
public class TranslateRequest {

    @JsonProperty(required = true)
    @JsonPropertyDescription("The text to translate")
    private String text;

    @JsonProperty(required = true)
    @JsonPropertyDescription("The target language (e.g., Spanish, French, Japanese)")
    private String language;

    public TranslateRequest() {}

    public TranslateRequest(String text, String language) {
        this.text = text;
        this.language = language;
    }

    public String getText() {
        return text;
    }

    public void setText(String text) {
        this.text = text;
    }

    public String getLanguage() {
        return language;
    }

    public void setLanguage(String language) {
        this.language = language;
    }

    @Override
    public String toString() {
        return String.format("TranslateRequest{text='%s', language='%s'}", text, language);
    }
}

TranslateResponse.java, the flow output and the LLM structured output:

import com.fasterxml.jackson.annotation.JsonProperty;
import com.fasterxml.jackson.annotation.JsonPropertyDescription;

/**
 * Structured output for the translate flow.
 */
public class TranslateResponse {

    @JsonProperty(required = true)
    @JsonPropertyDescription("The original text that was translated")
    private String originalText;

    @JsonProperty(required = true)
    @JsonPropertyDescription("The translated text")
    private String translatedText;

    @JsonProperty(required = true)
    @JsonPropertyDescription("The target language")
    private String language;

    public TranslateResponse() {}

    public TranslateResponse(String originalText, String translatedText, String language) {
        this.originalText = originalText;
        this.translatedText = translatedText;
        this.language = language;
    }

    public String getOriginalText() {
        return originalText;
    }

    public void setOriginalText(String originalText) {
        this.originalText = originalText;
    }

    public String getTranslatedText() {
        return translatedText;
    }

    public void setTranslatedText(String translatedText) {
        this.translatedText = translatedText;
    }

    public String getLanguage() {
        return language;
    }

    public void setLanguage(String language) {
        this.language = language;
    }

    @Override
    public String toString() {
        return String.format(
            "TranslateResponse{originalText='%s', translatedText='%s', language='%s'}",
            originalText, translatedText, language);
    }
}

The @JsonPropertyDescription annotations are key, Genkit passes them to Gemini as part of the JSON schema, so the model knows exactly what each field means.

Step 2: Initialize Genkit

Genkit genkit = Genkit.builder()
    .options(GenkitOptions.builder()
        .devMode(true)
        .reflectionPort(3100)
        .build())
    .plugin(GoogleGenAIPlugin.create())
    .plugin(jetty)
    .build();

That's the entire setup. The GoogleGenAIPlugin reads your GOOGLE_API_KEY automatically. The JettyPlugin handles HTTP. Genkit wires everything together.

Step 3: Define a Flow with Typed Classes and Structured Output

genkit.defineFlow(
    "translate",
    TranslateRequest.class,     // ← typed input
    TranslateResponse.class,    // ← typed output
    (ctx, request) -> {
        String prompt = String.format(
            "Translate the following text to %s.\n\nText: %s",
            request.getLanguage(), request.getText()
        );

        return genkit.generate(
            GenerateOptions.<TranslateResponse>builder()
                .model("googleai/gemini-3-flash-preview")
                .prompt(prompt)
                .outputClass(TranslateResponse.class)  // ← Gemini returns a typed object!
                .config(GenerationConfig.builder()
                    .temperature(0.1)
                    .build())
                .build()
        );
    }
);

Look at what's happening here:

TranslateRequest.class as the flow input, Genkit automatically deserializes incoming JSON into a TranslateRequest object. No Map.get() casting.
TranslateResponse.class as the flow output, the flow returns a typed object, serialized automatically to JSON for the HTTP response.
outputClass(TranslateResponse.class) on the generate call, this is the magic. Genkit sends the JSON schema derived from TranslateResponse to Gemini, and Gemini returns structured JSON that Genkit deserializes into a TranslateResponse object. No response.getText() + manual parsing.

That single defineFlow call:

Registers the flow in Genkit's internal registry
Exposes it as a POST /api/flows/translate HTTP endpoint
Makes it visible in the Dev UI
Adds full OpenTelemetry tracing automatically
Tracks token usage, latency, and error rates

Compare that to writing a Spring Boot controller + service + DTO + config + exception handler for the same functionality.

The Genkit Dev UI - Your AI Playground

This is where Genkit truly shines for development. When you run with genkit start, the CLI launches a visual Dev UI at http://localhost:4000.

What Can You Do in the Dev UI?

Browse all flows, See every flow you've registered, like translate, with its typed input/output schemas.
Run flows interactively, Fill in a TranslateRequest JSON, click "Run", see the TranslateResponse instantly. No cURL needed.
Inspect traces, Every flow execution is traced. See exactly which model was called, what the input/output was, how long it took, and how many tokens were used.
View registered models & tools, See all available Gemini models and any tools you've defined.
Test tool calling, Watch Gemini decide to call your tools in real-time.
Manage datasets & evaluations, Create test datasets and evaluate your AI outputs.

Deploying to Google Cloud Run

The project uses Jib to build and push container images directly from Maven, no Dockerfile and no Docker daemon required. Jib is configured in the pom.xml and builds optimized, layered container images.

Step-by-Step Deployment

# Set your GCP project
export PROJECT_ID=$(gcloud config get-value project)
export REGION=us-central1

# Build the container image and push it to Google Container Registry
# No Docker needed, Jib does it all from Maven!
mvn compile jib:build -Djib.to.image=gcr.io/$PROJECT_ID/genkit-java-app

# Deploy to Cloud Run
gcloud run deploy genkit-java-app \
  --image gcr.io/$PROJECT_ID/genkit-java-app \
  --region $REGION \
  --platform managed \
  --allow-unauthenticated \
  --set-env-vars "GOOGLE_API_KEY=$GOOGLE_API_KEY" \
  --memory 512Mi \
  --cpu 1

Two commands. No Docker. Your Java GenAI application is now live on a globally-distributed, auto-scaling, serverless platform.

Why Jib?

No Dockerfile, Container image is built directly from your Maven project
No Docker daemon, Doesn't require Docker installed or running on your machine
Fast rebuilds, Separates dependencies, classes, and resources into layers, so only changed layers are rebuilt
Reproducible, Builds are deterministic and don't depend on the local Docker environment
Direct push, Sends the image straight to GCR/Artifact Registry without a local docker push

You can also build a local Docker image (requires Docker running) with:

mvn compile jib:dockerBuild -Djib.to.image=genkit-java-app

Available Flows & API Examples

Once the server is running, test the translate flow:

Translate Text

Send a TranslateRequest JSON object and receive a structured TranslateResponse:

curl -X POST http://localhost:8080/api/flows/translate \
  -H 'Content-Type: application/json' \
  -d '{"text": "Building AI applications has never been easier", "language": "Spanish"}'

Example response (a TranslateResponse object):

{
  "originalText": "Building AI applications has never been easier",
  "translatedText": "Construir aplicaciones de IA nunca ha sido tan fácil",
  "language": "Spanish"
}

Try other languages:

# French
curl -X POST http://localhost:8080/api/flows/translate \
  -H 'Content-Type: application/json' \
  -d '{"text": "Genkit makes Java AI development simple", "language": "French"}'

# Japanese
curl -X POST http://localhost:8080/api/flows/translate \
  -H 'Content-Type: application/json' \
  -d '{"text": "Hello world", "language": "Japanese"}'

Notice how the response is always a structured JSON object, not a raw string. That's the power of outputClass(TranslateResponse.class). Gemini returns structured data that Genkit deserializes into your Java class automatically.

What Genkit Gives You for Free

When you use Genkit, you're not just getting a wrapper around API calls. You get a production-grade framework:

Observability (Zero Config)

Every flow execution is automatically traced with OpenTelemetry:

Latency tracking per flow, per model call
Token usage (input/output/thinking tokens)
Error rates and failure tracking
Span hierarchy showing the full execution path

Plugin Ecosystem

Need to swap Gemini for another model? Change one line:

// Switch from Gemini to OpenAI
.plugin(OpenAIPlugin.create())

// Or use Anthropic Claude
.plugin(AnthropicPlugin.create())

// Or run locally with Ollama
.plugin(OllamaPlugin.create())

Genkit supports 10+ model providers, vector databases (Pinecone, Weaviate, PostgreSQL), Firebase integration, and more.

Type Safety

This is where Genkit really shines for Java developers. Flows, generate calls, and even LLM responses are fully typed:

// The flow takes a TranslateRequest and returns a TranslateResponse
genkit.defineFlow("translate", TranslateRequest.class, TranslateResponse.class, ...);

// The LLM returns a TranslateResponse directly, no string parsing
genkit.generate(
    GenerateOptions.<TranslateResponse>builder()
        .outputClass(TranslateResponse.class)
        .build()
);

Genkit derives JSON schemas from your @JsonProperty and @JsonPropertyDescription annotations and sends them to Gemini, so the model returns structured data that maps directly to your Java classes. No Object casting, no response.getText() + objectMapper.readValue(), no runtime surprises.

What's Next?

This getting-started project covers the fundamentals. Genkit Java can do much more:

RAG, Retrieval-Augmented Generation with vector stores (Firestore, Pinecone, pgvector, Weaviate)
Multi-agent orchestration, Coordinate multiple AI agents
Chat sessions, Multi-turn conversations with session persistence
Evaluations, RAGAS-style metrics to measure your AI output quality
MCP Integration, Connect to Model Context Protocol servers
Spring Boot, Use the Spring plugin instead of Jetty for existing Spring apps
Firebase, Deploy as Cloud Functions with Firestore vector search

Explore the full Genkit Java documentation and the samples directory to dive deeper.

Conclusion

As you can see, it is very easy to use Genkit Java and Gemini to build powerful generative AI applications with minimal code. The combination of typed inputs/outputs, structured LLM responses, built-in observability, and seamless deployment makes Genkit Java the best way to build GenAI features in Java.

You can find the full code of this example in the GitHub repository

Happy coding!

Alexa Entities

Xavier Portilla Edo — Tue, 26 Sep 2023 17:03:15 +0000

En el Alexa Live 2020, el equipo de Amazon Alexa lanzó una funcionalidad llamada Alexa Entities. Esta funcionalidad tiene como objetivo utilizar el Alexa Graph Knowledge para recuperar información adicional de algunos built-in slots como por ejemplo de lugares, actores, personas, etc. Después de un año, esta funcionalidad se ha lanzado en más locales, incluidos español, alemán, francés e italiano. Con Alexa Entities, no necesitas acceder a una API externa para obtener datos adicionales. Cada entity proporcionará una URL del grafo de conocimiento de Alexa donde podrás obtener esa información extra.

Prerrequisitos

Aquí tienes las tecnologías utilizadas en este proyecto:

Node.js v14.x
Visual Studio Code
Extensión de Alexa para VS Code

Configurando nuestra Skill de Alexa

Como he señalado más arriba, cuando agregamos un built-in slot en nuestro modelo de interacción, por ejemplo AMAZON.Actor, y ese slot se matchea con lo que ha dicho el usuario, recibiremos en nuestra AWS Lambda dos cosas.

Primero que este slot se ha matcheado
Segundo, algo de información adicional.

Esa información adicional será la resolución del slot como una Alexa entity. ¿Qué es esa información? Será un enlace donde podemos obtener todos los datos de esa Alexa entity que se ha matcheado. Este enlace tiene una forma parecida al siguiente: https://ld.amazonalexa.com/entity/v1/KmHs1W4gVQDE9HHq72eDLs

Debido a esto, necesitamos configurar nuestro backend de la Alexa Skill. Como vamos a buscar algunos datos en el Alexa Knowledge Graph, el primer paso que debemos hacer es agregar un paquete npm: axios

Para instalar esta dependencia, tenemos ejecutar estos comandos:

Para npm:

    npm install --save axios

Para yarn:

    yarn add axios

Axios es una de las librerías más comunes que se utilizan en Node.js para realizar solicitudes HTTP.

¡Con este paquete instalado/actualizado, ya casi tenemos el setup necesario! Continuemos con los siguientes pasos.

Resolución de las Alexa Entities

Como se explica en la documentación oficial: "Cada Entity es un nodo vinculado a otras Entities en el grafo de conocimiento".

Así que volvamos a nuestro ejemplo, el del AMAZON.Actor. Imagina que tenemos un slot llamado actor que usa ese tipo de built-in slot. Cuando solicitamos información de un actor y ese actor coincide con el slot y también ese actor existe en el grafo de conocimiento de Alexa, obtendremos una URL para obtener sus datos.

Pero, ¿dónde podemos encontrar esa URL? ¿Dónde se encuentra esa información dentro de la request? Esto es lo que Alexa llama Slot resolution. El Slot resolution es la forma en que Alexa nos dice, como desarrolladores, que un slot ha matchaedo con éxito y cuál es la authority que resolvió el valor de ese slot. Por ejemplo, un slot puede resolverse mediante estas 3 authorities:

Como Custom value. Por ejemplo, un actor que agregamos manualmente.
Como Dynamic entity. Los valores personalizados que podemos agregar mediante código.
Como Alexa entity. Cuando el actor existe en el grafo de conocimiento de Alexa.

Las Slot resolution authorities y sus resoluciones se pueden encontrar dentro de la request aquí:

En este ejemplo, cuando obtenemos los datos, vemos algunas propiedades como birthdate, birthplace o un array llamado child. Este array contiene el hijo o los hijos del actor que hemos solicitado. En cada objeto del array child encontraremos una URL donde podemos obtener los datos de cada hijo.

Es importante señalar aquí que cada entity tiene su propio esquema. Se explican todos los tipos aquí.

Jugando con Alexa Entities

Una vez que tenemos los paquetes que necesitamos instalados/actualizados y entendemos la resolución de las Alexa Entities y cómo funciona, necesitamos modificar nuestro AWS Lambda para jugar con las Alexa Entities.

Para este ejemplo, he creado un intent para obtener información de los actores:

El slot actor está usando el built-in slot AMAZON.Actor:

Luego tenemos un handler para este intent llamado EntityIntentHandler. Lo primero que va a hacer este controlador es verificar si el slot actor se ha matchaedo exitósamente y si se ha resuelto como una Alexa Entity:

const actor = Alexa.getSlot(handlerInput.requestEnvelope, 'actor')

const resolutions = getSlotResolutions(actor);

Esta es la función getSlotResolutions:

function getSlotResolutions(slot) {
    return slot.resolutions
        && slot.resolutions.resolutionsPerAuthority
        && slot.resolutions.resolutionsPerAuthority.find(resolutionMatch);
}

function resolutionMatch(resolution) {
    return resolution.authority === 'AlexaEntities'
        && resolution.status.code === 'ER_SUCCESS_MATCH';
}

Cuando tenemos el slot y se resuelve con éxito como una Alexa Entity, necesitamos obtener un token. Este token se incluye en cada request. Para eso solo necesitas llamar a esta función:

const apiAccessToken = Alexa.getApiAccessToken(handlerInput.requestEnvelope);

Ten en cuenta que el objeto Alexa es el objeto que obtuvimos al importar la biblioteca ask-sdk-core:

const Alexa = require('ask-sdk-core');

Con toda esta información, podemos llamar al grafo de conocimiento de Alexa usando axios (asegúrate de que ya lo has importado):

const entityURL = resolutions.values[0].value.id;
const headers = {
    'Authorization': `Bearer ${apiAccessToken}`,
    'Accept-Language': Alexa.getLocale(handlerInput.requestEnvelope)
};
const response = await axios.get(entityURL, { headers: headers });

Es importante agregar el locale para obtener los datos en el idioma adecuado.

Si la request ha ido bien, podemos preparar nuestra string que vamos a devolver a Alexa usando los datos del Alexa Knowledge Graph:

if (response.status === 200) {
    const entity = response.data;
    const birthplace = entity.birthplace.name[0]['@value']
    const birthdate = new Date(Date.parse(entity.birthdate['@value'])).getFullYear()
    const childsNumber = entity.child.length
    const occupation = entity.occupation[0].name[0]['@value']
    const awards = entity.totalNumberOfAwards[0]['@value']
    const name =  entity.name[0]['@value']
    if (Alexa.getLocale(handlerInput.requestEnvelope).indexOf('es') != -1){
        speakOutput = name + ' nació en ' + birthplace + ' en '+ birthdate +' y tiene ' + childsNumber + ' hijos. Actualmente trabaja como ' + occupation + '. Tiene un total de ' + awards + ' premios.'
    }else{
        speakOutput = name + ' was borned in ' + birthplace + ' in ' + birthdate + ' and has ' + childsNumber + ' children. Now is working as a ' + occupation + '. Has won ' + awards + ' awards.'
    }

}else{
    if (Alexa.getLocale(handlerInput.requestEnvelope).indexOf('es') != -1){
        speakOutput = 'No he encontrado informacion sobre ese actor.'
    }else{
        speakOutput = 'Didnt find information about that actor.'
    }
}

Y este es el resultado final:

¿Qué Alexa Entities están disponibles?

Es importante decir que no todas los built-in slots de Alexa están enlazados a Alexa Entities. Depende del locale y del built-in slot en sí. Para asegurarte de cuáles están disponibles, puedes consultar la documentación oficial.

Recursos

Official Alexa Skills Kit Node.js SDK - The Official Node.js SDK Documentation
Official Alexa Skills Kit Documentation - Official Alexa Skills Kit Documentation
Official Alexa Entities Documentation - Official Alexa Entities Documentation

Conclusión

Como puedes ver, las Alexa Entities pueden ayudarnos a crear experiencias de voz muy chulas con contenido enriquecido.

Espero que este proyecto de ejemplo os sea de utilidad.

Puedes encontrar el código aquí

¡Eso es todo amigos!

Happy coding!

DevOps your Alexa Skill

Xavier Portilla Edo — Sun, 13 Sep 2020 11:02:42 +0000

My Workflow

"DevOps is the union of people, process, and products to enable continuous delivery of value to our end users." - Donovan Brown, Microsoft

DevOps is a "culture" which have a set of practices that combines software development (Dev) and information-technology operations (Ops) which aims to shorten the systems development life cycle and provide continuous delivery with high software quality. DevOps culture develops "production-first mindset".
In terms of Alexa, DevOps can help us to quickly ship the highest quality of our Skill to the end customers.
This post contains materials from different resources that can be seen on Resources section.

Prerequisites

Here you have the technologies used in this project

Amazon Developer Account - How to get it
AWS Account - Sign up here for free
ASK CLI - Install and configure ASK CLI
GitHub Account - Sign up here
Visual Studio Code

The Alexa Skills Kit Command Line Interface (ASK CLI) is a tool for you to manage your Alexa skills and related resources, such as AWS Lambda functions.
With ASK CLI, you have access to the Skill Management API, which allows you to manage Alexa skills programmatically from the command line.
If you want how to create your Skill with the ASK CLI, please follow the first step explained in my Node.js Skill sample.
We are going to use this powerful tool to do some steps in our pipeline. Let's DevOps!

Pipeline

Let's explain job by job what is happening in our powerful pipeline.
First of all, each box on the left represented in the image above is a job and they will be defined below the jobs node in the GitHub Actions Workflow configuration file:

Checkout

The checkout job will execute the following tasks:

Checkout the code
Bring execution permission to be able to execute all the tests

  checkout:
    runs-on: ubuntu-latest
    name: Checkout
    steps:
      # To use this repository's private action,
      # you must check out the repository
      - name: Checkout
        uses: actions/checkout@v2
      - run: |
          chmod +x -R ./test;
          ls -la

Build

The build job will execute the following tasks:

Checkout the code.
Run npm install in order to download all the Node.js dependencies, including dev dependencies.

  build:
    runs-on: ubuntu-latest
    name: Build
    needs: checkout
    steps:
      # To use this repository's private action,
      # you must check out the repository
    - name: Checkout
      uses: actions/checkout@v2
    - run: |
        cd lambda;
        npm install

Pretests

The pretest job will execute the static code quality check. Check the full explanation here.

Test

The test job will execute the unit tests. Check the full explanation here.

Code Coverage

The codecov job will execute the code coverage report. Check the full explanation here.

Deploy

The deploy job will deploy the Alexa Skill to the Alexa cloud in the development stage. Check the full explanation here.

Testing the Voice User Interface

These jobs will check our interaction model. Check the full explanation here.

Integration tests

These jobs will check the interaction model and our backend as well. Check the full explanation here.

End to end tests

These jobs will check the full system using the voice as input. Check the full explanation here.

Validation tests

These jobs will validate your Alexa Skill before submitting it to certification. Check the full explanation here.

Submit

These jobs will submit your Alexa Skill to certification. Check the full explanation here.

Store-artifacts

The store-artifacts job will execute the following tasks:

Restore the code that we have used in the previous step in /home/node/project folder
Clean node_modules folder
Store the entire code of our Alexa Skill as an artifact. It will be accessible in GitHub Actions whenever we want to check it out.


  store-artifacts:
    runs-on: ubuntu-latest
    name: Submit
    needs: submit
    steps:
    # To use this repository's private action,
    # you must check out the repository
    - name: Checkout
      uses: actions/checkout@v2}
    - name: Upload code
      uses: actions/upload-artifact@v2
      with:
        name: code
        path: ${{ github.workspace }}

Workflow

The GitHub Actions Workflow which will execute the jobs explained above configuration file is located in .github/workflows/main.yml:


on: [push]

jobs:
  checkout:
    runs-on: ubuntu-latest
    name: Checkout
    steps:
      # To use this repository's private action,
      # you must check out the repository
      - name: Checkout
        uses: actions/checkout@v2
      - run: |
          chmod +x -R ./test;
          ls -la
  build:
    runs-on: ubuntu-latest
    name: Build
    needs: checkout
    steps:
      # To use this repository's private action,
      # you must check out the repository
    - name: Checkout
      uses: actions/checkout@v2
    - run: |
        cd lambda;
        npm install
  pretest:
    runs-on: ubuntu-latest
    name: Pre-test
    needs: build
    steps:
    # To use this repository's private action,
    # you must check out the repository
      # To use this repository's private action,
      # you must check out the repository
    - name: Checkout
      uses: actions/checkout@v2
    - run: |
        cd lambda;
        npm install;
        npm run lint;
        npm run lint-html
    - name: Upload results
      uses: actions/upload-artifact@v2
      with:
        name: eslint-report
        path: lambda/reports/eslint/

  test:
    runs-on: ubuntu-latest
    name: Test
    needs: pretest
    steps:
    # To use this repository's private action,
    # you must check out the repository
    - name: Checkout
      uses: actions/checkout@v2
    - run: |
        cd lambda;
        npm install;
        npm run test
    - name: Upload results
      uses: actions/upload-artifact@v2
      with:
        name: unit-tests-report-html
        path: lambda/mochawesome-report/
    - name: Upload results
      uses: actions/upload-artifact@v2
      with:
        name: unit-tests-report-xml
        path: lambda/reports/mocha/

  codecov:
    runs-on: ubuntu-latest
    name: Code Coverage
    needs: test
    steps:
    # To use this repository's private action,
    # you must check out the repository
    - name: Checkout
      uses: actions/checkout@v2
    - run: |
        cd lambda;
        npm install;
        npm run codecov
      env: # Or as an environment variable
        CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
  deploy:
    runs-on: ubuntu-latest
    name: Deploy
    needs: codecov
    steps:
    # To use this repository's private action,
    # you must check out the repository
    - name: Checkout
      uses: actions/checkout@v2
    - run: |
        sudo npm install -g ask-cli;
        sudo apt-get install -y jq
        cd lambda;
        npm install;
        npm run copy-package;
        cd src;
        npm run build-production
    - run: ls -la && ask deploy --ignore-hash  
      env: # Or as an environment variable
        CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
        ASK_ACCESS_TOKEN: ${{ secrets.ASK_ACCESS_TOKEN }}
        ASK_REFRESH_TOKEN: ${{ secrets.ASK_REFRESH_TOKEN }}
        ASK_VENDOR_ID: ${{ secrets.ASK_VENDOR_ID }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        SKILL_ID: ${{ secrets.SKILL_ID }}

  check-utterance-conflicts:
    runs-on: ubuntu-latest
    name: Check Utterance Conflicts
    needs: deploy
    steps:
    # To use this repository's private action,
    # you must check out the repository
    - name: Checkout
      uses: actions/checkout@v2
    - run: |
        sudo npm install -g ask-cli;
        chmod +x -R ./test;
        cd test/vui-test/;
        ./interaction_model_checker.sh $SKILL_ID v2
      env: # Or as an environment variable
        CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
        ASK_ACCESS_TOKEN: ${{ secrets.ASK_ACCESS_TOKEN }}
        ASK_REFRESH_TOKEN: ${{ secrets.ASK_REFRESH_TOKEN }}
        ASK_VENDOR_ID: ${{ secrets.ASK_VENDOR_ID }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        SKILL_ID: ${{ secrets.SKILL_ID }}
  check-utterance-resolution:
    runs-on: ubuntu-latest
    name: Check Utterance Resolution
    needs: deploy
    steps:
    # To use this repository's private action,
    # you must check out the repository
    - name: Checkout
      uses: actions/checkout@v2
    - run: |
        sudo npm install -g ask-cli;
        chmod +x -R ./test;
        cd test/vui-test/;
        ./utterance_resolution_checker.sh $SKILL_ID v2
      env: # Or as an environment variable
        CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
        ASK_ACCESS_TOKEN: ${{ secrets.ASK_ACCESS_TOKEN }}
        ASK_REFRESH_TOKEN: ${{ secrets.ASK_REFRESH_TOKEN }}
        ASK_VENDOR_ID: ${{ secrets.ASK_VENDOR_ID }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        SKILL_ID: ${{ secrets.SKILL_ID }}
  check-utterance-evaluation:
    runs-on: ubuntu-latest
    name: Check Utterance Evaluation
    needs: deploy
    steps:
    # To use this repository's private action,
    # you must check out the repository
    - name: Checkout
      uses: actions/checkout@v2
    - run: |
        sudo npm install -g ask-cli;
        chmod +x -R ./test;
        cd test/vui-test/;
        ./utterance_evaluation_checker.sh $SKILL_ID v2
      env: # Or as an environment variable
        CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
        ASK_ACCESS_TOKEN: ${{ secrets.ASK_ACCESS_TOKEN }}
        ASK_REFRESH_TOKEN: ${{ secrets.ASK_REFRESH_TOKEN }}
        ASK_VENDOR_ID: ${{ secrets.ASK_VENDOR_ID }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        SKILL_ID: ${{ secrets.SKILL_ID }}
  integration-test:
    runs-on: ubuntu-latest
    name: Integration test
    needs: check-utterance-evaluation
    steps:
    # To use this repository's private action,
    # you must check out the repository
    - name: Checkout
      uses: actions/checkout@v2
    - run: |
        sudo npm install -g ask-cli;
        chmod +x -R ./test;
        sudo apt-get install -y expect
        cd test/integration-test/;
        ./simple-dialog-checker.sh $SKILL_ID
      env: # Or as an environment variable
        CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
        ASK_ACCESS_TOKEN: ${{ secrets.ASK_ACCESS_TOKEN }}
        ASK_REFRESH_TOKEN: ${{ secrets.ASK_REFRESH_TOKEN }}
        ASK_VENDOR_ID: ${{ secrets.ASK_VENDOR_ID }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        SKILL_ID: ${{ secrets.SKILL_ID }}
  end-to-test:
    runs-on: ubuntu-latest
    name: End-to-end test
    needs: integration-test
    steps:
    # To use this repository's private action,
    # you must check out the repository
    - name: Checkout
      uses: actions/checkout@v2
    - run: |
        sudo npm install -g ask-cli;
        sudo npm install -g bespoken-tools;
        chmod +x -R ./test;
        bst test --config test/e2e-bespoken-test/testing.json
      env: # Or as an environment variable
        CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
        ASK_ACCESS_TOKEN: ${{ secrets.ASK_ACCESS_TOKEN }}
        ASK_REFRESH_TOKEN: ${{ secrets.ASK_REFRESH_TOKEN }}
        ASK_VENDOR_ID: ${{ secrets.ASK_VENDOR_ID }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        SKILL_ID: ${{ secrets.SKILL_ID }}
    - name: Upload code
      uses: actions/upload-artifact@v2
      with:
        name: bespoken-report
        path: test_output/

  validation-test:
    runs-on: ubuntu-latest
    name: Validation test
    needs: end-to-test
    steps:
    # To use this repository's private action,
    # you must check out the repository
    - name: Checkout
      uses: actions/checkout@v2
    - run: |
        sudo npm install -g ask-cli;
        chmod +x -R ./test;
        cd test/validation-test/;
        ./skill_validation_checker.sh $SKILL_ID v2
      env: # Or as an environment variable
        CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
        ASK_ACCESS_TOKEN: ${{ secrets.ASK_ACCESS_TOKEN }}
        ASK_REFRESH_TOKEN: ${{ secrets.ASK_REFRESH_TOKEN }}
        ASK_VENDOR_ID: ${{ secrets.ASK_VENDOR_ID }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        SKILL_ID: ${{ secrets.SKILL_ID }}

  submit:
    runs-on: ubuntu-latest
    name: Submit
    needs: validation-test
    steps:
    # To use this repository's private action,
    # you must check out the repository
    - name: Checkout
      uses: actions/checkout@v2
    - run: |
        sudo npm install -g ask-cli;
        chmod +x -R ./test;
        cd test/submit/;
        ./submit.sh $SKILL_ID v2
      env: # Or as an environment variable
        CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
        ASK_ACCESS_TOKEN: ${{ secrets.ASK_ACCESS_TOKEN }}
        ASK_REFRESH_TOKEN: ${{ secrets.ASK_REFRESH_TOKEN }}
        ASK_VENDOR_ID: ${{ secrets.ASK_VENDOR_ID }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        SKILL_ID: ${{ secrets.SKILL_ID }}
  store-artifacts:
    runs-on: ubuntu-latest
    name: Store Artifacts
    needs: submit
    steps:
    # To use this repository's private action,
    # you must check out the repository
    - name: Checkout
      uses: actions/checkout@v2
    - name: Upload code
      uses: actions/upload-artifact@v2
      with:
        name: code
        path: ${{ github.workspace }}

GitHub Action

After explain the pipeline, it is important to explain the GitHub Action which are using the Docker image that you can use in your pipelines.
With the above Docker image a GitHub Action has been created in order to run ASK CLI Commands:

This GitHub Action is available in the gitHub Actions Marketplace](https://github.com/marketplace/actions/alexa-ask-aws-cli-action)

You can use the following example as a way to start:


  - name: Alexa ASK AWS CLI Action
    uses: xavidop/alexa-ask-aws-cli-docker@v1.0.6
    id: command
    with:
      command: 'ask --version'
    env: # Or as an environment variable
      ASK_ACCESS_TOKEN: ${{ secrets.ASK_ACCESS_TOKEN }}
      ASK_REFRESH_TOKEN: ${{ secrets.ASK_REFRESH_TOKEN }}
      ASK_VENDOR_ID: ${{ secrets.ASK_VENDOR_ID }}
      AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
      AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      SKILL_ID: ${{ secrets.SKILL_ID }}
  # Use the output from the `hello` step
  - name: Get the output
    run: echo "The result was ${{ steps.command.outputs.result }}"

Or for example using it in a workflow:

  on: [push]

  jobs:
    test-action:
      runs-on: ubuntu-latest
      name: Test Action
      steps:
        # To use this repository's private action,
        # you must check out the repository
        - name: Checkout
          uses: actions/checkout@v2
        - name: Test action step
          uses: xavidop/alexa-ask-aws-cli-docker@v1.0.6
          id: ask
          with:
            command: 'ask --version'
          env: # Or as an environment variable
            ASK_ACCESS_TOKEN: ${{ secrets.ASK_ACCESS_TOKEN }}
            ASK_REFRESH_TOKEN: ${{ secrets.ASK_REFRESH_TOKEN }}
            ASK_VENDOR_ID: ${{ secrets.ASK_VENDOR_ID }}
            AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
            AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
            SKILL_ID: ${{ secrets.SKILL_ID }}
        # Use the output from the `hello` step
        - name: Get the output
          run: echo "The result was ${{ steps.ask.outputs.result }}"

It is important to add that the GiHub Action are using the latest version of the ASK CLI.
You can find all the explanation in this repo.

xavidop / alexa-ask-aws-cli-docker

Docker container for ASK CLI and easy to use in devops pipelines

Docker image for ASK and AWS CLI

The purpose of this container is to be able to use the Amazon ASK CLI and Amazon AWS CLI in a Docker container in DevOps pipelines.

NOTE: This is a fork from martindsouza image with these changes:

Image base is the latest LTS version instead of the current version of Node.js.
Added ASK_CLI_VERSION build argument in order to be able to work with different ASK CLI versions.
Added git and zip packages that ASK CLI will use in its commands.
Added Bespoken.
Added jq and expect cli commands.
Remove volumes. I think it is not necessary in a simple docker image that I will use in my DevOps pipelines. In addition, you can use '-v' argument in docker run command whenever you want.

ASK Config

You have to take into account that you have to have an Alexa Developer account to be able…

View on GitHub

Conclusion

This is the first step to know how to DevOps your Alexa Skills using GitHub Actions.
As you have seen in this example, the Alexa Tools like ASK CLI can help us a lot. We will update this readme while we are updating the pipeline.
I hope this example project is useful to you.

That's all folks!

Happy coding!

Submission Category:

DIY Deployments

Yaml File or Link to Code

Here you have the link to the GitHub Repository:

xavidop / alexa-nodejs-lambda-helloworld-v2

Alexa Skill v2 template using Node.js

Alexa Skill with Node.js

Alexa Skill with Node.js

Alexa skills can be developed using Alexa Lambda functions or a REST API endpoint Lambda function is Amazon's implementation of serverless functions available in AWS. Amazon recommends using Lambda functions despite they are not easy to debug. While you can log to a CloudWatch log, you can't hit a breakpoint and step into the code.

This makes live debugging of Alexa requests a very hard task In this post, we will implement a custom skill for Amazon Alexa by using Node.js, npm and AWS Lambda Functions. This skill is basically a Hello World…

View on GitHub

Additional Resources / Info

DevOps Wikipedia - Wikipedia reference
Official Alexa Skills Kit Node.js SDK - The Official Node.js SDK Documentation
Official Alexa Skills Kit Documentation - Official Alexa Skills Kit Documentation
Official GitHub Actions Documentation - Official GitHub Actions Documentation

DEV Community: Xavier Portilla Edo

Stop Using Python for Your Gen AI Apps, Use Go and Genkit Instead

Introduction

Why Python Hurts in Production Gen AI

Concurrency is a constant fight

Cold starts and memory footprint

Dependency hell is worse for AI

Types are optional, and it shows

Deployment is a packaging exercise

The performance ceiling is real

Go Is the Best Language for Agentic Coders

Strong, static typing closes the feedback loop

There is usually one obvious way to do something

Tooling is built for machines, not just humans

And then Genkit Go takes it one level further

Why Genkit Go Specifically

What We Are Going to Build

Prerequisites

Install the Genkit CLI

Set Up the Project

The Code: a Single main.go

Run It

Test It Visually with the Developer UI

Deploying It

"But What About..."

Wrapping Up

References

Top JavaScript/TypeScript Gen AI Frameworks for 2026: A Hands-On Comparison" description

Introduction

Genkit

History and Direction

What Makes Genkit Stand Out

Flows — Composable, Typed Pipelines

Agent Abstractions

The Dev UI — Where Genkit Truly Shines

Broad Model Support — Provider Neutral by Design

Pros and Cons

Vercel AI SDK

History and Direction

What Makes the Vercel AI SDK Stand Out

Structured Generation and Agent Patterns

Genkit vs. Vercel AI SDK — Abstraction Levels

Pros and Cons

Mastra

History and Direction

What Makes Mastra Stand Out

Workflows

Pros and Cons

LangChain

History and Direction

LangChain's Position: Agent-First, Platform-Tied

LangSmith Observability

Pros and Cons

Google ADK (Agent Development Kit)

History and Direction

ADK's Position: Agent-First, Enterprise-Grade

Multi-Agent Systems

Vertex AI Lock-In

Pros and Cons

Head-to-Head Comparison

Developer Experience

Abstraction Levels

Observability

Language Support

Framework Neutrality

Idiom and Code Style

Which Framework Should You Choose?

Conclusion

Top Gen AI Frameworks for Java in 2026: A Hands-On Comparison

Introduction

Genkit Java

History and Direction

What Makes Genkit Java Stand Out

Vanilla Generation

Typed Flows — Observable Pipelines

Tools and Agents

The Dev UI — Same Power as TypeScript

Provider Support

Pros and Cons

Spring AI

The Code: a Single `main.go`