DEV Community: Oleg Jakunin

I built OJ CMS because the editor should not have to understand my website

Oleg Jakunin — Mon, 12 Oct 2026 11:39:00 +0000

Open a CMS. Find the right section. Figure out which field actually appears on the page. Hope changing it does not disturb the layout.

That is a lot of background knowledge for someone who wants to update a product description.

When I built OJ CMS, I wanted to remove that background knowledge from the job. The editor should recognize the content and know what happens after saving it. The way I assemble the website should mostly be my problem.

OJ CMS is my custom administration interface on top of Payload. The public site uses Next.js and React. Content, inquiries and selected traffic information can live in the same workspace, with the interface adapted to the project.

The WordPress habit I wanted to break

I do not like starting a custom website by searching for a theme and then searching for plugins to repair the mismatch.

A catalog needs documents connected to products. A product needs specifications. An editor needs to know whether a record is published. None of that starts as a theme decision.

Yet it is easy to make the theme the center of the project. Then the business gets expressed through whatever the theme and its extensions happen to support. A requirement becomes a search for another plugin. A design change becomes an exception to someone else's layout system.

That is the default I wanted to leave behind. I want to decide what the site does, model its content and build its interface around that.

Writing your own software does not mean writing every layer

I did not write a new authentication system to prove that I am a developer. I did not invent a database abstraction for the same reason.

Payload provides the CMS foundation. I use it to describe content and build the behavior around it. OJ CMS is the layer where I make the editor experience specific.

Think about attaching a document to a product. That relationship should be part of the content model. The editor can select the document, and the website knows where to show it. Nobody needs to remember which text block contains the download link.

That sounds mundane. Good. Updating a catalog should be mundane.

The small decisions matter more than the dashboard screenshot

A dashboard can look impressive while telling you very little about what to do next.

I care more about whether an editor can find the record they just changed. Whether the interface makes a draft obvious. Whether leaving a page with unsaved changes feels different from leaving a saved page. Whether a media item already used by the website can be mistaken for something disposable.

Incoming inquiries belong close to the content that prompted them. Traffic information is useful when it helps someone decide what to update, rather than turning the admin into a wall of charts.

The design work is partly about removing irrelevant choices. An editor managing news and products does not need a miniature tour of my technology stack every morning.

A custom frontend gives me somewhere to put responsibility

I want control over the public website too. Its layout, interaction and mobile behavior should follow the project, not the limitations of a purchased theme.

With structured content, I can change how a product page renders without rebuilding its content. The same data can support a category listing, a detail page and a search result. An editor does not have to create three versions of the same information.

There is also less room to dodge the engineering work. If I ship oversized images or unnecessary JavaScript, that is mine to fix. If publishing does not update the website correctly, I need to fix that path. Installing a modern framework does not excuse any of those things.

That accountability is part of why I prefer this approach.

The custom screen still needs real permissions

One detail for anyone trying this with Payload: the Local API overrides access control by default. A custom server operation acting for an editor needs to opt into the access checks and pass the authenticated user.

Hiding an action in React is not permission enforcement. The server still has to decide whether the user can perform it. Payload documents the Local API options here.

This is the kind of complexity worth keeping in the code, rather than pushing into an editor's daily work.

What about EmDash?

EmDash is worth a look if you are exploring an Astro-based CMS. It offers another route into modern TypeScript publishing, including sandboxed plugins.

OJ CMS uses Payload. I am interested in EmDash because it asks some of the same underlying questions about how a CMS and its extensions should be put together. I would compare the editorial workflow and deployment requirements before picking a foundation for a new project.

Start with the thing your editor is trying to do

I am not interested in rebuilding familiar CMS features just to put my name on them. I am interested in the awkward gap between a generic admin and a particular website.

For OJ CMS, that meant treating products, documents, news and inquiries as things the interface understands. It meant keeping the public design independent of the editor. It also meant accepting that a custom interface is software I have to maintain.

The question I would ask before adding another plugin is: are we implementing the actual task, or teaching someone another workaround?

Which part of your current CMS makes editors learn something they should not need to know?

Writing and illustrations prepared with AI assistance.

I Kept Rebuilding LLM Provider Setup - So I Built a Small Go Gateway

Oleg Jakunin — Tue, 15 Sep 2026 19:00:37 +0000

There is a particular point in an AI feature where my energy tends to drop. The idea is working. I have a screen or a route I want to test. The prompt is good enough to learn something from a real response.

And then I am not testing the feature anymore.

I am finding the right provider key for this project, checking whether a model name still works, comparing a streaming response to a non-streaming one, and wondering whether the environment where I deployed the app can use the provider at all. None of that is dramatic work. It is just the same surrounding setup, again and again, sitting between me and the question I actually wanted to answer: does this feature help a user?

That repetition is why I built Go-Ai, a small HTTP gateway for my own projects. It gives application backends one stable place to send chat-completion requests while the gateway deals with provider-facing details. Its boundaries are deliberate: it is not a general AI platform, agent runtime, or replacement for the application that calls it.

Source: github.com/JakuninOleg/Go-Ai

I also wanted a real reason to spend time with Go. I had heard good things about it for years, but did not want to learn it through comparisons or a throwaway demo. A compact service with HTTP, configuration, streaming, and clear failure cases gave me a useful problem. Go was a pragmatic choice, not a claim that it is better than every alternative.

The friction was around the feature, not inside it

