Devlog 4 - Categorisation!

So in the previous devlog I added the DNS page and made it show records. I decided to add some categorisation tools to help you find important records, such as Mail, Tunnels, and Workers.

I’ll soon work on a search bar and showing details in the dashboard. After that, I’ll finish the other pages and add an onboarding flow.

As I worked on creating lots of elements at the start that follow a consistent design style, I am able to work a lot faster!

Devlog 3 - Showing Data!

So after doing a bit of research and playing around with Cloudflare, I was able to set up my API key and have it correctly show data when I pulled DNS records.

I also decided to migrate the app over to Electron. I primarily chose this because I was running out of time to complete the project, and didn’t want to add the stress of a database to hold API keys, login systems, and web hosting with so little time before the end of Stardance. However, unlike some of my other projects, this will work across macOS and Windows!

Because the whole point of the dashboard is to display data easily, I decided to show just the Type, Name, TTL and Proxy Status and the content. I used my existing table element I wrote previously and just set up the app so that the data is pulled when you go to the DNS page, and it will auto populate.

I also decided to make the sidebar collapsible to give more space to view things, and the next step I will be working on is building a small view for the DNS details on the dashboard. I’m planning to show how many records you have, the types of records, and have a small dropdown to see the different zones.

After that, I will just be displaying SSL status, Analytics, if available, and hopefully Cloudflare Tunnel details, such as uptime, if they are up or down, and their IPs.

# 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