DEV Community: Njabulo

News4You: My Whole Morning in One Place

Njabulo — Mon, 26 Oct 2026 03:46:09 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

My morning information lives in different places: news in browser tabs, newsletters and delivery updates in Gmail, meetings in Google Calendar.

I built News4You, a personal daily newspaper that brings those pieces into one reading experience, with an ending.

Readers choose their interests, news feeds, reading length, timezone, and publication time. News4You turns public news and weather into a short, source-linked edition using Gemma.

Optional email and calendar snapshots sit alongside the news. Those personal details appear directly; they never pass through the AI editor.

The effort it saves is gathering everything before the day starts. Instead of checking several places, I wanted one place to answer: what’s happening, and what does my day look like?

Demo

Try News4You’s public demo

The demo needs no account or Gmail access. Personal examples are fictional and labelled.

Open the full application

Signed-in readers can configure sources, generate an edition, watch the draft arrive, and revisit saved editions. Optional Google connections add email and calendar snapshots.

See how it works

The explanation page includes architecture diagrams, the publication flow, and privacy boundaries.

Code

News4You repository

The code separates the dashboard, API, publisher, database, shared contracts, and core services.

How I Built It

News4You uses React, Vite, and TypeScript for the dashboard, with a Hono API on Cloudflare Workers. D1 stores preferences, generation runs, and editions.

Cloudflare Workflows runs publication jobs. An hourly Cron trigger checks for scheduled editions. The deployed application keeps publishing when my computer is switched off.

The editorial layer uses Gemma 4 26B A4B, wrapped in a Mastra agent and workflow.

Before calling the model, the publisher collects RSS and weather data, ranks relevant items, and checks for duplicates against published history. Readers can configure up to ten RSS or Atom feeds.

The editor receives at most twelve ranked public items. It produces structured content within the reader’s chosen reading budget.

Before publication, the application validates the structure, source references, and reading budget. These checks enforce the publication contract; they do not guarantee factual accuracy.

While generation runs, readers see progress stages and a growing draft. Draft content stays labelled until validation finishes.

For personal content, I chose a separate path:

Auth0 handles sign-in and Google-connected access through Token Vault.
Readers can select recent Gmail messages, a specific label, or no email.
Editions show subjects, senders, and received times for up to eight messages from the preceding 24 hours.
Email bodies and attachments are not collected.
Primary-calendar events appear for the edition date in the reader’s timezone.
Email and calendar snapshots never go to Gemma.

Google’s data-access review remains pending. The connection currently has an unverified-app warning and user limits; the public demo works without it.

An early publisher setup depended on my laptop. Moving it into Cloudflare was an important correction: background publication needed to keep working after I closed my computer.

Why Does Open Innovation Matter?

Gemma’s open weights make it possible to consider running the editorial model outside a single hosted API. Mastra’s open-source framework makes the agent and workflow code inspectable and adaptable.

My instructions, source-selection rules, validation, and reading limits live in the project. They are part of the application’s design.

The current deployment uses hosted inference. It is not offline or fully self-hostable yet.

That distinction matters. Open weights give me a possible local inference path; they do not automatically deliver one. Portable self-hosting is future work.

For this project, the value of open innovation is having room to change how the editor works and eventually where it runs.

My Agent Session

I used Codex throughout discovery, planning, development, testing, and deployment. I brought the product idea and constraints; the agent helped turn them into designs, code, and checks. Several of my corrections changed the architecture.

Discovery: decide what morning should feel like

I started with a personalised newspaper combining news, weather, email, and calendar events. My first instruction was: “Let’s discuss (not implement).”

We compared frameworks and explored delivery options, including email, PDFs, and printing. I narrowed the first experience to a website at /today. I also set a firm constraint: “I want free tier, I am not willing to pay for this hackathon.”

That ruled out the proposed paid GPU setup. I proposed a Cloudflare-based stack with Hono, D1, Auth0, Gemma, and Mastra. The agent helped work through how the pieces would fit.

