DEV Community: Joshua Olajide

Understanding Pointers in GO

Joshua Olajide — Fri, 09 Jan 2026 14:52:42 +0000

Introduction

Pointers are one of GO's most elegant features. Understanding them is the difference between writing code that just works and writing code that is efficient and also predictable.

In this article, we’ll demystify pointers using simple mental models and a real-world project example.

How it works

According to the official Go Documentation, a pointer holds the memory address of a value.

To visualize this, imagine you have a house:

The Value: This is the physical house itself.
The Pointer: This is the address of the house written on a sticky note.

If you give someone the sticky note (the pointer), they can go to your house and paint the front door red. If you don't give them the address, you are essentially sending them a photocopy (a copy) of a picture of your house. They can paint that photocopy all they want, but your actual house stays exactly the same.

The `&` and `*` operators

Go uses two primary operators to handle pointers. They may look confusing at first, but they have very specific functions

& (Address-of): This operator finds where a variable is sitting in memory.
* (Dereference): This operator lets you follow the address to see (or change) the actual value inside.

var p *int // The type *int means p is a pointer to an integer

package main

import "fmt"

func main() {
    name := "Alice"

    // & gets the memory address
    pointer := &name
    fmt.Println("Address:", pointer)   // Output: 0xc000014070

    // * accesses the value at that address
    fmt.Println("Value:", *pointer)    // Output: Alice
}

Copying vs. Pointing

Why does this matter? It comes down to how Go handles data in functions.

Pass-by-Value (Copying) When you pass a variable to a function in Go, it creates a copy by default. Changes inside the function stay inside the function.

func changeName(n string) {
    n = "Bob" // This only updates the copy!
}

// Result: original 'name' remains "Alice"

Pass-by-Pointer (Pointing) When you pass a pointer, the function modifies the data at the source.

func changeName(n *string) {
    *n = "Bob" // This follows the address and changes the original
}

// Result: original 'name' becomes "Bob"

Real World Scenario: The Food Ordering System

In a real system, you don't want to keep creating copies of a user's order every time they add an item that would be slow and lead to data bugs. You want one source of truth.

package main

import "fmt"

type Order struct {
    CustomerName string
    Items        []string
    TotalPrice   float64
    IsDiscounted bool
}

// We use *Order to ensure we are updating the actual order
func AddItem(order *Order, item string, price float64) {
    order.Items = append(order.Items, item)
    order.TotalPrice += price
    fmt.Printf("Added %s ($%.2f)\n", item, price)
}

func ApplyDiscount(order *Order, percent float64) {
    if order.IsDiscounted {
        fmt.Println("Discount already applied!")
        return
    }
    discount := order.TotalPrice * (percent / 100)
    order.TotalPrice -= discount
    order.IsDiscounted = true
    fmt.Printf("%.0f%% discount applied!\n", percent)
}

func main() {
    myOrder := Order{CustomerName: "John"}

    // Pass the address of myOrder using &
    AddItem(&myOrder, "Burger", 8.99)
    AddItem(&myOrder, "Fries", 3.49)
    ApplyDiscount(&myOrder, 10)

    fmt.Printf("Final Total for %s: $%.2f\n", myOrder.CustomerName, myOrder.TotalPrice)
}

Key Takeaways

Pointers (Memory Addresses) point to where data lives, not the data itself.
Pointers are great for large structs (like our Order) because you aren't copying the whole object every time you call a function.
Use & to create a pointer and * to read/edit the value it points to.
In Go, the zero value of a pointer is nil. Always ensure a pointer isn't nil before dereferencing it to avoid crashes.

PS: If your struct is small (like a single int), just pass the value. Use pointers when you need to modify the data or when the data is large enough that copying it would consume unnecessary memory.

Optimizing technical documentations for LLMs

Joshua Olajide — Fri, 29 Aug 2025 22:18:02 +0000

LLMs (Large Language Models) are already a part of many developers’ daily workflows, from writing and debugging code to exploring new libraries. The challenge is that these models have a knowledge cut-off; their training data only extends up to a certain point in time. This means they are often unaware of the latest tools, framework updates, breaking api changes etc. A framework released this year or a critical api update from last month might not exist for the model at all. You ask for a solution, and it confidently suggests code from a deprecated version, or worse, tells you the library does not exist.

The natural workaround will be to bring in your own documentation into the conversation. Developers often paste chunks of README files, api docs, or github issues into an llm chatbot and often times the problem is these sources aren’t always structured for LLMs. You end up copying boilerplate, irrelevant metadata, or text that doesn’t translate well into the model’s reasoning.

As LLMs become increasingly important for information retrieval and knowledge assistance, ensuring your documentation is LLM-friendly can significantly improve how these models understand and represent your products or services

This is where the idea of optimizing documentation for LLMs comes in. Instead of relying on outdated training data, you can feed models the exact context they need.

In this article, we’ll look at practical tools and approaches that make technical documentation more LLM-friendly, and how you can use them to cut down on hallucinations and get more accurate results.

Why documentation needs to be LLM friendly

