I Replaced 5 Frontend Services With One TypeScript SDK

Jom Joam — Sat, 26 Sep 2026 23:02:50 +0000

Introducing GN-Apex: The Zero-Config Headless CMS & Telemetry SDK

Every modern web application eventually starts collecting dependencies.

A CMS for content.

An analytics SDK for events.

Another library for caching.

Another one for authentication state.

Another service for developer tooling.

Individually, none of these are particularly difficult.

The problem is what happens when they all have to work together.

You end up with environment variables scattered across dashboards, duplicated configuration, cache invalidation logic, different APIs for different services, and a growing amount of glue code that isn't actually part of your product.

I got tired of building that layer over and over again.

So I built GN-Apex.

And the result is @gnapex/sdk — a TypeScript SDK designed to bring content delivery, telemetry, rendering utilities, and developer tooling into a single developer experience.

The problem wasn't the services

The problem was the integration layer.

A typical Next.js project might look something like this:

Next.js
   │
   ├── CMS SDK
   │
   ├── Analytics SDK
   │
   ├── Authentication
   │
   ├── Cache / revalidation
   │
   └── Custom application glue

Every service has its own configuration.

Every service has its own lifecycle.

And eventually your application becomes responsible for making sure all of them agree with each other.

For a small application, that's manageable.

For a platform serving multiple projects, it becomes infrastructure.

That's the layer I wanted to eliminate.

Meet `@gnapex/sdk`

The basic setup is intentionally boring:

npm install @gnapex/sdk

Then your application can interact with GN-Apex through a single client.

The goal isn't to create another giant framework.

It's to provide a consistent interface for the infrastructure that sits underneath a modern web application.

1. Typed Headless Content

Fetching a page shouldn't require writing a custom API wrapper every time.

With the SDK:

import { notFound } from "next/navigation";
import { nexus, isNexusError } from "@gnapex/sdk";

interface BlogPost {
  title: string;
  body: string;
}

export default async function Page({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;

  try {
    const post = await nexus.getPage<BlogPost>(slug);

    return (
      <main className="mx-auto max-w-4xl px-4 py-10">
        <h1 className="text-4xl font-bold">
          {post.title}
        </h1>

        <div>{post.body}</div>
      </main>
    );
  } catch (error) {
    if (isNexusError(error) && error.status === 404) {
      notFound();
    }

    throw error;
  }
}

The important part here isn't just the API call.

The content is typed.

Your application knows what it's receiving.

And the SDK handles the communication with the GN-Apex content layer instead of forcing every project to reinvent the same client.

2. Content Rendering Comes With the SDK

A CMS is only useful if developers can actually render the content cleanly.

GN-Apex provides React rendering utilities for common content types.

For example:

import { NexusRenderer } from "@gnapex/sdk/react";

<NexusRenderer
  content={post.body}
  hydrateCharts
  enableImageInteraction
/>

The React package includes components for things like:

Rich text
Images
Code blocks
Maps
Galleries
Structured content

This means the CMS isn't completely separated from the application rendering layer.

The SDK understands both sides.

3. Analytics Without Another SDK

Analytics is another place where frontend projects accumulate dependencies.

GN-Apex exposes telemetry through the same client:

import { nexus } from "@gnapex/sdk";

nexus.analytics?.track("subscription_started", {
  plan: "pro",
  billing: "annual",
});

For purchases:

nexus.analytics?.trackPurchase({
  orderId: "ord_1024",
  total: 49,
  currency: "USD",
  products: [
    {
      id: "p_1",
      name: "Pro Tier",
      price: 49,
      quantity: 1,
    },
  ],
});

The idea is simple:

Your application shouldn't need to know which telemetry infrastructure is underneath it.

It should just describe what happened.

4. Web Vitals and Behavioral Telemetry

The telemetry layer can also collect application and user-experience signals such as:

LCP
CLS
INP
TTFB
Scroll depth
Dead clicks
Rage-click signals
Custom application events

The SDK batches telemetry before sending it to the GN-Apex infrastructure.

That matters because analytics shouldn't become the thing slowing down the application it's supposed to measure.

5. Privacy Controls Are Part of the Client

Telemetry creates an important engineering problem:

What should the application actually send?

GN-Apex provides controls for consent and data handling rather than assuming every application should collect everything.

For example:

nexus.analytics?.reset(true);

And telemetry configuration can be used to redact sensitive attributes before they leave the application.

The goal is not "collect everything."

The goal is to make telemetry useful while giving applications explicit control over what they send.

6. A Developer CLI

The SDK isn't only for production applications.

It also includes a CLI for local development:

npx apex init

Pull project content:

npx apex pull

Start the local visual environment:

npx apex studio

Push changes:

npx apex push

This creates a workflow where developers can work with local project state without constantly jumping between a browser dashboard and their editor.

The local workspace uses GN-Apex's project files and synchronization mechanisms to move between local development and the remote platform.

7. Why Build Another Platform?

This is probably the most important question.

There are already excellent CMS platforms.

There are already excellent analytics platforms.

There are already excellent developer tools.

GN-Apex isn't trying to pretend those products don't exist.

The motivation is different.

I wanted infrastructure where these pieces could understand each other.

Instead of:

Application
 ├── CMS
 ├── Analytics
 ├── Cache
 ├── Auth
 └── Developer tooling

the idea is:

                 GN-Apex
                    │
        ┌───────────┼───────────┐
        │           │           │
      Content    Telemetry   Developer
                              Tooling
        │           │           │
        └───────────┼───────────┘
                    │
                Application

One platform.

One SDK.

One developer-facing interface.

What I Learned Building It

The biggest lesson wasn't technical.

It was that developer experience is infrastructure.

A service can have an amazing API and still be painful to use if developers have to understand five different systems before they can ship something.

Reducing configuration is not just about saving a few lines of code.

It's about reducing the number of things developers have to keep in their heads.

That's the problem GN-Apex is trying to solve.

Getting Started

Install the SDK:

npm install @gnapex/sdk

Then check out the project:

GN-Apex: https://www.gnapex.com
npm: https://www.npmjs.com/package/@gnapex/sdk
GitHub: https://github.com/gn-apex/sdk

If you're building with Next.js, React, or TypeScript, I'd genuinely love to hear how you'd approach this architecture differently.

What would you put into a unified application infrastructure layer?

And more importantly:

What are you tired of configuring every time you start a new project?

DEV Community: Jom Joam