Planning: turn the idea into testable work

I asked for requirements and a high-level design grouped into frontend, backend, async, AI, database, and DevOps. We then turned those groups into implementation tasks.

The plan covered more than generating text: authenticated ownership, explicit generation requests, source references, duplicate prevention, reading budgets, failure states, and scheduled publication. We chose one editor agent inside a controlled workflow.

I also supplied a reference project for the repository structure and simplified the proposed application paths. Development moved into a separate feature worktree, with instructions not to commit while I reviewed the code.

Development: use the product and challenge the design

The work grew through feedback from the running application. I configured services, completed consent steps, requested editions, and confirmed when I could read the result.

I asked for configurable RSS feeds, a rolling 24-hour email window, and calendar events below the edition’s source note. When generation felt slow, I asked whether readers could see content arriving like an AI chat. That became the live draft experience.

Privacy discussions changed the design too. Instead of sending personal content through hosted AI, I proposed generating the news and displaying personal details directly. The final hosted editor receives public sources; email metadata and calendar snapshots bypass it.

Testing: check the boundaries and the real journey

The agent added automated checks for authentication, reader isolation, database migrations, duplicate requests, source filtering, publication recovery, and streaming progress. The final recorded suite passed 114 tests across 22 files, alongside lint, formatting, type checks, and builds.

We also checked the application in a browser at desktop and mobile widths. With my approval, live checks covered Google connection, real generation, and reading a saved edition. Fictional fixtures covered personal-data cases without repeatedly reading my accounts.

Deployment: prove it works with my laptop out of the loop

The initial plan used GitHub Actions, and an interim publisher ran locally. I challenged that dependency: the application needed to keep working when my Mac was off.

Publication moved to Cloudflare Workflows with an hourly Cron trigger. With the local publisher stopped, both on-demand and scheduled generation completed in the hosted environment.

Deployment also exposed a model API billing mismatch. After I approved returning the project to Free tier, the agent corrected the configuration and repeated the hosted verification.

The session was useful because it made assumptions visible. I could question the cost, privacy, delivery, and hosting choices, then ask for evidence that the revised design worked.

The Lazy Payoff

The payoff is one place to begin the morning.

Public news comes with source links. Recent email subjects can surface newsletters or delivery updates. Calendar events show what is ahead. The reader can finish the edition and leave.

I tested real generation and Google-connected publication during development. I have not measured long-term time savings, so I am not claiming a number.

The project currently runs on free-tier services, with quota limits. When those limits are reached, generation can fail or pause; there is no paid model fallback.

For the “Slow and Steady” theme, my goal was a small automation with a clear stopping point: let the newspaper gather the morning, then let the reader get on with it.

Prize Categories

Best Use of Gemma: Gemma edits ranked public news and weather into structured, source-linked editions.
Best Use of Mastra: A Mastra agent and workflow execute the editorial step.
Best Use of Auth0 for AI Agents: Auth0 provides authentication and Token Vault access for optional Google-connected publication.

001 - This is OnglX deploy

Njabulo — Wed, 10 Sep 2025 08:30:00 +0000

Hey everyone! 👋

Super excited to share something I’ve been working on: OnglX Deploy 🚀

It’s basically a tool that helps you take control of AI infrastructure without the crazy costs or headaches of managing it yourself.

Here’s the problem: if you’ve ever tried running your own AI workloads, you know how painful it can be. Either you’re stuck paying high API costs to providers, or you’re lost in the weeds setting up cloud infra, Terraform, permissions, scaling, etc. It’s a nightmare.

That’s exactly what OnglX Deploy fixes.

Here’s what it does:

Your Cloud, Your Rules: Deploy AI APIs directly to your own AWS (and soon GCP) accounts. No vendor lock-in, no data privacy worries.
OpenAI-Compatible: You get the same API interface you already use, but running on your own infra.
Big Savings: Cut costs by 25–65% by skipping middleman markups and paying your cloud provider directly.
Developer-Friendly: One simple CLI command sets everything up—no endless configs, no hidden magic.
Extras Built-In: It even ships with an Open WebUI so you can interact with your models from day one.

