DEV Community

Cover image for "Beyond the Brain: Exposing AI Modules to REST, gRPC, and GraphQL"
tercel
tercel

Posted on

"Beyond the Brain: Exposing AI Modules to REST, gRPC, and GraphQL"

#ai #python #architecture #api

We’ve seen how apcore modules can be called by Claude via MCP, by humans via the CLI, and by other Agents via A2A. But in the enterprise, there is a massive world of legacy systems, mobile apps, and web frontends that still speak the traditional languages of the web: REST, gRPC, and GraphQL.

The challenge for most developers is "Interface Duplication." You build a tool for your AI Agent, and then you have to rewrite the same validation, security, and documentation logic to expose it as a REST API for your React frontend.

In this sixth article of our series, we look at how apcore turns your AI-Perceivable modules into universal web services using framework adapters like fastapi-apcore and flask-apcore.

The "Surface" Philosophy

In apcore, we treat different protocols as Surfaces. A surface is a thin layer that projects the internal logic of an apcore module into a specific network format.

By using framework-specific integrations, you can project your entire module Registry onto the web with zero duplication.

1. RESTful Auto-Mapping

With adapters like flask-apcore, your module executor.user.get_profile automatically becomes a REST endpoint:
GET /api/v1/executor/user/get_profile

The input_schema is used to validate the incoming JSON body or query parameters, and the output_schema ensures the response is consistent. This is done at the middleware level, ensuring your business logic stays "pure."

2. gRPC for High-Performance

For internal microservices, apcore integrations can generate Protobuf definitions on the fly, allowing your legacy Java or Go services to call your AI-Perceivable Python modules with binary efficiency.

Why Web Exposure is Better with apcore

When you use an apcore framework adapter, you aren't just getting an auto-generated router. You are getting the entire apcore Execution Pipeline:

  • Unified ACL: The same pattern-based access control that protects your modules from AI hallucinations also protects them from unauthorized web requests.
  • Trace Propagation: If a web request triggers an apcore module, the adapter captures the trace-id (or generates a new one) and propagates it through any internal module-to-module calls.
  • Schema-Driven Documentation: Your apcore description and documentation fields can be automatically exported as Swagger/OpenAPI docs for your frontend team.

Code Showcase: The Universal Backend

Imagine you are building a simple "Weather Module" using FastAPI. Here is how you expose it to the world:

# The AI-Perceivable Module
@module(id="common.weather.get", description="Get current weather for a city.")
def get_weather(city: str) -> dict:
    return {"temp": 22, "condition": "Sunny"}

# The Web Surface (FastAPI)
from fastapi import FastAPI
from fastapi_apcore import register_routes

app = FastAPI()
register_routes(app, registry) # All modules now have REST endpoints automatically
Enter fullscreen mode Exit fullscreen mode

One definition. Your AI Agent calls it. Your CLI tool calls it. Your React app calls it. Zero duplication.

Conclusion: The Bridge to the Future

The "Agentic Era" doesn't mean we throw away the web. It means we upgrade the web to be AI-Perceivable. Framework adapters ensure that your AI investment is also a "Web 2.0" investment, creating a bridge between your legacy infrastructure and your autonomous future.

Now that we’ve seen the power of the apcore Adapter Ecosystem, it’s time to go under the hood. In the next article, we’ll dive into the 3-Layer Metadata Philosophy that makes all of this possible.

This is Article #6 of the **apcore: Building the AI-Perceivable World* series. Build once, serve everywhere.*

GitHub: aiperceivable/apcore

Top comments (0)