When developers ask an LLM for help, the model pulls from the its training data. If your framework, library, or API documentation isn’t part of that data or if it’s written in a way that’s ambiguous the model will try to “fill the gaps” which often results in hallucinations, outdated code samples, or even missing context.

The main issue is that traditional documentation is written for humans. It assumes that the reader can cross check references, scan changelogs, and adapt examples to newer versions. LLMs don’t do this. They rely on explicit patterns in the text. If those patterns are vague or inconsistent, the LLM struggles to provide accurate answers.

LLM-optimized documentation ensures that AI systems like ChatGPT, Gemini, Claude, Cursor, and Copilot can retrieve and provide accurate, contextual responses about your product or API.

Some of the ways an llm friendly documentation can benefit developers:

Improved reliability of ai-assisted coding: When your docs are structured with predictable patterns (such as consistent headings, code annotations, and explicit parameter descriptions), LLMs are more likely to surface correct results.
Faster onboarding for new developers: Even if they aren’t using AI directly, new contributors benefit from the same clarity and structure.

Think of it this way; a human reader can skim through three paragraphs to find the right function signature. An LLM however, does not skim, it looks for exact matches. If the function signature is hidden in a sentence like you might also use init() for setup purposes, the model may miss it entirely. But if the function is presented in a dedicated code block with clear arguments and return values, making the documentation equally accessible and actionable for both humans and LLMs.

Practical techniques for llm friendly documentation

Creating documentation that is both developer friendly and llm consumable requires a balance between precision and readability.

Below are some of the practical techniques to ensure your docs serve humans first, while remaining optimized for AI

1. Use clear and consistent headings