Think of it like Vercel for AI, but instead of someone else’s servers, it’s your cloud. One command and you’ve got a fully running inference API on AWS.

I just shipped v0.1.43, our first production-ready release 🎉.

That means you can already:

Spin up an API in AWS with onglx-deploy init → onglx-deploy deploy
Run Bedrock models behind an OpenAI-compatible endpoint
Manage everything with a lightweight Go-based CLI that installs via
- Homebrew
  - brew tap onglx/homebrew-deploy-cli
  - brew install onglx-deploy
- npm
  - npm install -g @onglx/deploy-cli

I wanted the developer experience to feel effortless, but under the hood, it’s built on a strong foundation:

CLI Layer: A Go + Cobra-based CLI, a single static binary with zero dependencies.
Orchestration Layer: OpenTofu runner coordinating deployments, rollbacks, and state.
Infrastructure Layer: Embedded OpenTofu modules for AWS (and soon GCP).
Build System: Monorepo powered by pnpm + Turborepo for speed and consistency.
IaC: Everything defined in OpenTofu, fully embedded inside the CLI — no external module wrangling.
Automated Distribution: Binaries cross-compiled with GoReleaser and shipped across Homebrew and npm.

All that, so the experience for you is just one lightweight command.

Getting to this release wasn’t easy. A few big hurdles I solved along the way:

Distribution from a Private Monorepo: Package managers can’t pull from private repos, so I built public “release mirrors” (onglx/homebrew-deploy-cli, onglx/npm-deploy-cli) that automatically publishes binaries after every tag.
Platform-Specific Installs: Needed a way for Homebrew/npm to auto-detect OS + architecture and fetch the right binary. Custom install scripts solved it.
Complex Release Automation: Manual releases were painful, so I wired up GoReleaser + GitHub Actions to fully automate versioning, builds, and publishing.

The result? A smooth, one-command install across macOS, Linux, and Windows.

Still early days, but here’s the roadmap:

Next: OpenAI-compatible endpoint with GCP (Vertex AI + Cloud Functions)
Soon: streaming responses, custom domains + SSL, and better secrets management
Long-term: Multi-cloud, Azure support, and eventually expanding beyond inference into compute, storage, and databases.

If you’ve ever felt locked into someone else’s AI infra or sick of watching your API bill explode, this is for you.

Would love your feedback—and if you want to try it, docs are live here 👉 https://deploy.onglx.io

KIRO - The AI IDE that works?

Njabulo — Thu, 24 Jul 2025 07:00:00 +0000

Introduction

If you're a developer like me, you've probably experimented with AI coding tools like Cursor or Windsurf. And let's be honest, while they promise magic, they often deliver 'hallucinations' – losing context, butchering project structure, or completely misunderstanding your tech stack. It's frustrating, time-consuming, and frankly, defeats the purpose of 'assistance.'

That's why when I stumbled upon Kiro, a new AI IDE from AWS, my ears perked up. It's a bold promise? To bring structure to AI coding through a concept called spec-driven development. This isn't just another tool; it might be the breakthrough we've been waiting for.

Why It's On My Radar

Problem Solved: Taming the AI Beast

Kiro directly confronts the AI Hallucination problem. Instead of refining prompts endlessly, Kiro uses your detailed specifications to ensure the AI stays perfectly aligned with your project's vision, architecture, and existing codebase. Think of it as giving the AI a blueprint, not just a vague idea.

Core Concept: Code with the Blueprint

Forget prompting in the dark. Kiro's "Code with Spec" workflow is where the magic happens.

Requirements: You define what needs to be built.
Design: You detail how – architecture, data models, error handling, even testing strategies. This is where you establish the guardrails.
Tasks: Break down the work into actionable steps.

