# Devlog 1 - Design and Components

Over the last few weeks, I’ve been working on designing some custom components for CloudNext, so that I can use them later and save myself some time. I added the following:

• Sidebar - This component is the bar at the side with options to view the specific data pulled from API endpoints.

• Top Bar - This component is at the top, where you can see your authentication status (I added Auth, read more below on that!) and you can switch zones.

• Badge - This component is designed for small little notes, like whether something is active, has an error or another issue. It will also be used for what each DNS Record is for, as well as the type (MX, TXT, Tunnel, A, CNAME, etc.)

• Status Dot - This component is similar to the badge, but is just a small colored dot for lower priority events.

• Card/ZoneCard - This component is a card for details on analytics, and details on zone statuses.

• Table - This component is for DNS Records, so you can see them at a glance.

Authentication

So because it is of the utmost importance to keep your API keys safe, especially as I want to add DNS editing later, I decided to go with Clerk for handling authentication for the app. rather than designing my own system using Firebase, I wanted something used by large companies that I can trust is secure, and isn’t susceptible to issues I haven’t patched or noticed while configuring the app. 

I’m planning on using Prisma ORM and PostgreSQL with RLS to handle storing the keys, and I will obviously be hashing them so that they are highly secure. I also implemented access control, so you can’t type in certain dashboard details and automatically be into their dash, as you will be redirected to the login page.

I’ve decided to also integrate the clerk account details into the top bar of the app itself to keep the UI clean, and I’m hoping to adjust the account settings page and recode it to fit the existing design of the app. I attached a simple image of the elements I made so that you can see the design I am going for (kinda similar to Cloudflare and Linear.app).

Devlog 1 - API Building!

Hey! This is my first devlog for CloudNext, a Next.js-based dashboard using the Cloudflare API. I’m building this because I wanted something simple to check my Cloudflare stats without having to dig through all the menus.

Most of my time was spent creating and debugging the four API endpoints I’ve made so far. The debugging took much longer than expected because, in my infinite wisdom, I created the wrong type of API token (an Account Token instead of a User Token). No matter what I tried, every request was blocked. (I know… I’m so smart.)

The four endpoints I have working at the moment are:

• Zones Endpoint – Shows information about your Cloudflare-managed domains.
• DNS Endpoint – Lists all of your DNS records, and maybe in the future I’ll add the ability to create or edit records.
• Analytics Endpoint – Displays information like DNS query counts and other traffic analytics for your domains.
• SSL Endpoint – Shows your current SSL/TLS encryption mode and whether your certificates are active or valid.

Now that I have a working API, the next step is to build a nice-looking dashboard using placeholder data. Once the UI is finished, I’ll hook everything up to the live Cloudflare data.

The logic itself is actually pretty simple. Each endpoint just makes a request to the Cloudflare API and returns the response as JSON. I tested everything in Insomnia first because it gives really nice output for debugging. Here’s the Zones endpoint:

import { NextResponse } from "next/server";
import cf from "@/lib/cloudflare/client"; // This just imports the Cloudflare API Client 

export async function GET() {
  try {
    const zones = await cf.zones.list();
    return NextResponse.json(zones);
  } catch (error) {
    return NextResponse.json(
      { error: "Failed to fetch zones" },
      { status: 500 }
    );
  }
}

Anyway, thanks for reading this Devlog! Maybe the next one will be a bit shorter lol