Break content into small and well labelled sections.
Use a hierarchy (##,###) to reflect structure
Avoid vague titles and be more explicit. For example

Replace

Advanced stuff

With

Configuring OAuth 2.0 Authentication

2. Write concise, jargon-free content

LLMs (and humans) parse concise, imperative phrasing more effectively.

Replace

This function can maybe be used to fetch something like data

With

Use fetchData() to retrieve JSON from an endpoint

3. Pair every explanations with practical examples

Examples basically provide grounding for both the reader and the model. A technical documentation should always show a minimal working snippet alongside any concept

// Vague example
fetchData();

// Minimal but working example
import { fetchData } from "library";

async function main() {
  const data = await fetchData("/users");
  console.log(data); // -> [{ id: 1, name: "Josh" }]
}
main();

4. Avoid ambiguity and hidden context

Define acronyms when first introduced (e.g LLM (Large Language Model))
State defaults explicitly (e.g The timeout defaults to 30s if not set)
Avoid the use of it or this without clear references

5. Keep content current and accurate

Nobody likes outdated docs. Regular updates mean LLMs won’t give people wrong information about your latest features and updates.

6. Standardize formatting for APIs

Svelte's llm guidelines demonstrates how effective llm friendly documentation can be by publishing its api references in a plain text (llm.txt), highly structured format. Each function or component is described consistently with a clear signature, a concise explanation, its parameters, return type, and an example. By stripping away visual styling and navigational noise, the documentation becomes both scannable for humans and rich for machines.

This allows LLMs to reliably extract meaning, map queries to the correct methods, and minimize hallucinations. For example, when a developer asks about getUser, the model can point directly to its definition, parameters, and usage instead of inferring or fabricating details.

### `getUser(id: string): Promise<User>`

Retrieves a user by their unique `id`.

- **Parameters**
  - `id` (string): The user’s unique identifier.
- **Returns**
  - `Promise<User>`: A promise resolving to the user object if found.
- **Example**
const user = await getUser("123");
console.log(user.name);

Tools and approaches developers can use

Even with well structured docs, developers often need ways to make them more usable inside LLMs. As mentioned earlier; copying and pasting READMEs or API references is one option, but it usually brings along noise such as badges, changelog snippets, or irrelevant metadata. Fortunately, there are tools that help clean up, transform, and deliver documentation in formats that LLMs can reason about more effectively.

Gitingest: Gitingest according to the docs mentioned that it can Turn any Git repository into a simple text digest of its codebase. This is useful for feeding a codebase into any LLM. Gitingest can take a Github repository and convert it into plain text that's easier to feed into an LLM. Instead of manually pulling out individual files or copying messy markdown, you can point Gitingest to a repo and get a linear, text-first version of the code and documentation. This is especially useful when working with fast paced open source libraries where official docs may lag behind the latest commits.
Doc specific exports: Some libraries already publish documentations optimized for LLMs. Expo docs, for example provides an LLM-friendly export of their docs. Instead of navigating styled web pages or API explorers, you can download a single llm.txt file that is structured, consistent and ready to be shared with any model. This ensures that the information you load into an LLM is accurate and up to date.
Custom preprocessing: For projects without ready made LLM exports, you can preprocess docs yourself by stripping HTML, flattening headings, and removing non essential sections (like badges or marketing blurbs) makes the input cleaner. Even simple scripts that extract code examples, parameter tables, and sectioned markdown can drastically improve how a model interprets your documentation.
Embedding and retrieval pipelines: For larger codebases or libraries, consider using a Retrieval Augmented Generation (RAG) setup. By embedding your documentation and querying it on demand, you avoid token limits and keep responses scoped. Tools like LangChain or LlamaIndex make it easier to wire documentation into chat workflows so the model only pulls what’s relevant to the query.

Best practices checklist

To make your documentation LLM-friendly, focus on hierarchy, clarity, and structure. Below are some practical guidelines you can apply

Provide an llms.txt file: llms.txt is a proposed standard for making web content available in text-based formats that are easier for LLMs to process. llms docs page should be accessible by appending /llms.txt to the root URL of your docs site. The llms.txt file serves as an index for your documentation site, providing a comprehensive list of all available markdown-formatted pages. With this file, you make it easier for LLMs to efficiently discover and process your documentation content
Use concise, clear language: Use clear phrasing, avoid jargon, and define acronyms when they first appear
Add descriptions when linking: When linking to resources, include brief, information descriptions
Test your docs with LLMs: Run a tool that expands your llms.txt file into an LLM context file and test a number of language models to see if they can answer questions about your content

Example

Here's an example of llms.txt, in this case a cut down version of the file used for the FastHTML project (Full version here)

# FastHTML

> FastHTML is a python library which brings together Starlette, Uvicorn, HTMX, and fastcore's `FT` "FastTags" into a library for creating server-rendered hypermedia applications.

Important notes:

- Although parts of its API are inspired by FastAPI, it is *not* compatible with FastAPI syntax and is not targeted at creating API services
- FastHTML is compatible with JS-native web components and any vanilla JS library, but not with React, Vue, or Svelte.

## Docs

- [FastHTML quick start](https://fastht.ml/docs/tutorials/quickstart_for_web_devs.html.md): A brief overview of many FastHTML features
- [HTMX reference](https://github.com/bigskysoftware/htmx/blob/master/www/content/reference.md): Brief description of all HTMX attributes, CSS classes, headers, events, extensions, js lib methods, and config options

## Examples

- [Todo list application](https://github.com/AnswerDotAI/fasthtml/blob/main/examples/adv_app.py): Detailed walk-thru of a complete CRUD app in FastHTML showing idiomatic use of FastHTML and HTMX patterns.

## Optional

- [Starlette full documentation](https://gist.githubusercontent.com/jph00/809e4a4808d4510be0e3dc9565e9cbd3/raw/9b717589ca44cedc8aaf00b2b8cacef922964c0f/starlette-sml.md): A subset of the Starlette documentation useful for FastHTML development.

In conclusion

It is now evident that LLMs has become an integral part of how users discover, consume, and interact with technical contents, hence, optimizing your documentation for them is no longer optional but essential.

A few years ago, writing docs was primarily about making content accessible to humans. It is no longer the case today, it's now about writing the docs for two audiences at once; Human readers and AI systems that increasingly act as intermediaries.

By adopting practices like concise, structured explanations and LLM-friendly writing and implementing standards such as llm.txt and llm-full.txt, you not only future proof your documentation but also make it easier for AI systems to deliver accurate answers based on your content

Humans get clearer, more accessible documentation.
LLMs can amplify your docs, driving visibility, trust, and adoption of your product.

Basically, LLM-ready docs = better user experience for everyone

So, as you write or revise your next piece of documentation, keep this principle in mind to write for humans and optimize for machines :)

Meta prompt; Why your prompt alone may be limiting your LLM

Joshua Olajide — Thu, 24 Jul 2025 13:10:36 +0000

There's a good chance you are not getting the best out of your LLM (Large Language Model) not because the model isn't powerful enough, but because your prompt isn't.

Maybe you are too quick to ask a question before structuring your thought or it could be that you are not giving your LLM enough context. In my early days of writing prompts, I found myself doing something interestingly odd which is giving my rough prompt to another LLM just to see how it would rewrite or improve it and most times the results are often better, more structured and often closer to what I actually needed.

At the time, I didn’t have a name for this process. It just felt like I was refining a prompt through another prompt. But few weeks ago, I learned the actual term which is called meta prompting. That's when it all started making sense.

That’s when it all clicked :)

This post is for people like me who have dabbled in prompt engineering, maybe even practiced meta prompting without realizing it. And now, you want to do it more intentionally, to shape how your LLM think before it answers and getting the best of it.

What is meta prompting?

According to the white paper where it originated from, meta prompting is described as an effective scaffolding technique which is a way to organize and manage how a language model approaches a task, especially when the task involves multiple steps, contexts, perspectives, or modes of thinking.

But let’s break it down.

Meta prompting is what happens when you stop treating a language model like a tool that needs to be told what to do and start treating it like a system that needs to decide how to do something well.

Think back to the early wave of prompt engineering where everyone was obsessed with the expert roleplay trick

You are a senior software engineer. Given the following request…

I'm still quite obsessed with it though...

Then came a brilliant shift. What if, instead of telling the model what role to play, we asked the model to decide the best role for the task? What if we asked the model to design the optimal prompt for itself? Amidst the numerous "what if's"... That’s where meta prompting was born.

It’s a mindset shift: from giving commands to creating frameworks. For example, instead of writing a direct prompt like:

Write a landing page headline for a new SaaS product...

A simple meta prompt would go as thus

Design a prompt that would help generate a compelling landing page headline for a new SaaS product. Think through what details the model would need, what kind of tone would work best, and what process it should follow

With that one change, the model isn’t just a coder anymore it becomes a prompt engineer, a strategist, and sometimes even a teacher.

Meta prompting opens the door to collaborative prompting where you and the LLM think together about what the best next step is, rather than rushing to the final output.

From prompts to systems

Prompting at first glance feels straightforward. You ask a question or give an instruction, and the model gives you a response. But over time especially when the questions become layered or the tasks becomes more difficult, something becomes clear... simple or not well structured prompts often fall short.

You begin to notice that your outputs lack consistency. Or they sound close but not quite right. You tweak the wording, try again and again, chasing a result that feels just out of reach. Then you realize that maybe the problem is not with the word but the way the model is being asked to think.

That’s when prompting stops being a task and starts to feel like design.

The shift happens when you stop seeing the LLM as a tool you command, and start treating it as a system you can guide. Instead of telling it what to do, you begin to shape how it reasons. You lay out a structure; break the task into steps, evaluate different options, choose based on a goal, and reflect on what it just produced.

The word Meta prompting is not a fancy technique, it is a mindset. It is where you move from issuing requests to building processes. You start to treat your prompt like a blueprint, one that defines roles, sets expectations, and provides space for the model to explore, self-correct and even enhance the result.

It is no longer about getting a response. It is about helping the model arrive at better outcomes just because you designed a better path for it to walk through.

The conditions that lead to better outputs

You may get tired of writing prompts at some point and start wondering if your prompt could actually be better, this is where you begin to ask your self How can I phrase this to get a clearer or more accurate response? Then maybe, instead of rewriting it yourself, you ask the model to improve it for you.

Meta prompting isn’t about the output. It’s about shaping the conditions that lead to better outputs

The moment this becomes real is when your prompt is almost right but just not enough to get you the kind of output you want. You definitely know that the model can do more, the steps are there, the style is close. But something is missing which is structure, depth and clarity. And instead of refactoring your prompt manually, you can ask the model to help fix the way you are asking.

I saw a brilliant X post on meta prompt that captures this perfectly. Instead of writing a new prompt from scratch, it tells the model to act like an expert prompt engineer, understand the user's query, and return a well crafted version that’s clear, specific, and context-aware. In this case, the model is not just generating content but rather optimizing instructions.

Meta prompting also shines when you know the outcome you want but don’t know how to phrase it. You describe your intent, hand it over, and ask the model to design the path to get there. You stop guessing, and let the system co design with you.

The art of meta prompting

Most direct prompts such as Summarize this article will not give a desirable result.

The art of meta prompt is switching the LLM into a reflective mode. For example

How would a world-class research summarize this article to a beginner

is a subtle shift, but it changes everything. In this case, you are no longer treating the LLM as a tool that only executes instructions but as a collaborator who thinks through the task with you.

The art of meta prompting starts when you stop optimizing your prompt for the answer and start optimizing for the thinking that leads to that answer.

One of the easiest way to get there is giving the model a role. Not just You are an expert... but something more deeper such as A prompt designer A decision architect A senior software engineer with many years of experience. You use that role not to make it sound smart, but to push it to reason more deliberately.

I saw another interesting X post on meta prompt that nails it. Instead of asking the model to answer a query, the user gives it a mission instead Craft the best possible prompt to answer this user's goal And then it laters in context, quality guidelines, and evaluation standards (clarity, specificity, accuracy, reasoning etc). The model is asked to think like someone who optimizes thought itself and that request alone changes the kind of prompt it produces.

These are what makes meta prompting an art, there's no rigid formula; You are designing systems of thought, not just strings of text.

You can ask the model to critique it's own response then
Pass the response back to the model and ask How could this be made better?
You can break tasks into multiple sections, each with a different instructions or goal

The real art starts with one simple question

What kind of prompt would actually unlock the best in this model?

Some practical patterns and prompt

A good meta prompt doesn't always start with the perfect words, it usually starts with an intention. For example I want the model to think before it answers or I want the model to reflect on different options before it chooses, From there you design the structure that encourages that behaviour.

One approach is to begin with role. But instead of the usual You are an expert..., you can frame the role around the process you want. An example is

You are a prompt engineer tasked with crafting the clearest, most effective prompt to solve a user’s goal. Think through the goal, evaluate possible prompts, then output only the final optimized prompt.

Note that the above doesn't stop at the goal. It adds instructions that drive the model to reason, evaluate and refine before giving an output

Another pattern is feedback loops
This is where you ask the model to generate a response, then immediately critique it

Critique the above response based on clarity, accuracy, and depth. Suggest exactly how it could be improved.

Then ask it to rewrite based on that feedback. You’re building a self review system and all of it happens within one interaction. You can also split intent and execution

First, prompt the model with:

What steps should be taken to solve this problem thoroughly?

Then once it lists them follow with:

Now complete the task by following the steps above, one at a time

In each of these cases, you are not necessarily prompting the model to do, but you are prompting it to think through doing. That’s the distinction.

One final example; If you're designing content or strategy, you can layer multiple lenses. First, ask the model to generate raw ideas then, prompt it to assess those ideas based on specific goals (e.g clarity, impact, originality). Finally, ask it to improve or combine the strongest ones. Each pass adds depth, not noise. And each layer is a prompt in itself. The best part is that they are not advanced tricks but they are reusable patterns. And once you internalize them, you stop writing one off prompts and start creating systems you can rely on, no matter the task.

In conclusion

At the surface, prompting feels like giving instructions to a very smart machine. You say something, it replies. But as your expectations grow, you start to realize that the quality of the response depends less on how clever your question is, and more on how well you’ve structured the model’s thinking.

Meta prompting is the shift from speaking to a model to designing how it reasons. It’s not a hack or a trick. It’s a mindset. You start to treat the language model not as a genie that grants wishes, but as a system that can be guided, corrected, and improved (if you give it the right path).

This approach is especially powerful for those building tools, interfaces, or workflows around AI. You’re not just prompting for fun. You need reliability, structure, repeatability. Meta prompting gives you the scaffolding to build that.

Whether you're asking it to review its own work, define its own goals, simulate expertise, or reflect before it answers, you are no longer just writing prompts. You are building systems of thought.

And the more you do it, the more natural it becomes, you stop thinking in one shot instructions and start thinking in flows / patterns. You then realize that your job isn’t to control the model, but to co design how it reasons.

That’s where the real power lies. Not in what the model knows, but in how you shape the way it thinks

More prompt example

Example 1
Example 2
Example 3
Example 4

When AI steals the joy of creating

Joshua Olajide — Wed, 04 Jun 2025 12:07:29 +0000

There's a satisfaction that comes with creating that is so hard to explain, Ofcourse it's different for everyone; Is it the excitement that comes with chasing an idea or the exploration and eventually shaping it into something real. It is not just about the finished product, it's the late-night rabbit holes, the unexpected research that comes along the way, the small "aha" moments that make you want to keep showing up

But sometimes, without warning, that joy disappears!

Ever been in a situation where you feel overly excited about a new idea, then out of excitement you decided to share the idea with a friend and they weren't as excited about it as you were? Or only for them to nod nicely and say "Niceeeee"

Or in a similar situation where they are as excited but they gave you a detailed analysis of your idea, analyze it, build on it, reframe it... and somehow, in the process of seeing your idea laid out clearly, you lose the spark. The energy / excitement vanishes. Suddenly the idea feels finished; though you haven't even done anything on it yet.

Then you move on...
Then it happens again...
Until eventually, you are left wondering; why don't I feel like creating anymore?

The "friend" in this story? that's AI
The "you" that's me

I didn't see it coming at first. But the more I used AI to help shape my thoughts, the more I noticed a quiet tradeoff happening: clarity in exchange for creativity, Speed in exchange for spark, Convenience... at the cost of fulfilment.

The joy of the process

A few years ago, if you wanted to write about something technical, let's say an article on Golang; your first most likely stop would be the official documentation. From there, you'd dive into Google, hunting down blog posts, tutorials, white papers, articles, youtube videos and forum discussions to be able to gather a broad range of perspectives.

But you didn't just copy and paste. Instead, you absorbed all this information, piece by piece, until you fully have a better understanding about the topic. Along the way, you'd come across terms and concepts that you are not familiar with which then forced you to pause and dig deeper. You might even take some time off to experiment, research, and make sense of it all.

Only after this deliberate (sometimes slow) process can you piece together your findings into a coherent article that reflects your understanding. Writing a technical piece wasn't just about sharing facts; it was proof that you have developed a grounded knowledge of the subject. And with that understanding came confidence.

The confidence that you weren't just repeating information, but truly owned the topic

When AI skips the process

Fast forward to present where AI is now fully in the picture; Powerful, efficient, and also impressively fast. It has helped unblocked writers from creative ruts lol, speed up research, complete projects in record time and deliver answers without the usual deep dive down the rabbit hole lol.

But where is the joy!? No doubt that AI excels at removing friction, it however, often takes with it something far more valuable.

The messy middle

The messy middle as I love to call it is like the chaotic, uncertain space or finding the right "click" between idea and execution is where much of human creativity lives. It's where we struggle, discover, and evolve our thoughts into something richer. AI can obviously shortcut that process, sometimes even to the point where we like we are like spectators to our own ideas.

All it takes is one prompt

All it takes is one prompt, and it spits out polished answers before you've even had a chance to think things through. Yes! It's fast but how about the result? Content that might read well on the surface, but often lacks human touch, soul, no real connection to the audience, no hard-earned insights, just a pile of buzz words strung together by patten recognition.

When the process disappears, so does the sense of ownership. And without ownership, what are we truly creating?

You are not alone

The struggle is real, The excitement that fades out cannot be over emphasized and you are not the only one feeling it. That rush of excitement when a new idea hits? It's powerful. But just as quickly, it can vanish the moment AI turns your spark into a neatly packaged paragraph. You thought you were about to write something, but now it feels like it's already written, and somehow... not by you.

It's not that you didn't get what you asked for, in fact, you got it instantly. But the thrill? The curiosity? The messy exploration that made you feel in it may be gone with a single prompt. You are then left with staring at a finished answer, yet feeling creatively empty.

If you have felt this, you are not alone. Many creators are experiencing the same disconnect; a silent kind of burnout that doesn't come from working too hard, but from skipping the part that made the work meaningful in the first place.

Reclaiming the joy of writing

That constant feeling of not being enough is not a flaw, it's however a signal. It's a sign that you still care. That you are still full of ideas worth exploring. If anything, it means the spark is still alive.

AI doesn't have to be the thief of your creativity. It can be your creative partner, a co-pilot, not a ghostwriter.

Instead of outsourcing your ideas to a machine, start with your own messy, human draft then embrace the rawness, the imperfection, the questions. Invite AI to collaborate but not to take over but to sharpen, reshape, and challenge your thinking.

Use it to unblock yourself, explore alternatives, find patterns, or expand a thought; not to replace the joy of the process.

Here is an example prompt you can try: Act as a co-editor. Let's brainstorm on this idea together

You can even add reference links, articles, docs etc for extra context. That way, it becomes collaborative effort; your idea, your voice, enhanced by the tools you choose to work with

Because at the end of the day, writing is not just about hitting the 'publish' button. It's about making something that feels true to you.

A letter to self

AI isn't the enemy, However, it can quietly overshadow your voice only if you let it.

So take back the pen. Let the ideas breathe in its raw unfinished form, let the process be messy, curious and human.

And most importantly, let yourself feel proud -- not just of what you create, but how you create it.

You are still the writer. AI is just the assistant!

Build a REST API with Prisma, Node JS and Typescript.

Joshua Olajide — Sat, 11 Mar 2023 03:30:01 +0000

Introduction

The process of learning a new technology can often feel tedious, especially in the initial stages when you have yet to see it in action.

This article will guide you through the process of integrating these amazing technologies and demonstrate how to build a small application using them.

During the course of this article, we will develop a blog application that showcases how CRUD operations work in practice, with fundamental functions including:

Creating new posts
Retrieving all posts or a specific post
Modifying post content
And ultimately, removing a post
An additional feature we will implement is the inclusion of a like count for each post.

CRUD means CREATE, READ, UPDATE and DELETE

If you are interested in checking out the code, Check out the github repository here

Prerequisite

Before you proceed, it's important to be acquainted with the following set of tools:

Node.js and Express.js
TypeScript
Prisma

If you require a brief overview of Prisma, my blog post here can be a helpful resource.

Let's Get Started 🚀

Open up your terminal then create and navigate to your folder directory using the below command

mkdir prisma-typescript-blog && cd prisma-typescript-blog

Next, Initialize the project using yarn

yarn init -y

Then, Install the Dependencies

yarn add -D @types/express @types/node prisma ts-node-dev typescript

yarn add express @prisma/client

Finally, set up Prisma with the init command of the Prisma CLI:

npx prisma init --datasource-provider sqlite

This creates a new prisma directory with your Prisma schema file and configures Sqlite as your database.

Set up Prisma Schema

prisma/prisma.schema

datasource db {
  provider = "sqlite"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
}

model Post {
  id         Int      @id @default(autoincrement())
  title      String
  content    String
  likesCount Int      @default(0)
  createdAt  DateTime @default(now())
  updatedAt  DateTime @updatedAt

  // Relations
  comments Comment[]
}

model Comment {
  id        Int      @id @default(autoincrement())
  content   String
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt

  // Relations
  post   Post @relation(fields: [postId], references: [id])
  postId Int
}

In the above schema we define our Blog Models which includes Post and Comment

post   Post @relation(fields: [postId], references: [id])

This line of code means that there's a one-to-many relationship between the Post and Comment models. One post can have many comments, and each comment is associated with only one post. The postId field in the Comment model is used to reference the id field in the Post model.

Once you are done with this, Update your package.json to look like this:

{
  "name": "prisma-typescript-blog",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "scripts": {
    "start": "ts-node-dev --respawn --transpile-only --exit-child src/server.ts",
    "db:migrate": "npx prisma migrate dev --name user-entity --create-only && npx prisma generate",
    "db:push": "npx prisma db push"
  },
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "lib": [
      "es6",
      "dom"
    ]
  },
  "devDependencies": {
    "@types/express": "^4.17.17",
    "prisma": "^4.11.0",
    "ts-node-dev": "^2.0.0",
    "typescript": "^4.9.5"
  },
  "dependencies": {
    "@prisma/client": "^4.11.0",
    "dotenv": "^16.0.3",
    "express": "^4.18.2"
  }
}

start Starts the Node Js Server
db:migrate - Generate the migration file and Prisma Client
db:push - Pushes the Prisma schema to the database

Migration

At this point, you have a Prisma model but no database yet. Open your terminal and run the following command to create the SQLite database and the “posts” table represented by the model.

yarn db:migrate

After running the command, the Prisma CLI will analyze your schema and generate a migration file in the prisma/migrations directory.

Push the Prisma schema to the database:

yarn db:push

After synching the SQLite database with the Prisma schema, run npx prisma studio to open the Prisma GUI tool in the browser. Prisma studio allows you to view and mutate the data stored in the database.

By now, Your browser should automatically open a new tab and you will see something like this:

Project Structure 🚧

Edit your project structure to look like below

`prisma` -|
          `schema.prisma`
`src` -|
     `controllers`
          -| 
           `post.controller.ts`
     `routes`
          -|
           `post.route.ts`
     `server.ts`
.env
`tsconfig.json`

.env

DATABASE_URL="file:./dev.db"

Replace whatever is in your .env file with the above snippet

Let's move on to the fun part 💃

server.ts

import express, { Request, Response } from "express";
import { PrismaClient } from "@prisma/client";
import PostRouter from "./routes/blog.route";

export const prisma = new PrismaClient();

const app = express();
const port = 8080;

async function main() {
  app.use(express.json());

  // Register API routes
  app.use("/api/v1/post", PostRouter);

  // Catch unregistered routes
  app.all("*", (req: Request, res: Response) => {
    res.status(404).json({ error: `Route ${req.originalUrl} not found` });
  });

  app.listen(port, () => {
    console.log(`Server is listening on port ${port}`);
  });
}

main()
  .then(async () => {
    await prisma.$connect();
  })
  .catch(async (e) => {
    console.error(e);
    await prisma.$disconnect();
    process.exit(1);
  });

Quite a lot is going on here, so let me explain

prisma = new PrismaClient() - Creates a new instance of the Prisma client
The express.json() Registers middleware to parse incoming request bodies as JSON.
app.use("/api/v1/post", PostRouter); Registers API routes using the PostRouter module.
app.all("*",... Defines a catch-all route to handle unregistered routes and return a 404 error response.

When the main() function is called, it starts the Express server and connects to the database using the Prisma client. If there are any errors, it logs the error to the console and disconnects from the database.

The code serves as a starting point for building an API server with Node.js, Express.js, and Prisma ORM. It demonstrates how to handle API routes, connect to a database, and start a server that listens for incoming requests.

Routes

routes/post.route.ts

import express from "express";
import PostController from "../controllers/post.controller";

const router = express.Router();

router.post("/create", PostController.createBlogPost);
router.post("/createPostAndComments", PostController.createPostAndComments);
router.get("/getall", PostController.getBlogPosts);
router.get("/get/:id", PostController.getBlogPost);
router.put("/update/:id", PostController.updateBlogPost);
router.delete("/delete/:id", PostController.deleteBlogPost);
router.delete("/deleteall", PostController.deleteAllBlogPosts);
router.post("/like", PostController.likeBlogPost);

export default router;

These routes are pretty straight forward except for the /createPostAndComments route. Each route handles a specific HTTP method (POST, GET, PUT, or DELETE). The routes are mapped to methods defined in the PostController controller, which handles the logic for each of these routes.

The /:id portion of these routes is a parameter that represents a dynamic value that can be passed in the URL. The id parameter is a placeholder for a specific value, such as a unique identifier for a blog post.

The createPostAndComments will help us demonstrate a one to many relationship as it was defined in the Schema earlier.

In the Post Prisma model, there is a one-to-many relationship between Post and Comment, where one Post can have many Comments, but each Comment can only belong to one Post. This relationship is modeled in the Prisma schema using the comments field in the Post model:

model Post {
  id         Int      @id @default(autoincrement())
  title      String
  content    String
  likesCount Int      @default(0)
  createdAt  DateTime @default(now())
  updatedAt  DateTime @updatedAt

  // Relations
  comments Comment[]
}

As you can see, the comments field is an array of Comment objects, which represents the one-to-many relationship.

Controllers

controllers/post.controller.ts

import { Request, Response } from "express";
import { prisma } from "../server";

const createBlogPost = async (req: Request, res: Response) => {
  try {
    const { title, content } = req.body;
    const newBlogPost = await prisma.post.create({
      data: {
        title,
        content,
      },
    });
    res.status(200).json(newBlogPost);
  } catch (e) {
    res.status(500).json({ error: e });
  }
};

const createPostAndComments = async (req: Request, res: Response) => {
  try {
    const { title, content, comments } = req.body;
    const newBlogPost = await prisma.post.create({
      data: {
        title,
        content,
        comments: {
          create: comments,
        },
      },
      include: {
        comments: true, // Include the comments in the response
      }
    });
    res.status(200).json(newBlogPost);
  } catch (e) {
    res.status(500).json({ error: e });
  }
};

const getBlogPosts = async (req: Request, res: Response) => {
  try {
    const blogPosts = await prisma.post.findMany();
    res.status(200).json(blogPosts);
  } catch (e) {
    res.status(500).json({ error: e });
  }
};

const getBlogPost = async (req: Request, res: Response) => {
  try {
    const { id } = req.params;
    const blogPost = await prisma.post.findUnique({
      where: {
        id: Number(id),
      },
    });
    res.status(200).json(blogPost);
  } catch (e) {
    res.status(500).json({ error: e });
  }
};

const updateBlogPost = async (req: Request, res: Response) => {
  try {
    const { id, title, content } = req.body;
    const updatedBlogPost = await prisma.post.update({
      where: {
        id: Number(id),
      },
      data: {
        title,
        content,
      },
    });
    res.status(200).json(updatedBlogPost);
  } catch (e) {
    res.status(500).json({ error: e });
  }
};

const deleteBlogPost = async (req: Request, res: Response) => {
  try {
    const { id } = req.body;
    const deletedBlogPost = await prisma.post.delete({
      where: {
        id: Number(id),
      },
    });
    res.status(200).json(deletedBlogPost);
  } catch (e) {
    res.status(500).json({ error: e });
  }
};

const deleteAllBlogPosts = async (req: Request, res: Response) => {
  try {
    const deletedBlogPosts = await prisma.post.deleteMany();
    res.status(200).json(deletedBlogPosts);
  } catch (e) {
    res.status(500).json({ error: e });
  }
};

const likeBlogPost = async (req: Request, res: Response) => {
  try {
    const { id } = req.body;
    const likedBlogPost = await prisma.post.update({
      where: {
        id: Number(id),
      },
      data: {
        likesCount: {
          increment: 1,
        },
      },
    });
    res.status(200).json(likedBlogPost);
  } catch (e) {
    res.status(500).json({ error: e });
  }
};

export default {
  createBlogPost,
  createPostAndComments,
  getBlogPosts,
  getBlogPost,
  updateBlogPost,
  deleteBlogPost,
  deleteAllBlogPosts,
  likeBlogPost,
};

This controller is quite bulky, so I will go ahead and explain each method one after the other.

Our methods are listed as follows

createBlogPost
createPostAndComments
getBlogPosts
getBlogPost
updateBlogPost
deleteBlogPost
deleteAllBlogPosts
likeBlogPost

createBlogPost
This is a pretty simple method that accepts the title and content. It first destructures the title and content values from the req.body object, which is the request payload.

Also, it uses the create() method to create a new blog post in the database. This method returns a Promise, which is why the await keyword is used to wait for the operation to complete before continuing execution.

When a request is made to the http://localhost:8080/api/v1/post/create endpoint with the credentials included in the request body, the createBlogPost handler will be evoked to create a new blog post.

Postman is my preferred tool for testing all the endpoints, but feel free to use whichever testing tool you prefer.

createPostAndComments

The createPostAndComments method expects the request body to include a title, content, and an array of comments. The method then creates the new Post object using the create() method provided by Prisma, and includes the comments in the data object as well.

The Comment object will include the content field, as the postId field will be automatically set by Prisma when the Comment is associated with the new Post.

Finally, the include parameter is used to include the comments for the newly created Post in the response.

Here is how the payload and response looks like

updateBlogPost
This method first extracts the id, title, and content properties from the request body using object destructuring.

It then uses Prisma to update the blog post with the specified id. The update() method is called on the post model, passing in an object that specifies the where and data clauses. The where clause specifies the unique identifier for the blog post to be updated, while the data clause specifies the new values for the title and content properties.

likeBlogPost
This method first extracts the id property from the request body. This id represents the unique identifier of the blog post to be liked.

It then uses Prisma prisma.post.update() to update the specified blog post. The update() method is called on the post model, passing in an object that specifies the where and data clauses. The where clause specifies the unique identifier for the blog post to be updated, while the data clause increments the likesCount property by 1 using the increment keyword

Here is it in action

When a request is made to the http://localhost:8080/api/v1/post/like endpoint passing id as body, It then invokes the createBlogPost handler and likesCount will be incremented

All other methods are quite similar to what has been covered so I won't be going over them

After all these steps, Be sure your server is still running if not run yarn start to get it up and running.

In Conclusion

This article demonstrates how to apply your knowledge of this amazing tools by creating a blog API using Node, Typescript, and Prisma. Additionally, the tutorial covers the process of connecting the API with a SQLite database.

Congratulations on reaching the end of this article! If you found it helpful, please consider giving it a thumbs up and leaving your comments below.

See you in the next 😉🚀

DEV Community: Joshua Olajide

Understanding Pointers in GO

Introduction

How it works

The & and * operators

Copying vs. Pointing

Real World Scenario: The Food Ordering System

Key Takeaways

Optimizing technical documentations for LLMs

Why documentation needs to be LLM friendly

Some of the ways an llm friendly documentation can benefit developers:

Practical techniques for llm friendly documentation

Tools and approaches developers can use

Best practices checklist

Example

In conclusion

Meta prompt; Why your prompt alone may be limiting your LLM

What is meta prompting?

From prompts to systems

The conditions that lead to better outputs

The art of meta prompting

Some practical patterns and prompt

In conclusion

More prompt example

Further reading

When AI steals the joy of creating

The joy of the process

When AI skips the process

You are not alone

Reclaiming the joy of writing

A letter to self

Build a REST API with Prisma, Node JS and Typescript.

Introduction

Prerequisite

Let's Get Started 🚀

Set up Prisma Schema

Migration

Project Structure 🚧

Let's move on to the fun part 💃

Routes

Controllers

In Conclusion

The `&` and `*` operators