Only after you've approved these detailed specs does the AI generate code for each task, directly referencing your blueprint. This structured approach is a game-changer for consistency and accuracy.

Potential Impact: Beyond Just Code

Reducing AI hallucinations isn't just about faster coding; it's about shifting our focus. Imagine less time debugging AI-generated messes and more time on high-level problem-solving and innovative design. Kiro's approach could lead to:

Higher Code Quality: AI adheres to established designs.
Improved Maintainability: Code is generated with context and structure.
Faster Feature Delivery: Less rework, more production.

Industry Context: AWS's Secret Weapon?

Kiro occupies a unique niche. While Cursor and Windsurf are strong contenders, Kiro's AWS parentage is a significant differentiator. We could see deep integrations with AWS cloud services, potentially making it the go-to IDE for developers heavily invested in the AWS ecosystem. The buzz is real: a waiting list for access confirms its high demand.

Personal Insight & Experience

Setup & First Impressions

As a VS Code fork, setup was a breeze – instantly familiar, and yes, you can export your existing extensions. My initial impressions were largely positive. The "agent hooks" and "agent steering" give a sense of control previously missing. The main adjustment? The time. Going from ideation to final results isn't instant gratification; it requires that upfront spec work. But it's a worthwhile investment.

Pros & Cons

Pros:
- Unmatched Accuracy: The spec-driven approach dramatically reduces hallucinations.
- Detailed Workflow: Guides you through requirements and design, improving overall project planning.
- VS Code Familiarity: Low UI learning curve for existing VS Code users.
- AWS Backing: Potential for powerful cloud integrations.
Cons:
- Time Investment: The initial spec phase takes more time than quick prompting.
- Mindset Shift: Requires developers to embrace a more structured AI-assisted workflow.

Use Cases & Applicability

I see Kiro shining brightest for:

Team Projects: Ensuring consistent AI-generated code across a team, aligning with shared specs.
Complex Features: Tackling intricate features where context and structure are paramount.
Domain Alignment: Keeping the AI updated with current domain knowledge as features evolve.

The big learning curve isn't the UI, but getting developers to think differently about AI-assisted development – less "write me code," more "build this exactly according to my blueprint".

Broader Implications & Future Outlook

Kiro isn't just a tool; it's a statement. It's bringing back core software development best practices (planning, design, documentation) to the forefront of AI-assisted coding. This aligns perfectly with trends towards more robust, reproducible, and maintainable codebases.

I believe Kiro is poised to become a critical component in the development cycle, especially as AI continues to mature. It's the bridge between raw AI power and structured, enterprise-grade software development.

Conclusion

Kiro promises what many AI IDEs haven't delivered: reliable, context-aware code generation through a genius spec-driven approach. It's a trial that's showing immense promise for how we build software with AI. As Kiro puts it, it "helps you do your best work by bringing structure to AI coding with spec-driven development". I'm watching this space closely.

Have you used Kiro? What are your thoughts or experiences? Feel free to connect with me

Data Visibility: A Mongoose Middleware Case Study

Njabulo — Tue, 15 Jul 2025 07:18:23 +0000

Situation: Unapproved orders displayed

As part of a recent feature development, the objective was to empower procurement officers to initiate orders on behalf of various departments. A critical requirement was to prevent these orders from appearing on departmental dashboards until formally approved by the respective department manager.

Tasks: Architectural decision

Option 1: Decentralised Filtering: Modify every single query that retrieves orders across the application. This approach presented a significant risk of identifying and changing potentially dozens or hundreds of queries that would be time-consuming; the likelihood of missing a critical query or introducing subtle bugs was significant, and leading to future changes to data visibility logic requiring similar widespread modifications.
Option 2: Centralised Interception (Chosen): Leverage Mongoose middleware to intercept all data retrieval operations. This promised a more robust and maintainable solution by centralising the logic for filtering unapproved orders at the data layer.

Actions: Filter out unapproved orders