The clearest example for me was a development app where I kept trying chat, streaming, and later voice. Every improvement to the product surface meant revisiting the same provider chores: which key belongs in which environment, whether this host can reach that upstream, and whether a model slug that worked last month still exists. The feature itself was rarely the hard part. The surrounding setup was.

The applications I was building did not need a grand AI platform. They needed to ask a model a question, sometimes stream the answer, and occasionally move away from a provider-specific model name without hunting through several codebases.

Direct provider integrations make sense, especially for one small application. But with more than one app, credentials need safe homes, upstream model slugs can change, and provider availability can vary by environment or region. I did not want each new application to rediscover those constraints independently.

Before, each application carries provider setup alongside its own work. After, provider-facing concerns have one small home while applications keep product decisions.

There are already strong projects in this area. LiteLLM, LangChain, and Vercel AI SDK solve real problems, and I would reach for them when their broader coverage or integrations are what a project needs. I am not trying to replace any of them.

For my case, a wider framework or gateway meant learning more surface than the job required. I wanted a service I could follow from request to response and deploy next to my apps.

When I would not reach for Go-Ai:

one app, one provider, and the direct SDK is already fine
you need an agent runtime, tool executor, memory, or RAG pipeline in the gateway
you want a managed SaaS, dashboard, or billing layer instead of a small service you run yourself

A small gateway, not another application framework

An application backend sends an OpenAI-compatible chat request to Go-Ai, using a local alias rather than a provider model slug. The gateway resolves that alias and proxies the request upstream; the application keeps its user session, validation, rate limits, database access, and response shape.

That modest boundary gives provider credentials one server-side home and lets an upstream model change without a sweep through every application route. The detailed mechanics -- runtime alias selection, defined fallback classes, the route and SSE contract, audio proxying, and validation -- are in the companion article: Building a Small Go LLM Gateway with Explicit Boundaries.

Application wiring constructs three provider clients: Gemini and OpenRouter for the chat router, plus Groq for the separate audio service. I like that the wiring is ordinary and visible in cmd/api/main.go: configuration enters in one place, providers are constructed explicitly, and the chat and audio services have distinct responsibilities.

Voice stayed on the same principle. Speech-to-text and text-to-speech are separate proxy routes, not a new kind of chat request. The application decides whether an answer should be spoken; the gateway does not turn chat into realtime voice or an automatic speaking feature.

Tools belong with the application

Tool calling was where the boundary mattered most to me. Go-Ai can pass OpenAI-compatible tool-related payloads through, but it does not execute tools. The calling application knows who the user is, what they are allowed to do, which tenant or record they can access, and which side effects are acceptable. The gateway does not.

The gateway carries provider concerns; the application keeps the context required to make an authorization or business decision. Tool execution stays where that context exists.

In practice, an application receives a tool call, validates the user and arguments, performs the work against its trusted systems, and sends the follow-up message. It also keeps the complete tool-call message intact between turns, including any opaque provider metadata, instead of trying to rebuild it from a smaller shape. Provider credentials and the bearer secret stay in trusted server-side configuration; a browser talks to its application backend, not directly to the gateway.

Try it without adopting a new platform

The Go-Ai repository is the project itself, not a hosted product. You can run it beside an existing backend and decide whether its small boundary is useful.

Docker Compose is one supported option. Copy the example env, set your own secret and at least the Gemini key, then start it. OpenRouter stays optional unless you want its configured fallback path. Do not put real values in version control.

cp .env.example .env
# Edit .env: set GO_AI_SHARED_SECRET and GEMINI_API_KEY.
docker compose up -d --build

That starts the repository's Docker setup; it does not validate credentials or promise that an upstream provider is reachable from every host. A simple request from trusted server-side code can look like this:

export GO_AI_BASE_URL=http://localhost:8080
export GO_AI_SHARED_SECRET=replace-with-your-gateway-secret

curl "$GO_AI_BASE_URL/v1/chat/completions" \
  -H "Authorization: Bearer $GO_AI_SHARED_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "default",
    "messages": [
      { "role": "user", "content": "Say hello in one sentence." }
    ]
  }'

If you want the same boundary inside an existing frontend-backed app, start with the agent handoff: copy the guides into the target repo, keep GO_AI_BASE_URL and GO_AI_SHARED_SECRET server-side only, and ask the agent to propose the smallest migration before editing files. The browser must never receive the shared secret.

What I deliberately did not build

The omissions are as important as the code that exists:

No agent runtime or tool executor. Go-Ai does not plan agent steps, run tools, manage memory, or own a RAG pipeline.
No shared persistent state. It is not a durable store for application conversations or cross-instance state.
No broad resilience system. It is not a circuit-breaker, retry, or health-orchestration layer.
No full OpenAI API, dashboard, or billing layer. The gateway exposes the small route set it supports rather than imitating a larger product.

This is scope discipline, not a claim that those things are unimportant. If a future application needs full orchestration, a rich client SDK, billing, or broad provider management, I should choose a tool built for that job instead of stretching this one past recognition.

What I learned from keeping it small

The most useful result has been removing a repeat decision from the next project: one service boundary and one provider-side home for credentials instead of provider setup in every codebase.

Building it also gave my Go learning a practical shape: where HTTP errors belong, how to preserve a stream, which state should be local, and where not to hide responsibility.

My next focus is not to pile features onto Go-Ai. It is to keep the boundary reliable, document integrations clearly, and learn from the cases where the small shape stops being the right one. If you build or try something similar, I would value specific feedback: open an issue in the Go-Ai repository, or contribute a fix, test, or documentation improvement when you see a concrete gap. The most useful contributions will help keep the boundary honest rather than merely making it larger.