To facilitate the filtering, I needed a mechanism to mark orders that were pending approval explicitly. We added a new field, activeAction, to our orderSchema

The core of our solution lies in a pre-find middleware hook. This hook executes automatically before any find operation (including findOne, findById, etc.) on the Order model.

Results:

Clean and Accurate Dashboards: Only display approved and relevant order data and eliminating confusion.
Centralised Logic: The core filtering logic resides in a single, well-defined location within the orderSchema, making it easy to understand, debug, and modify.
Reduced Development Risk: We completely avoided the arduous and error-prone task of modifying numerous find queries throughout the application.
Scalable Pattern: This approach provides a reusable pattern for managing data visibility based on internal states, applicable to various entities beyond orders.

How do you use MongoDB middlewares? Share in the comments!

Resolving Unexpected Git Hook Changes

Njabulo — Tue, 08 Jul 2025 13:02:38 +0000

Situation: Unwanted file modifications

Recently, after merging a branch, my Pull Request unexpectedly showed numerous file changes that had minor auto-modifications (e.g., “Hello” to 'Hello') due to an active Git hook. These changes weren't part of my task, leading to a noisy and unclear PR.

Task: Isolate & Maintain Focus

Needed to:

Revert unrelated changes
Keep the PR diff focused on the current task I was working on

Actions: Step-by-step approach

Results: Clean PR

Restored the affected files to their original state
My PR was clean and contained only the relevant task changes

What are your go-to Git commands for managing tricky situations? Share in the comments!

NextAuth.js over Clerk

Njabulo — Wed, 24 Apr 2024 09:30:00 +0000

The prior article examined how Clerk may simplify user authentication for Next.js applications. Clerk provides a handy managed service option, but it's wise to weigh your options before making a choice. Today, we'll examine and contrast Clerk and NextAuth.js, two more well-liked authentication libraries for Next.js, to help you decide which is ideal for your project.

Why Next Auth instead of Clerk?

Control and Flexibility
- Self-Hosted vs. Managed Service: NextAuth enables you to fully self-host the authentication flow, giving you more control over user data and security procedures. Conversely, Clerk is a managed service, meaning that its servers hold your user data.
- Customization: NextAuth provides more flexibility, such as customizing the authentication procedure using callbacks, which are flexible enough to adjust to your unique requirements. The clerk's experience is more preconfigured, but you can still get some flexibility using webhooks
Community and Support:
- Larger Community: NextAuth benefits from a larger and more active developer community. You'll find more resources, tutorials, and support online if you encounter issues. Clerk, a relatively newer service, might have a smaller support pool.
- Integration Flexibility: NextAuth integrates seamlessly with various social providers and other authentication services. You can leverage existing libraries and solutions within your development stack.
Cost:
- Open-Source vs. Freemium: NextAuth is an open-source library with no direct cost for its basic functionalities. Clerk offers a free tier with limitations and paid plans for additional features and user management capabilities.

Setting Up Next Auth in Next.js

Install NextAuth
```
npm install next-auth
```

Configure NextAuth

Server

NextAuth.js will handle all queries to /api/auth/* (signIn, callback, signOut, etc.) automatically.

import NextAuth from "next-auth";
import GoogleProvider from 'next-auth/providers/google';

export const authOptions = {
  providers: [
    GoogleProvider({
      clientId: process.env.GOOGLE_CLIENT_ID,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET
    })
  ]
}

export default NextAuth(authOptions)

Client

Provider

import { SessionProvider } from "next-auth/react"

export default function App({
  Component, pageProps: { session, ...pageProps }
}) {
  return (
    <SessionProvider session={session}>
      <Component {...pageProps}/>
    </SessionProvider>
  )
}

Consumer

import { useSession, signIn, signOut } from "next-auth/react"

export default function Component() {
  const { data: session } = useSession()
  if(session) {
    return <>
      Signed in as {session.user.email} <br/>
      <button onClick={() => signOut()}>Sign out</button>
    </>
  }
  return <>
    Not signed in <br/>
    <button onClick={() => signIn()}>Sign in</button>
  </>
}

NextAuth.js is a compelling alternative to Clerk, offering developers greater control, flexibility, and cost-effectiveness. Its open-source nature, extensive community support, and seamless integration capabilities make it an attractive choice for Next.js applications. Whether you're looking for a self-hosted solution or prefer a managed service, NextAuth.js provides a robust and customizable authentication framework to meet your project's needs.

Auth with Clerk

Njabulo — Wed, 17 Apr 2024 15:00:00 +0000

It can be challenging to set up user authentication for web apps. Creating login flows, safely hashing passwords, controlling sessions, and integrating social logins are all part of the traditional process, guaranteeing optimal security. Luckily, there's a more effective method.

In a recent project, I investigated Clerk, a powerful solution for simplifying user authentication in Next.js applications. Let's explore why Clerk has become my preferred option and how it streamlines development.

Why Clerk Auth?

Forget about the time-consuming back-end configurations. With a wide range of capabilities aimed at improving the security and usability of your application, Clerk gives you the power to:

Embeddable UIs: Say goodbye to custom login forms! Clerk provides pre-built UI components like SignIn, SignUp, UserButton, and UserProfile that seamlessly integrate into your Next.js and other frontend frameworks supported by Clerk.
Authentication: Clerk offers a comprehensive set of authentication options, including:
- Multifactor Authentication (MFA): Add an extra layer of security with MFA to protect user accounts.
- Session Management: Includes maximum lifetime, inactivity timeout, and multi-session apps.
- Social Sign-On: Make logging into well-known social media sites like Google, Microsoft, and others easier.
- Email/SMS One-Time Passcodes (OTPs): Send verification codes via email or SMS to offer easy log-in.
- Magic Links: Simplify the login procedure by using links that, when clicked, provide access.
Flexibility: Integrate Clerk seamlessly with your preferred development stack:
- Frontend SDKs: Integrate Clerk with popular frontend frameworks like Next.js, React, React Native/Expo, and more.
- Backend SDKs: Leverage Clerk's backend SDKs for Node.js, Go, and other languages.
More
- Admin Dashboard: Manage user authentication and access control from a centralized, secure dashboard.
- Integrations: Expand your application's functionality by integrating Clerk with other services, such as Firebase, Supabase, and more.
- Webhooks: Stay informed about user activities through real-time notifications.
- Bot Detection: Clerk helps mitigate brute-force attacks with built-in bot detection mechanisms.
- B2B Suite: Build secure and scalable authentication experiences for your business-to-business applications.

Setting Up Clerk Auth in Next.js

Install Clerk
```
npm install @clerk/nextjs
```

Configure Clerk

By adding the following environments in .env.local

NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=<your clerk public key>
CLERK_SECRET_KEY=<your clerk secret key>

ClerkProvider

Provide authentication context to the rest of the application by wrapping around an app, such as root layout.tsx

...
import { ClerkProvider } from '@clerk/nextjs';

...

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}): JSX.Element {
  return (
    <ClerkProvider>
      <html lang="en">
        <body>{children}</body>
      </html>
    </ClerkProvider>
  );
}

Middleware

Clerk's middleware functionality in the Next.js middleware file handles authentication, protects routes, and ensures that only authenticated users can access them.

import { authMiddleware } from "@clerk/nextjs";

export default authMiddleware({});

export const config = {
  matcher: [ 
    "/((?!.+\\.[\\w]+$|_next).*)",
    "/(api|trpc)(.*)"
  ]
};

Configure type of auth strategy through a dashboard

Clerk supports authentication strategies such as password login, social authentication (allowing users to log in using their Google, GitHub, or other social network accounts. This feature enhances the user experience by providing a familiar login process), and more. To those auth strategies, you need to configure it in your Clerk dashboard.

Additionally, Clerk supports various authentication strategies, such as password login and social authentication, which can be configured seamlessly through the Clerk dashboard.

My journey with Clerk Auth has been nothing short of transformative. It's revolutionized how I approach user authentication, offering unparalleled simplicity without compromising security. Clerk isn't just a tool – it's a game-changer for Next.js development.

Facebook Introduces Meta AI in WhatsApp

Njabulo — Mon, 15 Apr 2024 07:00:00 +0000

Facebook has integrated Meta AI, powered by the Llama model, into WhatsApp, introducing an AI chatbot to enhance user interactions. This integration enables users to engage with AI assistants, offering a new dimension to their messaging experience.

While you can add Meta AI to group chats, it functions independently. It respects your privacy by not accessing your private conversations, and it doesn't analyze the history of the group chat before joining. It's important to note that this feature is currently in a limited rollout.

Currently, Meta AI offers basic functionalities. However, the future is promising. We can expect Meta AI to evolve into a powerful tool that can understand and participate in your conversations. This could include features like generating summaries of conversations, analyzing sentiment, or even helping you draft messages.

NB: There's more reads at My Blog Site

AI powered PostgreSQL Test Data Generation Tool (Cloudflare AI Challenge)

Njabulo — Sun, 14 Apr 2024 16:07:56 +0000

This is a submission for the Cloudflare AI Challenge.

What I Built

I built a serverless application using Cloudflare Workers and Hono, a lightweight web framework for Cloudflare Workers. The application is designed to generate steps for inserting random data into a PostgreSQL database and then convert those steps into SQL queries. This is achieved by leveraging Cloudflare's AI models to understand and generate natural language instructions, which are then converted into SQL commands.

Demo

My Code

REPO

The core functionality lies in the generate-data endpoint:

Extracting Schema: It retrieves the user-provided schema definition from the request body.
Initializing AI Models: It creates instances of two AI models:
- @hf/thebloke/deepseek-coder-6.7b-base-awq: This model understands natural language instructions and generates the steps in human-readable format.
- @cf/defog/sqlcoder-7b-2: This model takes the steps and schema definition, translating them into corresponding SQL code.
Prompting the Models
- The first model receives a prompt explaining the desired outcome and the provided schema.
- The second model receives the generated steps and the schema definition, combining the information for SQL generation.
Returning Data: The function returns a JSON response containing the generated steps and the corresponding SQL code.

Journey

Building this application involved several steps, from understanding the requirements to implementing the solution.

Understanding Cloudflare Workers: I started by researching how to use Cloudflare Workers and Hono for serverless applications.
Exploring AI Models: I explored Cloudflare's AI models to find one that could generate natural language instructions based on a given schema.
Integration and Orchestration: I implemented the logic to process the generated instructions and convert them into SQL queries.

Multiple Models and/or Triple Task Types

Multiple Models

The application demonstrates multiple AI models from Cloudflare's AI platform. The first model, @hf/thebloke/deepseek-coder-6.7b-base-awq, generates natural language steps for data insertion. The second model, @cf/defog/sqlcoder-7b-2, converts these steps into SQL queries. This showcases the flexibility and power of Cloudflare's AI platform in generating complex content based on simple prompts.
Triple Task Types

The application performs three main tasks:

Data Generation: It generates natural language steps for inserting data into a PostgreSQL database based on a given schema.
SQL Query Generation: It converts the generated steps into SQL queries.
API Endpoint: It exposes an API endpoint (/generate-data) that accepts a schema and returns the generated steps and SQL queries.

Challenges:
- Coordinating communication between the two LLMs.
- Prompts designs.
- Ensuring the generated SQL scripts are functional and adhere to the DDL and data constraints.

What I'm Proud Of

The ability to combine multiple LLMs to achieve a complex task like test data generation for databases.

What's Next

Experiment with different LLM combinations for improved performance.
Integrate user feedback to refine the generated test data scripts.
Local LLMs integration
Use LangChain SQL agent to retrieve database DDLs