The catch is cost. Claude Code runs against Anthropic's API by default, and an agentic coding session burns through tokens fast. Every file it reads, every edit it makes, every command it runs is all being billed.

But then, Claude Code doesn't actually need to talk to Anthropic. It just needs something that speaks its API format. And there's a free tool that does exactly that.

Option 1: Run Claude Code for Free Using OpenRouter

What is OpenRouter?

OpenRouter is a platform that gives you access to dozens of AI models from different companies — Meta, Google, Alibaba, Mistral — through a single API. Many of these models have a free tier, meaning you can use them without spending anything.

The reason this works with Claude Code is that OpenRouter already speaks Anthropic's message format. So instead of pointing Claude Code at Anthropic's servers, you redirect it to OpenRouter, pick a free model, and everything works the same way.

Same interface. Same agentic workflows. Someone else's compute budget.

What You'll Need

• Claude Code installed (npm install -g @anthropic-ai/claude-code)
• A free OpenRouter account at openrouter.ai
• A terminal

That's it. No special hardware. No GPU. Works on any machine.

Step 1: Create an OpenRouter Account

Go to openrouter.ai and sign up. Verification is quick.

Once you're in, navigate to the API Keys section in your dashboard and create a new key. Copy it — you'll need it shortly.

Step 2: Pick a Free Model

In your OpenRouter dashboard, go to the Models section and filter by free. Free models are marked with a :free suffix in their model ID.

Good options for coding tasks:

• meta-llama/llama-3.3-70b-instruct:free — Meta's 70B model, strong at reasoning and code
• google/gemma-3-27b-it:free — Google's Gemma 3, solid general performance
• qwen/qwen3-8b:free — Alibaba's Qwen3, good at code specifically

For serious coding work, the Llama 3.3 70B free tier is the strongest option available at no cost. It will outperform most small local models by a significant margin.

Copy the full model ID of whichever you choose.

Step 3: Configure Claude Code

Open your terminal and run these three export commands, replacing the placeholders with your actual values:

export ANTHROPIC_BASE_URL=https://openrouter.ai/api
export ANTHROPIC_AUTH_TOKEN=your-openrouter-api-key
export ANTHROPIC_API_KEY=""

A few things worth knowing:

• ANTHROPIC_BASE_URL redirects Claude Code away from Anthropic and toward OpenRouter
• ANTHROPIC_AUTH_TOKEN is where your OpenRouter key goes
• ANTHROPIC_API_KEY must be set to empty — this prevents Claude Code from trying to authenticate with Anthropic directly

These variables apply only to your current terminal session. If you open a new terminal window, you'll need to run them again. To make them permanent, add the three lines to your ~/.zshrc or ~/.bashrc file.

Step 4: Launch Claude Code

In the same terminal window where you set those variables, navigate to your project folder and run:

claude --model meta-llama/llama-3.3-70b-instruct:free

Replace the model name with whichever one you chose from OpenRouter's free list.

Claude Code will start up and behave exactly as it normally does. You can ask it to read files, write code, run tests, debug errors — the full workflow.

What to Expect

Free tier models on OpenRouter have rate limits. If you hit one, you'll see an error message and need to wait a few minutes or switch to a different free model. Adding even a small credit balance to your OpenRouter account (a few dollars) removes most of this friction.

Performance is real. The 70B models available on OpenRouter's free tier are genuinely capable for most coding tasks. They won't match Claude Opus on complex architectural reasoning, but for writing functions, debugging, refactoring, and explaining code, they hold up well.

Option 2: Run Claude Code for Free Using OpenRouter

Download Ollana at ollama.com/download. It has cloud-hosted models accessible through the same interface you use for local ones.

Then run Claude Code with:

1. Open Ollama and sign in. Make sure to enable cloud models.
2. Open your terminal and type in ollama launch claude and hit Enter.
3. Select a recommended Cloud model, and that is it.

You can use Claude Code as normal. And this is a cloud model so it runs fast.

This is the easiest path if Ollama is already part of your workflow. The compute still happens in the cloud. It just routes through Ollama's interface.

The Bottom Line

Claude Code is designed to work with a variety of models. Features like the agentic interface, file reading, and terminal commands do not depend specifically on Anthropic's models. OpenRouter and Ollama allow you to use this interface with free models that are truly capable of handling real coding tasks.

This article is about how to start a blog as a clinician, why it matters more than ever in 2025, and what happens to your career when you do.

The Numbers Are Hard to Ignore

Medical misinformation is at an all-time high. 82% of adult social media users now report encountering false or misleading health information online, and 1 in 5 Americans turns to TikTok for health advice before speaking to a doctor. The demand for credible clinical voices on the internet has never been greater — and most of the search results people find are written by marketers, not clinicians.

At the same time, research on clinicians and online content creation reveals something striking: only about 1% of healthcare professionals who are online are actually producing original content — writing blogs, publishing articles, building forums. The other 99% are reading, scrolling, or occasionally commenting. That gap is not closing fast. Which means if you start a blog today, you are still entering a largely uncrowded space.

Meanwhile, the healthtech sector is pulling clinicians into new roles faster than most people realise. The global AI in healthcare market was valued at $21.66 billion in 2025 and is projected to reach $110.61 billion by 2030. These companies need clinicians — not just to advise on products, but to communicate them. They need people who understand medicine and can write, explain, and build trust with healthcare audiences. A blog is how you signal that you are one of those people.

And then there is burnout. 49% of physicians reported burnout in Medscape's 2024 survey — a number that has remained stubbornly above 45% for over a decade. Many are quietly looking for what comes next, or at least for something alongside clinical practice that doesn't drain them further. Writing, for a lot of clinicians who try it, turns out to be the opposite of draining.

What a Clinician Blog Actually Does For Your Career

Let's be specific, because "build your personal brand" is advice that sounds good and means nothing.

It creates a public record of your thinking. When a healthtech founder Googles your name before a call, or a journal editor looks you up before accepting your pitch, or a conference organiser tries to decide whether to invite you — what do they find? A blog gives them something real to read. It shows how you think, what you care about, and whether you can communicate.

It opens non-traditional clinical roles. Clinical writing, clinical advising, medical affairs, healthtech consulting, policy advocacy — all of these roles exist, and all of them are growing. Most of them go to clinicians who already have a public presence. A hiring manager at a digital health startup looking for a clinical lead is not posting on LinkedIn hoping an anonymous clinician applies. They are finding the people who are already talking about the problems they are trying to solve.

It builds a patient-facing reputation. If you run a practice or plan to, your blog is how patients decide whether to trust you before they ever book an appointment. 84% of patients now check online reviews and information before choosing a new provider — and 63% will choose one provider over another specifically because of a strong, informative online presence.

It compounds over time. A well-written article about a topic in your specialty can bring in readers for years. Unlike a tweet that disappears in 48 hours, a blog post is indexed by search engines and continues working for you long after you've moved on to writing the next one.

Physicians Who Did It — And What Happened Next

These are not hypothetical outcomes. They are documented stories of clinicians who started writing and watched their careers expand in ways clinical training never made possible.

Dr. Kevin Pho — KevinMD.com

In 2004, Dr. Kevin Pho, a primary care physician in New Hampshire, wrote a short post about a drug recall. A patient reached out to say the article had comforted them. That was the moment he realised clinicians could have a meaningful voice beyond the exam room. He kept writing. Twenty years later, KevinMD is one of the largest physician-written platforms in the world, receiving over 3 million monthly page views. What started as a blog became a speakers bureau, a coaching practice, a podcast, and a co-authored book on physician online reputation. None of that was planned. All of it followed from the decision to write consistently and in public.

Dr. Tammie Chang — Pediatric Oncologist and Community Builder

Dr. Tammie Chang is a practicing pediatric oncologist who used her online writing and platform to do something most clinicians consider impossible: build multiple careers simultaneously. Her work online helped her grow communities of over 125,000 verified physician members, author two bestselling books, and earn coverage in Forbes, CNN, and the Washington Post. She was named a LinkedIn Top Voice in Healthcare in 2020. She did not stop practising medicine. She expanded what medicine meant for her.

The pattern in both stories is the same. They started writing about what they already knew. They were consistent. They let the audience find them. And opportunities — speaking, publishing, advising, building — followed the visibility.

What to Write About

The best clinician blogs are not textbook summaries. They are a clinician's perspective on things people are actually searching for: how a diagnosis feels from the inside, what a test result means in plain language, why a treatment works the way it does, what you would tell a patient if you had more than 10 minutes.

You do not need to write about everything. The most powerful blogs are narrow and consistent. Pick a lane — your specialty, a patient population you care about, the intersection of medicine and technology — and write from inside it.

Some starting points that tend to work:

• "What I wish patients knew about [condition]"
• "What actually happens during [procedure]"
• "How I explain [diagnosis] to my patients"
• "Why I think AI will / won't change [area of medicine]"
• Case discussions (anonymised, with ethical principles applied)
• Reflections on clinical training, medical education, or the healthcare system

These are not just good for your readers. They are the exact topics people are searching for.

How to Set Up Your Clinician Blog

This is where most clinicians get stuck — not from lack of ideas, but from the wrong mental model. A clinician blog is not a technical project. It is a professional home. You want it to look credible, load quickly, and tell visitors exactly who you are and what you do.

Here is what you need:

1. A place to host your profile and writing. This is your home base. It should include your clinical background, your specialty, your credentials, and a way for people to contact or follow you. The simpler this is to set up, the sooner you will actually use it.

2. A domain that looks like you. yourname.com or yourname.bio — not a subdomain on a platform you don't control. When you write something good, you want people to remember where it lives.

3. A place to publish articles. This can be a blog section on your personal site, a Substack newsletter, or both. What matters is that it is yours, that it is easy to update, and that it does not require you to learn to code.

4. A consistent publishing rhythm. One article a month is enough to start. Two is better. The goal is consistency over volume — a blog with 12 well-written articles is more useful than one with 3 brilliant ones and a year of silence.

Where Ulna Fits In

Ulna (ulna.bio) was built specifically for clinicians who want a professional online presence without the friction of building a website from scratch.

You get a personal portfolio page with your credentials, specialty, work history, and links — all in a format designed for healthcare professionals. You can add your publications, your research, your speaking engagements, your blog. You can claim a clean personal URL. And you can set it up in under 30 minutes, without touching code.

Think of it as the clinical equivalent of a developer's GitHub profile — a place that shows what you know, what you've done, and what you're building. When you start a blog, Ulna is where that blog lives alongside everything else that makes you credible.

If you want to see what it looks like, head to Ulna and set up your profile. It's free to get started, and the first thing it will show you is how complete your professional presence actually is — which, for most clinicians, turns out to be more incomplete than they expected.

The Cost of Waiting

Here is the thing about clinician visibility: the window does not stay open forever.

Every specialty has a small number of clinicians who have already built a public presence. They are the ones who get invited to advisory boards, quoted in healthtech press releases, and approached for clinical writing contracts. They are not necessarily smarter or more experienced than their peers. They are just visible.

The gap between "clinician with a blog" and "clinician without one" is not a gap in knowledge. It is a gap in who gets found.

You have spent years building clinical expertise that most people in the world will never have. A blog is how you let that expertise travel further than the rooms you work in.

Start small. Write what you know. Build the thing.

Ulna is a portfolio and profile builder for clinicians. If you're ready to build your professional online presence, get started at ulna.bio.

1. The Most Important Skill: Prompt Engineering

Prompt engineering is just knowing how to talk to AI well. The better your question, the better the answer.

The formula: Role + Context + Format

Bad prompt: "What's the treatment for malaria?"

Good prompt: "You are an infectious disease specialist. My patient is a 28-year-old pregnant woman in her second trimester with uncomplicated falciparum malaria in a chloroquine-resistant region. What is the safest first-line treatment and why? Give your answer in bullet points."

Same question. Completely different output. The second one is actually useful at the bedside.

Tips:

• Always give the AI a role ("You are a cardiologist...")
• Add patient context (age, comorbidities, relevant history)
• Tell it the format you want (bullet points, table, plain paragraph)
• If the answer isn't good enough, say "be more specific" or "simplify this for a patient"

Read more: Prompt Engineering for Clinicians

2. Tools Worth Knowing

General AI Assistants

Use these for drafting letters, summarising papers, explaining diagnoses to patients, studying, and clinical reasoning.

• ChatGPT
• Claude
• Gemini

For clinical-specific questions with referenced literature, use:

• OpenEvidence

OpenEvidence answers medical questions using real published studies. More reliable than general LLMs for bedside decisions.

AI Medical Scribes

These tools listen to your consultation and generate a structured clinical note automatically.

• Nabla
• Abridge
• Nuance DAX

You stop typing mid-consultation. You look at your patient. The note writes itself.

Vibe Coding Tools (Build Without Coding)

These let you describe what you want in plain English and the AI builds it for you. No coding knowledge required.

• Cursor
• Claude
• Lovable (personal fav)
• Bolt
• Replit

What you can actually build as a doctor:

• A patient follow-up tracker for your ward
• A triage checklist app
• A referral letter template generator
• A personalised study quiz based on your weak areas
• A simple tool to explain diagnoses to patients at different literacy levels

You describe it. The AI builds it.

Medical Literature & Research

• OpenEvidence
• Consensus
• Elicit
• Perplexity

Use these to search research questions and get evidence-backed summaries faster than PubMed.

3. Courses to Take

AI 101: A Practical Guide for Clinicians

Free. Self-paced. Built specifically for clinicians and medical learners getting started with AI. https://dochobbs.github.io/ai101/index.html

Start here if you want zero fluff and immediate practical value.

Google's Introduction to Generative AI

Free. 45 minutes. Gives you a solid conceptual foundation. https://www.cloudskillsboost.google/courses/536

Good for understanding what AI actually is before you start using it.

AI in Healthcare Specialization — Stanford on Coursera

Paid (Coursera subscription). Structured and clinical. Built by Stanford faculty. https://www.coursera.org/specializations/ai-healthcare

The most rigorous option on this list. Worth it if you want to go deep.

4. Where to Stay Updated

• BMJ Digital Health
• JAMA Network (search "artificial intelligence")
• LinkedIn — follow clinicians and researchers working at the medicine-tech intersection

The conversation is happening in public. You just have to show up to it.

5. One Rule to Never Break

AI hallucinates. It can sound confident and be completely wrong. Never paste AI output directly into a patient's chart without reading and verifying it. Treat AI like a smart but occasionally unreliable colleague — useful, but not unsupervised.

Build Your Presence as a Clinician Who Gets This

If you want to start showing up online as a doctor who understands where medicine is going, build a portfolio.

Ulna — Free clinician portfolio tool with personal domains and prebuilt templates. Built for doctors.

This guide covers everything: React's cache() function, Next.js's new use cache directive, cacheTag, revalidateTag, unstable_cache, the full request lifecycle, and the mental models you need to reason about all of it confidently.

By the end, you will know exactly what caches exist in Next.js, when each one activates, how they interact, and the practical patterns that separate production-grade apps from the rest.

Related: If you want implementation-ready patterns, production-tested snippets, and architectural diagrams specifically for caching in Next.js App Router apps, I go much deeper in the Next.js Caching Handbook — built for Next.js developers shipping real products.

Why caching in Next.js is different (and harder) than you think

Most developers approach caching reactively. Something is slow, so they add a cache. Something is stale, so they bust the cache. This works fine in simple apps but falls apart fast in Next.js, for one reason: there are multiple caches operating simultaneously at different layers, and they do not always know about each other.

Here are the four primary caches you are dealing with in a Next.js App Router application:

1. Request Memoization — deduplicates identical fetch() calls within a single render pass
2. Data Cache — persists fetch results across requests (server-side, file-system-backed)
3. Full Route Cache — stores rendered HTML + RSC payloads for static routes
4. Router Cache — client-side cache of visited route segments in the browser

Each one has its own lifetime, its own invalidation mechanism, and its own failure modes. Understanding what each does — and does not — cache is the foundation everything else builds on.

Layer 1: Request Memoization

Request Memoization is the most misunderstood cache in Next.js, because it looks like a data cache but is not.

What it does: During a single server render, if you call fetch("https://api.example.com/user/1") in three different components, Next.js only makes one actual HTTP request. The result is shared across all three.

What it does not do: It does not persist across requests. When the next user loads the page, the memoization table is wiped and fresh fetches happen.

Scope: Single render tree, single request.

When it activates: Automatically, for all fetch() calls made with identical URLs and options during a server-side render.

This is why you can safely call getUser() at the top of multiple server components without worrying about N+1 HTTP requests. Next.js deduplicates them for you.

// Both components call the same URL — only ONE HTTP request is made
async function Header() {
  const user = await fetch('/api/me').then(r => r.json())
  return <div>Welcome, {user.name}</div>
}

async function Sidebar() {
  const user = await fetch('/api/me').then(r => r.json())
  return <div>Profile: {user.avatar}</div>
}

React cache() — manual memoization for non-fetch data

fetch() gets automatic memoization. But what about database queries, SDK calls, or anything that doesn't use fetch()?

That's what React.cache() is for.

import { cache } from 'react'
import { db } from '@/lib/db'

export const getUser = cache(async (id: string) => {
  return db.user.findUnique({ where: { id } })
})

Now getUser("abc") called from any server component in the same render will only hit the database once. React deduplicates by function reference + serialized arguments.

Key rules for cache():

• Only works in server components and server-side code
• The cache is per-request — not persistent across requests
• Arguments must be serializable (strings, numbers, plain objects)
• The function must be defined at module scope, not inside components

cache() is best used in your data layer — create one getUser, one getPost, one getCart, wrap each with cache(), and call them freely from anywhere in the server component tree.

Layer 2: The Data Cache

The Data Cache is where things get genuinely persistent. Unlike request memoization, the Data Cache survives across requests and is stored on the server (in Next.js's file-system cache or an external cache depending on your deployment).

By default, all fetch() calls in Next.js App Router are cached indefinitely in the Data Cache. This is the behavior that catches most developers off-guard when migrating from the Pages Router.

// This response is cached indefinitely by default
const data = await fetch('https://api.example.com/posts')

// Opt out of Data Cache entirely
const data = await fetch('https://api.example.com/posts', { cache: 'no-store' })

// Cache but revalidate every 60 seconds
const data = await fetch('https://api.example.com/posts', {
  next: { revalidate: 60 }
})

Time-based revalidation

next: { revalidate: N } tells Next.js to treat this cache entry as stale after N seconds. On the next request after expiry, Next.js will serve the stale response immediately (so the user doesn't wait) while revalidating in the background. This is Stale-While-Revalidate behavior.

async function BlogPosts() {
  // Fresh for 10 minutes, then background-revalidated
  const posts = await fetch('/api/posts', { next: { revalidate: 600 } })
  return <PostList posts={await posts.json()} />
}

On-demand revalidation with revalidatePath and revalidateTag

Time-based revalidation works, but for content-driven apps you usually want to revalidate when something changes, not on a schedule.

revalidatePath('/blog') purges all cached data for that route.

revalidateTag('posts') purges all cached entries that were tagged with "posts".

Tags are more precise and composable. Here is how you assign them:

const data = await fetch('/api/posts', {
  next: { tags: ['posts'] }
})

And here is how you invalidate them — typically in a Server Action or API route:

'use server'
import { revalidateTag } from 'next/cache'

export async function publishPost(id: string) {
  await db.post.update({ where: { id }, data: { published: true } })
  revalidateTag('posts') // purge all cached data tagged 'posts'
}

This is the pattern to reach for in CMS-backed sites, e-commerce, dashboards — any app where data changes on user action.

Layer 3: The Full Route Cache

The Full Route Cache stores the rendered output of static routes — the HTML and RSC payload — on disk. This is what makes Next.js apps incredibly fast to serve: for static routes, Next.js skips rendering entirely and streams bytes directly from disk.

Static routes are generated at build time unless you opt into dynamic rendering. A route becomes dynamic when it uses:

• cookies(), headers(), or searchParams
• fetch() with cache: 'no-store'
• Any dynamic function

If your route has none of these, it renders once at build time and gets cached forever (until you redeploy or revalidate).

When the Full Route Cache is invalidated

• On every new deployment
• When revalidatePath() is called for that route
• When a tagged fetch used on that route is invalidated via revalidateTag()

The Full Route Cache and the Data Cache are linked. When the Data Cache for a fetch used in a page is invalidated, Next.js will also regenerate the Full Route Cache for that page on the next request. This is Incremental Static Regeneration (ISR) — updated and alive in the App Router.

Layer 4: The Router Cache

The Router Cache lives in the browser. When a user navigates between routes in a Next.js app, the prefetched and visited route segments are stored in memory in the client. Navigating back to a previously visited page is instant — no network request.

Default lifetimes:

• Static route segments: 5 minutes
• Dynamic route segments: 30 seconds

This cache exists entirely in the browser and cannot be accessed or controlled from the server. It is invalidated when:

• The user refreshes the page
• router.refresh() is called from a client component
• A Server Action with revalidatePath or revalidateTag runs (Next.js automatically invalidates the relevant router cache entries)

A common gotcha: after a Server Action updates data on the server, the Router Cache may still show stale content. Calling revalidatePath() inside the Server Action tells Next.js to expire the relevant router cache entries, which triggers a fresh fetch on the client.

The use cache directive (Next.js 15+)

use cache is the new, unified caching primitive introduced in Next.js 15 as part of the "dynamicIO" model. It is designed to replace the patchwork of fetch options, unstable_cache, and manual cache wrappers with a single, ergonomic API.

You can apply use cache to:

• An entire file (all exports become cacheable)
• An individual async function
• An async server component

// Cache a specific function
async function getPosts() {
  'use cache'
  return db.post.findMany({ where: { published: true } })
}

// Cache an entire component
async function BlogList() {
  'use cache'
  const posts = await getPosts()
  return <ul>{posts.map(p => <li key={p.id}>{p.title}</li>)}</ul>
}

cacheTag — tagging use cache entries

cacheTag is the companion API to use cache. It lets you attach string tags to cached function results, enabling precise on-demand invalidation with revalidateTag.

import { unstable_cacheTag as cacheTag } from 'next/cache'

async function getPost(id: string) {
  'use cache'
  cacheTag(`post:${id}`, 'posts')
  return db.post.findUnique({ where: { id } })
}

Now revalidateTag('posts') invalidates all posts. revalidateTag('post:abc') invalidates only the post with id abc. You can be as granular as your use case demands.

cacheLife — controlling cache duration

cacheLife lets you set the lifetime of a use cache entry using named profiles or explicit values:

import { unstable_cacheLife as cacheLife } from 'next/cache'

async function getHomepageData() {
  'use cache'
  cacheLife('hours') // built-in profile
  return fetchHeavyData()
}

Built-in profiles: 'seconds', 'minutes', 'hours', 'days', 'weeks', 'max'.

You can also define custom profiles in next.config.ts:

const nextConfig = {
  experimental: {
    cacheLife: {
      editorial: {
        stale: 60 * 60,       // 1 hour
        revalidate: 60 * 60 * 4, // 4 hours
        expire: 60 * 60 * 24 * 7, // 1 week
      }
    }
  }
}

Then use it: cacheLife('editorial').

unstable_cache — the predecessor to use cache

Before use cache, unstable_cache was the way to cache non-fetch async functions. It is still widely used and supported.

import { unstable_cache } from 'next/cache'

const getCachedUser = unstable_cache(
  async (id: string) => db.user.findUnique({ where: { id } }),
  ['user'], // cache key segments
  {
    tags: ['users'],
    revalidate: 3600,
  }
)

The key differences from use cache:

• unstable_cache wraps the function at definition time. use cache is applied inline.
• unstable_cache requires explicit key segments. use cache derives the key automatically from function arguments.
• use cache is simpler but requires experimental.dynamicIO: true in next.config.ts.

For new projects on Next.js 15, prefer use cache. For existing projects or where dynamicIO is not enabled, unstable_cache is the right tool.

Opting out of caching

Knowing how to opt out is just as important as knowing how to opt in.

// Per-fetch opt-out
fetch('/api/data', { cache: 'no-store' })

// Route-level opt-out — makes the entire route dynamic
export const dynamic = 'force-dynamic'

// Revalidation only, no persistent cache
export const revalidate = 0

When should you opt out?

• Real-time data (prices, live scores, user-specific dashboards)
• Auth-gated pages with personalized content
• Any route where stale data would cause functional bugs

Common caching mistakes (and how to fix them)

1. Caching user-specific data globally

Never cache responses that differ per user (session data, personalized feeds, account info) in the Data Cache or with use cache at the page level. Cache the data-fetching layer and pass user context in, or opt those routes out of caching entirely.

2. Forgetting revalidateTag in Server Actions

A Server Action that mutates data without calling revalidateTag or revalidatePath will leave the Data Cache and Router Cache stale. Always pair mutations with cache invalidation.

3. Using cache() for persistent caching

React.cache() is per-request memoization, not persistent caching. Using it to "cache" a database result across requests has no effect — the result is thrown away after each render.

4. Tagging too broadly

If you tag every fetch with 'all' and call revalidateTag('all') on every mutation, you lose all the benefits of granular invalidation. Tag specifically: post:${id}, user:${id}, category:${slug}.

5. Ignoring the Full Route Cache in production

Static routes work differently locally (next dev always renders dynamically) versus production (next build). Test caching behavior with next build && next start, not just in dev mode.

A practical mental model for Next.js caching

Think of it as four nested layers:

Request
  └─ Request Memoization     (within a single render, ephemeral)
       └─ Data Cache          (across requests, persistent, server-side)
            └─ Full Route Cache (rendered HTML, per route, server-side)
                 └─ Router Cache   (browser, in-memory, per session)

Invalidation flows outward: when the Data Cache for a fetch is invalidated, the Full Route Cache that depends on it gets regenerated. When the Full Route Cache is updated, the Router Cache for that route gets expired on the next Server Action or navigation.

Cache as close to the data source as possible. Tag specifically. Invalidate on mutation. Opt out for truly dynamic content.

Summary: when to use what

| Scenario | Tool | |---|---| | Deduplicate DB calls within a render | React.cache() | | Cache fetch results across requests | fetch() with next: { revalidate } | | Cache non-fetch async functions | unstable_cache or use cache | | Tag-based on-demand invalidation | cacheTag + revalidateTag | | Invalidate a whole route after mutation | revalidatePath | | Skip caching for real-time data | cache: 'no-store' or dynamic = 'force-dynamic' | | Control cache lifetime with profiles | cacheLife |

Going deeper

This guide covers every caching concept in the Next.js App Router. But knowing the concepts and applying them correctly in a production codebase are two different things.

If you're building a real Next.js application and want:

• Architecture diagrams showing how the four cache layers interact
• Production-ready patterns for e-commerce, SaaS, and content sites
• Recipes for cache warming, segment-level caching, and multi-tenant apps
• A decision tree for every caching choice you'll face
• Code snippets you can drop straight into your app

...then the Next.js Caching Handbook is built exactly for that. It's a code-first, production-focused guide for Next.js developers who want to cache correctly from the start.

Published by Emeruche Ikenna. If this helped you, share it with a Next.js developer who's been burned by stale cache.

Most people use Next.js very superficially.

Routing, SSR, maybe API routes — and that’s it. But Next.js is not just a React framework; it’s a routing, request-handling, and application architecture layer. Many of its most powerful features live outside components and never touch JSX.

One of those features is rewrites.

Today, we’re talking about rewrites — what they are, how they work, and why they matter.

What is a Rewrite in Next.js?

A rewrite allows you to map an incoming request path to a different destination without changing the URL in the browser.

The user requests one URL.

Your application serves content from another.

The browser never knows.

This is fundamentally different from redirects.

Redirects tell the browser to make a new request.

Rewrites happen entirely inside Next.js.

Basic Rewrite Example

Rewrites are defined in next.config.js

module.exports = {
  async rewrites() {
    return [
      {
        source: '/blog/:slug',
        destination: '/content/posts/:slug',
      },
    ]
  },
}

What happens here?

A user visits /blog/nextjs-rewrites and Next.js internally serves /content/posts/nextjs-rewrites.

However, the browser URL remains /blog/nextjs-rewrites.

No redirect. No reload. No visible change.

Why Rewrites Matter Architecturally

URLs are a public contract.

Once users, crawlers, or external systems depend on a URL, changing it becomes expensive. Rewrites let you preserve that contract while refactoring everything underneath.

This means:

• you can change folder structures freely

• you can reorganize routes without breaking links

• you can evolve your app incrementally

API Proxying With Rewrites

One of the most practical uses of rewrites is API proxying.

module.exports = {
  async rewrites() {
    return [
      {
        source: '/api/:path*',
        destination: 'https://external-service.com/:path*',
      },
    ]
  },
}

Now the frontend calls /api/users but the request is actually sent to https://external-service.com/users

Why this is powerful:

• avoids CORS issues

• keeps API keys server-side

• creates a single API surface for the frontend

• allows backend services to change without frontend changes

From the client’s perspective, everything lives under /api

Rewrites vs Redirects (Critical Difference)

Redirects:

• change the browser URL

• trigger a second request

• are visible to the user

• affect SEO

Rewrites:

• keep the original URL

• resolve internally

• are invisible to the user

• do not trigger navigation

If redirects are navigation tools, rewrites are infrastructure tools.

Rewrites and the Request Lifecycle

Rewrites run before routing.

This means:

• Next.js evaluates rewrites first

• then resolves the final route

• then executes page or API logic

Because of this:

• req.url may not reflect the final destination

• middleware logic must be tested carefully

• assumptions about paths can break if rewrites are ignored

This is one of the few “gotchas” with rewrites — they are powerful precisely because they’re invisible.

Conditional Rewrites

Rewrites can also be conditional.

Example based on headers:

{
  source: '/dashboard',
  has: [
    {
      type: 'header',
      key: 'x-admin',
      value: 'true',
    },
  ],
  destination: '/admin/dashboard',
}

Same URL. Different destination. Different behavior.

This enables:

• role-based routing

• multi-tenant applications

• internal feature flags

• environment-based routing

Why Rewrites Are Underrated

Rewrites don’t live in components.

They don’t affect UI.

They don’t announce themselves.

But they:

• decouple URLs from implementation

• enable safe refactors

• turn Next.js into a lightweight gateway

• push routing decisions closer to infrastructure

Once you understand rewrites, you stop thinking of URLs as file paths and start treating them as interfaces.

Final Thought

Rewrites allow Next.js apps to grow, migrate, and evolve without breaking users or clients. If you’re building anything beyond a small project, rewrites are not optional — they’re foundational. Most people never go past the surface of Next.js.

Rewrites are one of the first features that show you how deep it actually goes.

This usually isn’t because the AI is “bad” but because the questions are underspecified.

This article explains prompt engineering for clinicians: what it actually means, why it matters in medical contexts, and how doctors can use AI tools more safely and effectively in everyday clinical workflows.

What Is Prompt Engineering (Technically)?

Prompt engineering is the deliberate structuring of inputs to an AI system to guide its reasoning, scope, and output.

In simpler terms:

AI systems respond based on how you ask, what context you provide, and what constraints you set.

For clinicians, this is critical. Medicine is contextual, probabilistic, and safety-sensitive. A vague prompt can easily lead to:

• Overly general advice
• Missing contraindications
• Recommendations that don’t apply to your region or patient population

Prompt engineering is not about tricks or shortcuts. It is about translating clinical reasoning into a format AI systems can interpret.

Why This Matters in Clinical Practice

Clinical decisions are rarely universal. Age, pregnancy status, comorbidities, guideline differences, and resource availability all influence care.

If these factors are not explicitly stated, AI systems will make assumptions. Those assumptions may be incorrect, outdated, or unsafe.

Good prompting reduces this risk by:

• Narrowing the scope of responses
• Improving relevance
• Highlighting uncertainty
• Making outputs easier to verify

Core Principles of Prompt Engineering for Clinicians

Below are practical, repeatable guidelines clinicians can apply immediately.

1. Clearly Define the Role of the AI

AI systems respond differently depending on how they are positioned. If no role is defined, responses default to general educational explanations.

Instead of asking:

What is the treatment for asthma?

Ask:

You are a clinical decision support assistant helping a practicing physician. Summarise first-line management of asthma.

Why this works:
Defining the role signals that the response should be clinically framed, concise, and practice-oriented rather than patient-facing or generic.

2. Provide Patient-Specific Context

Clinical recommendations depend heavily on patient characteristics. Without context, AI systems must guess.

Instead of asking:

What antibiotics treat UTI?

Ask:

Adult female, 28 years old, non-pregnant, no known drug allergies, uncomplicated UTI. Summarise first-line antibiotic options.

Why this works:
Age, pregnancy status, allergies, and complexity level dramatically change management. Explicit context narrows the response and improves safety.

3. Specify Guidelines and Geographic Context

Medical practice varies across countries, institutions, and guideline bodies. AI systems do not automatically know which standard applies to you.

Instead of asking:

What’s the management of hypertension?

Ask:

Based on current international guidelines, summarise first-line management of hypertension in adults, and note where practice may vary by region.

Why this works:
This reduces outdated recommendations and highlights where local practice or resources may change management.

4. Add Constraints and Safety Signals

Unconstrained prompts can lead to long, unfocused answers that miss clinical red flags.

Instead of asking:

Explain this lab result.

Ask:

Explain this lab result, include normal ranges, common causes, and red flags that require urgent clinical review.

Why this works:
Constraints structure the output and force the model to surface safety-critical information.

5. Use Follow-Up Prompts to Refine Reasoning

Clinical reasoning is iterative. One answer is rarely sufficient.

After an initial response, follow up with questions such as:

• What are common contraindications?
• What uncertainties or grey areas exist?
• What findings would change management?

Why this works:
AI performs best when guided step-by-step, similar to a clinical discussion rather than a single exam-style question.

How Clinicians Should Use AI (and How Not To)

AI tools should be used as:

• Learning aids
• Documentation support
• Clinical preparation tools
• Patient education drafting assistants

They should not replace:

• Clinical judgement
• Local protocols
• Formal guidelines
• Supervision or escalation pathways

Prompt engineering improves usefulness, but verification remains essential.

Common Mistakes to Avoid

• Asking overly broad questions
• Omitting patient context
• Ignoring geographic or guideline differences
• Treating AI output as authoritative
• Skipping follow-up clarification prompts

Further Learning

• Prompt Engineering For Healthcare: 11 Tips To Craft Great ChatGPT Prompts
• Prompt Engineering in Clinical Practice: Tutorial for Clinicians
• Prompt Engineering in Healthcare AI: Revolutionizing Diagnostics and Patient Communication
• LinkedIn post by Dr Robert Pearl
• Asking ChatGPT for Medical Advice? Here’s How to Do It Safely.
• 9 Doctor-Approved Ways to Use ChatGPT for Health Advice

Videos

• Prompt Engineering in Medicine: How Doctors Use AI to Work Smarter
• Prompt Engineering for Healthcare by Dr Alex Dummett
• Master Prompt Engineering for Physicians: How to get accurate AI answers every time
• Prompt Engineering in Healthcare

Other notable readings

• AI 101: A Self-Paced Guide to AI in Medicin
• WHO Guidance on Ethics and Governance of AI in Health
• FDA: AI/ML in Medical Software

Final Thoughts

Prompt engineering is simply the skill of translating clinical thinking into structured questions AI systems can respond to safely.

As AI becomes embedded in documentation systems, decision support tools, and patient-facing platforms, clinical AI literacy will increasingly be part of modern medical practice.

Learning how to ask better questions is the first step.

Image generated by nano-banana

Let us address and understand two key concepts:

Traditional SEO

Traditional SEO is the practice of optimizing webpages to rank higher on search engines using keywords, metadata, backlinks, and technical performance. Its goal is to improve visibility in SERPs (Search Engine Result Pages) when users type queries into search engines like Google and Bing.

LLM SEO

LLM SEO is the practice of structuring content so large language models like ChatGPT, Gemini, Claude, etc can easily understand, recall, and reference it in conversational answers. It emphasizes clarity, semantic richness, and strong entity signals instead of traditional ranking factors.

A couple of years ago, developers, marketers and website owners never had to worry about this topic. But all that has changed since the rise and wide adoption of generative AI and large language models (LLMs). Before the introduction of LLMs, web users relied primarily on search engines like Google and Bing to find information on the internet, and these returned just links to webpages. For years, developers and marketers have understood and focused more on this: making their sites searchable and indexable by search engine crawlers like Googlebot. But with AI tools like ChatGPT, Perplexity, and Claude, they don’t just search. They answer in human language — and can occasionally cite links as references. And this is why this matters. Users mostly now ask AI instead of Googling.

So now, it is important for web developers and owners to understand and know how to make their sites and pages “findable” by these AI tools. And that is essentially what we are here for.

Related: If you’re building with Next.js and want implementation-ready patterns, I go much deeper into dynamic sitemaps, JSON-LD, and llms.txt for the App Router in my Next.js LLM SEO Handbook.

But before we proceed, let us take a step back to first understand how search engines differ from LLM-based systems.

How does LLM search work?

RAG (Retrieval-Augmented Generation) is the foundational approach powering most AI search tools.
When you ask AI like ChatGPT, Claude, Perplexity, etc a question, search works by combining two powerful operations: retrieval and reasoning. Unlike traditional search engines, they do not match keywords. Instead, an LLM first interprets your question semantically. This means the model is not just looking at the exact words you typed. It’s trying to understand the meaning behind your question. It is trying to understand intent, context, entities, and relationships.

“Unlike keyword search, which looks for exact word matches, semantic search finds conceptually similar content — even if the exact terms don’t match."

— Open AI on semantic search

Let’s break it down:

Understanding intent, not keywords

Traditional search matches exact words while LLM semantic understanding interprets what you actually want. For e.g., “hypertension guideline update” becomes “latest official hypertension diagnosis or treatment recommendations.” It focuses on intent, not phrasing.

Understanding context and entities

LLMs consider the surrounding conversation and real-world entities.
“What are the side effects?” refers to the drug previously discussed.
“What did Apple announce this week?” is understood as a company-related news query, not fruit, and “this week” means recent information.

Understanding synonyms, relationships and variations

Semantic search recognizes meaning equivalents:
“update” → “latest changes,”
“guideline” → “recommendation,”
“hypertension” → “high blood pressure.”
This lets it find relevant content even when wording differs.

Reformulating the query for better retrieval

After understanding meaning, the LLM generates improved search queries like:
“latest WHO hypertension guideline 2023/2024,”
“recent changes in high blood pressure management,”
“hypertension treatment recommendations site:gov.”
These richer queries only work because the model understands the underlying intent.

It then rewrites your query into multiple optimized forms, firing off parallel searches across the web, databases, or specialized sources. This produces a pool of potentially relevant documents that go far beyond what a single query would surface.

Putting it all together

After gathering results, the system proceeds to aggressively filter for relevance, recency, authority, and uniqueness. Each document is broken into smaller chunks and converted into embeddings (numerical representations of meaning). Using vector similarity search, the system selects the most relevant chunks that match the true intent of your question, and not just your exact words. These chunks are then fed into the LLM alongside your query, allowing the model to read, compare, and synthesize information grounded in actual sources.

The connection between LLM and Traditional search

LLM search relies heavily on semantic understanding, entity recognition, and query reformulation. But it can only apply these abilities to content it can actually retrieve. If your site isn’t indexed by Google, Bing, or another major traditional search partner, the LLM has nothing to semantically interpret, rewrite, or reason over. In other words, even the smartest AI search systems can’t surface content they can’t access. This is why SEO and proper indexing are essential: if search engines can’t see you, LLMs can’t either.

Traditional SEO vs “LLM SEO” (AI‑Search Optimization)

I believe it is important to note that LLM SEO — also called a few other fancy words like GEO (Generative Engine Optimization), AEO (AI Engine Optimization), LLMO (Large Language Model Optimization) — is basically just traditional SEO but going an extra length to optimize content to be found by LLMs and AI search engines.

You cannot build on LLM SEO without understanding and building on traditional SEO first. And most of the time, if you paid enough attention to getting the traditional SEO for your site right, then you have little to nothing extra to do in order to be discovered by AI.

Credit: Vercel

This means the fundamentals of classic SEO remain essential for getting your pages and content discovered in the first place. As explained in Jenny Ouyang’s article SEO for AI: How to Make Your Product Discoverable by LLMs, if your content isn’t indexed by search engines, it’s often invisible to LLMs.

Here are the foundational SEO concepts that LLM SEO builds upon:

1. Crawlability and indexability
Googlebot, Bingbot, and partner crawlers still determine whether your content enters the search index that LLMs borrow from.

2. Clean HTML structure and metadata
Clear titles, meta descriptions, and semantic HTML help both search engines and LLMs interpret your content.

3. Quality, helpful content
Traditional SEO’s “helpful content” guidelines apply strongly in the AI era. LLMs prioritize pages with strong explanations, clear definitions, and well-structured writing.

4. Backlinks and authority signals
Authority still matters. Pages referenced by other reputable websites are more likely to rank in Google and in turn, more likely to be cited by LLMs.

5. Sitemap and robots.txt configuration
Submitting a sitemap to Google and Bing ensures your pages are findable by the search infrastructure that LLMs depend on. Basic robots.txt rules still govern crawler access.

6. Fast page performance
Search engines and AI crawlers both favor pages that load fast. As noted by Vercel, slow, JS-heavy pages risk being partially invisible.

If you have these in place, you are almost good to go.

What are the actionable steps to improve LLM SEO?

Here are in-depth practices and checklists that will guide you to ensure AI and LLMs can find and reference your content easily:

1. Ensure your site is crawlable and indexable

Crawl-ability and index-ability are mostly managed by two files — robots.txt and sitemap.xml.

A robots.txt file is a simple text file placed at the root of a website (e.g https://www.example.com/robots.txt) to tell web crawlers which pages or directories they can or cannot access. It uses rules like User-agent, Disallow, and Allow to guide search engine bots, helping manage crawl budget, reduce server load, and prevent unnecessary crawling of non-public or irrelevant sections. While useful for SEO and site organization, it’s not a security tool and blocked pages can still appear in search results if other sites link to them.
Below is a robots.txt snippet gotten from my personal website:

User-Agent: *
Allow: /
Sitemap: https://coleruche.com/sitemap.xml

Above, I am just letting web crawlers know that I am allowing all user agents/bots (User-Agent parameter) to crawl all web pages on my website (Allow parameter) for any informtion or context. To make it easier for them to know the different pages I have on the website, I am also pointing them to the location of my sitemap.

A sitemap.xml is an XML file that lists all the important pages of a website to help search engines understand its structure and discover content efficiently. It acts like a map of your site, telling crawlers which URLs exist, how often they’re updated, and how important they are relative to other pages. Like a robots.txt, the sitemap file should also be located at the root of the website (e.g https://www.example.com/sitemap.xml)

If you have a dynamic website — like a blog or documentation website — where the content and pages change over time (new pages are added, removed or updated frequently), then it is advisable to generate the sitemap dynamically.

Related: In the Next.js LLM SEO Handbook, I show step‑by‑step how to wire up dynamic sitemap.xml and JSON-LD generation from your content so AI crawlers and search engines can reliably discover every page.

Remember to submit sitemap.xml to both Google Search Console and Bing Webmaster Tools.

2. Use SSR or SSG and avoid CSR-only sites

AI crawlers like ChatGPT and Claude don’t execute JavaScript, and this is important to know because for your content to be discovered by LLMs, it has to be server-rendered.

“Our research with Vercel highlights that AI crawlers, while rapidly scaling, continue to face significant challenges in handling JavaScript and efficiently crawling content. As the adoption of AI-driven web experiences continues to gather pace, brands must ensure that critical information is server-side rendered and that their sites remain well-optimized to sustain visibility in an increasingly diverse search landscape.”

— Ryan Siddle, Managing Director of MERJ

You can use rendering techniques like SSRs and SSGs and avoid React SPAs and CSR by all means, except for non-trivial, supporting content like comments, likes, etc.

To view how crawlers may vie your site, test pages with a simple command:
curl https://yoursite.com
You can also load the page in a browser, open up the browser console and disable JavaScript. Then navigate to the Source tab and reload the page. If no meaningful content shows, AI crawlers won’t see it.

3. Add structured data (JSON-LD)

Structured data is extra, machine-readable information you add to a webpage to help search engines clearly understand what the page is about. It describes key details like the type of content, product information, author, ratings, prices, events, FAQs, etc.

JSON-LD (JavaScript Object Notation for Linked Data) is the most common and recommended format for adding structured data to web pages. It’s placed inside a tag in the page’s HTML and doesn’t affect the visible content, making it easy to manage and update. JSON-LD uses clean, nested key-value pairs to describe entities and their relationships, helping search engines like Google, Bing, and AI search systems better understand context and meaning, which ultimately boosts visibility, relevance, and eligibility for AI search features.

Here is a snippet of a JSON-LD for a blog post with schema @BlogPosting

<script type="application/ld+json">{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to Make Your Website Discoverable by AI & LLMs",
  "description": "The articles description goes here",
  "author": {
    "@type": 'Person',
    name: 'Emeruche Ikenna',
  },
}
</script>

Other schema types include Article, FAQPage, Product, Person.Learn more about structured data and JSON-LD.

4. Create clean, semantic HTML

LLMs prefer content that is:

• well-sectioned with <h1>, <h2>, <h3> with good heirarchy

• logically grouped into topic clusters and avoid large walls of text

• use bullet points and numbered listings

• readable even without CSS or JS

• dense with meaning, low on fluff

Clear structure improves semantic similarity retrieval, the core of RAG systems.

5. Write concise summaries at the top of your pages

LLMs rely heavily on:

• opening paragraphs

• abstract-like summaries

• definitions and context at the top

These sections become the “embedding anchor” that determines how your content is recalled.

6. Build internal linking across related topics

Internal links help LLMs understand category structure, topic relationships, and conceptual clusters. This increases your retrieval score during AI search.

For example, you should have a “related articles” sections that link to other articles that may be similar, having hyperlinked texts in an article that references another article on your blog, or having interlinked blog series.

7. Add an llms.txt file (emerging standard)

An llms.txt file is an emerging, unofficial proposal that aims to give website owners a way to signal how they prefer their content to be used by AI models.

It is similar in spirit to robots.txt, but focused on LLM training, indexing, and dataset inclusion. Although the idea has gained attention after early discussions from projects like llm-api and posts from Hacker News and The Verge examining AI data governance, there is still significant debate about its real-world effectiveness, since no major AI company currently treats it as a binding standard. Regardless, adding an the file carries no downside: it doesn’t interfere with normal SEO, it’s easy to implement, and it publicly documents your preferences around AI usage in a transparent, machine-readable way.

While the ecosystem evolves, llms.txt is seen as a “no harm, no foul” option for creators who want to stake out clear expectations for how their content should be consumed by LLMs.

Here is a sample snippet:

site_title: Your Site Name
site_description: A concise description of your website's purpose.

allow: openai
allow: perplexity

disallow_training: all
allow_snippets: all

require_attribution: true

Learn more about the llms.txt proposal.

8. Optimize performance and time-to-first-byte

AI crawlers have much shorter timeouts than browsers. If your server responds slowly, they simply abandon the request, meaning parts of your site may never get indexed.

Improve by focusing on:

• caching (CDN, edge functions)

• HTML delivery speed

• image compression

• code-splitting (without harming SSR)

Fast backends lead to more complete crawls.

9. Maintain content freshness

LLMs prioritize content that remains current and valuable over time. This means regularly updating pages with new insights or corrections, incorporating the latest statistics, facts, and data points, and maintaining evergreen articles that are periodically refreshed with relevant examples. Consistently fresh content enhances both indexing frequency and retrieval accuracy.

10. Get external citations and backlinks

AI-powered systems prioritize content that demonstrates both popularity and relevance, much like traditional SEO. To build this authority involves creating meaningful connections. These connections can be between related pages on your own site (as described in 6. Build internal linking across related topics) and gaining references from niche directories, forums, and specialized blogs. Additionally, promoting your content through newsletters, social media, and backlinks from trusted sources amplifies its reach and credibility. While AI may evaluate these signals differently than Google, the underlying principle of trust and authority remains consistent across platforms.

11. Test your site in AI models regularly

Ask Perplexity or ChatGPT with browsing enabled to analyze your website by requesting a summary of its content. Ask, specifically, what the page contains, and verifying whether it loads correctly. This process helps ensure that AI models can access and interpret your site’s information accurately, highlighting any potential issues with visibility or rendering. If the model is unable to see the content, it indicates a problem that needs to be addressed, such as server-side rendering, crawlability, or indexing issues. Regular testing with AI tools provides valuable feedback to maintain your site’s accessibility and discoverability.

In conclusion

AI-powered search and LLM SEO are transforming how websites and contents are discovered and referenced. Get traditional SEO fundamentals right (crawlability, clean HTML, quality content, and authority), and by building on it, developers can ensure their content remains visible to both search engines and AI systems.

LLM SEO adds an extra layer, emphasizing structured data, server-side rendering, internal linking, and emerging standards like llm.txt to maximize discoverability. Regular testing with AI tools and maintaining content freshness further strengthen a site’s accessibility in the evolving AI landscape. Integrating these strategies ensures that your content not only reaches a wider audience but also becomes a trusted source for AI-powered answers, keeping your website relevant and authoritative in the age of generative AI.

🔐 Medium Integration Tokens are no longer issued to new accounts, but if you already have one, you’re in luck!

If You Have a Medium Integration Token

You can check if you have an existing Medium token here.

Steps to Connect

1. Log in to Crosspost and go to Integrations

2. Select Medium. Locate Medium in the list of supported platforms. If you do not see it at first, click on "Show More".

3. Paste your Medium integration token in the input box provided.

4. Select the default visibility of new posts. By default, all posts will be "Public". And toggle the "Notify users..." switch

5. Click Save and it's done!

   

   Your Medium account is now fully connected. You can:

   • Publish posts directly from Crosspost to Medium

   • Import any of your Medium posts into Crosspost (including paywalled ones)

   • Enable AI-enhanced formatting before publishing

If You Don’t Have a Token (New Medium Users)

With this method, direct publishing will not be available.

Even without a token, Crosspost still lets you connect your Medium account via your username — with some important limitations.

Steps to Connect Without a Token

1. Go to the Medium integration page.

2. Click on "I do not have my Medium integration token"

3. Enter your Medium username (e.g., if your profile is medium.com/@johndoe, then enter johndoe)

4. Save

   

What You Can Do:

Import all your non-paywalled Medium articles. Crosspost will fetch your publicly visible stories via RSS, with the following benefits:

• Tag Optimization: When republishing Medium articles elsewhere, Crosspost helps you auto-optimize tags for each platform.

  • Avoiding Duplicate SEO: Crosspost auto-detects canonical links and prevents accidental content duplication across platforms.

  • Backup Strategy: Consider importing your Medium content even if you’re not publishing from Crosspost, so you always have a clean backup.

What You Cannot Do:

• You cannot publish to Medium from Crosspost

• You cannot import paywalled content (stories behind Medium’s member paywall)

Need help?

Reach out via the in-app chat or email us at support@trycrosspost.com.

With this, you can now import articles from and publish to your Shopify store blog effortlessly.

Why You Should Integrate Shopify with Crosspost

Looking to automate your Shopify content publishing and expand your reach? Integrating Shopify with Crosspost helps you distribute blog posts, product announcements, and promotional updates across platforms like Medium, Dev.to, and LinkedIn effortlessly.

With this, you can:

1. Automate Shopify blog publishing to save hours of manual work

2. Boost Shopify SEO by syndicating content to high-authority platforms

3. Reach new audiences and drive traffic back to your ecommerce store

4. Maintain consistent messaging across all content channels effortlessly

Whether you’re a Shopify store owner, a content marketer, or a developer building ecommerce automation, this integration helps turn your store into a scalable content marketing engine.

How to integrate

To add this integration, you will need your storefront URL as well as your admin API access token.

Getting your store URL

The Shopify store URL is pretty straightforward. To find your Shopify storefront URL, log into your Shopify admin, navigate to Settings, then Domains. Your store's URL, typically in the format your-store-name.shopify.com, will be displayed there.

Alternatively, you can view it in the browser's address bar when logged by clicking "View your online store".

Getting your store admin API access token

To obtain a Shopify Admin API access token, you need to create a custom app within your Shopify admin and configure its API access scopes, then install the app to generate the token. This token allows your app to interact with your Shopify store's data.

Here's a step-by-step guide:

• Log in to your Shopify Admin: Access your Shopify store's admin dashboard using your credentials.

• Navigate to App Settings: Go to "Apps" and then "Apps and sales channel settings".

• Develop Custom Apps: Click on "Develop apps".

• Create a New App: Click "Create an app", give it a name, and choose an app developer (usually yourself).

• Configure Admin API Integration: Go to the "Configuration" tab. Find the "Admin API integration" section and click "Configure".

• Select API Access Scopes: Choose the specific permissions your app needs by selecting the appropriate checkboxes under "Admin API access scopes". For this use case, search for write_content and read_content scopes and select them.

• Install the App: Click "Install app" on top right. (Reload the page if still disabled after selecting access scopes)

• Confirm Installation: In the dialog box, click "Install" again.

• Reveal and Save the Token: Click "Reveal token once" to display the generated access token. Important: Copy and securely store this token, as it will not be displayed again.

Integrating in Crosspost

Now that we have both our shop domain URL and access token, we can proceed to connect in Crosspost. Log in and navigate to the Shopify integration page, enter your storefront URL and the access tokens in the specified fields. Then, "Choose" a blog to connect to. If you do not have a blog created, click on "Create new" and you will be redirected to Shopify to create a new blog.

Click on "Save" to finish the integration. Now you can successfully import and publish to Shopify from Crosspost.

As always, kindly reach out to us if you have any questions.

Let’s face it: many of us have used ChatGPT (and other generative AI) with the same finesse as a toddler in a candy store: excited but completely clueless. You type something vague like, "Tell me about space," and what do you get? A meandering lecture about the universe that could put a caffeinated squirrel to sleep. But fear not! With the right tweaks, you can use ChatGPT as a powerful assistant instead of a disappointing chatbot. Buckle up, because we’re diving into six important AI-prompting guidelines that will unlock its full potential!

1. Be Specific, Not Vague

The first rule of thumb is simple: if you want quality, be specific.

When you provide precise inputs, ChatGPT can hone in on what you really need. Think of it as giving a chef a recipe versus just asking for food. Specific ingredients make for a much tastier dish!

Example:

• Vague Prompt: "How to manage DKA?"

• Specific Prompt: "Summarize the DKA protocol for a 15-year-old T1DM patient in ER. Include doses, fluids, and key danger signs."

This specificity improves the relevance of responses and also elevates the quality of information you receive.

2. Give It a Role or Persona

Imagine asking a senior backend engineer for advice on coding, and then asking a junior developer the same question. You can guess who’s more likely to provide a better response! By assigning a role or persona to ChatGPT, you help it respond in the right tone, depth, and expertise.

Examples:

• Prompt: “You’re a senior backend engineer. Explain how to optimize a database query for speed.”

• Prompt: “Act as a med school lecturer and explain the importance of patient history in diagnosis.”

The same question can yield very different results based on the persona you provide. So, put ChatGPT in the right shoes, and watch it strut its stuff!

3. Add Structure to Your Request

Clarity is king, and the best way to achieve that is by asking for structured outputs. Let ChatGPT know if you want steps, checklists, or bullet points. Specifying the format can be a game-changer.

Example:

• Prompt: “Explain ECG interpretation.”

• Structured Prompt: “Break it down in 5 steps like a checklist for medical interns.”

When you lay out your expectations clearly, ChatGPT can deliver a polished, easy-to-understand response that doesn’t leave you scratching your head.

4. Feed It Context First

ChatGPT isn’t a mind reader. If your request lacks background, the answer will too. Providing context is like giving ChatGPT a roadmap: it prevents it from ending up in a ditch somewhere.

Example:

• Contextual Prompt: “I’m working on a chatbot for an e-commerce site that specializes in handmade crafts. Can you help me design its user flow?”

By giving it a little background, ChatGPT can craft a response that aligns perfectly with your goals, rather than spitting out a generic answer that’s about as useful as a screen door on a submarine.

5. Refine With Follow-Up Prompts

ChatGPT isn't just a magic eight ball—it's more like a conversation partner. Don't settle for the first draft! Follow up with prompts that refine the output.

Examples:

• Initial Prompt: “Write a blog post on the benefits of meditation.”

• Follow-Up Prompt: “Make it sound less robotic and include personal anecdotes.”

By treating ChatGPT like a dialogue, you can coax out better, more tailored responses. So keep the conversation flowing!

6. Use Style Anchors & Examples

If you want ChatGPT to create something that resonates, give it style anchors or references. When you name-drop styles, brands, or examples, it helps anchor the tone and layout.

Example:

• Prompt: “Create a landing page copy for a new productivity app. Make it feel like Apple.com, but with buttons like Stripe.”

This technique dramatically improves the creative outputs, it aligns them with your vision and makes the final result feel cohesive and compelling.

7. Quick Recap: Example Prompts That Combine These

Now, let's put it all together with a couple of final example prompts that incorporate all six habits:

• Example Prompt 1: “Act as a marketing guru and outline a 3-step social media strategy for a small business in the eco-friendly products niche. Use bullet points and include examples.”

• Example Prompt 2: “You’re a high school math teacher. Explain the Pythagorean theorem in a fun, engaging way suitable for 14-year-olds. Please provide a real-world example, and keep it casual.”

These prompts work so well because they combine persona, structure, context, tone, and clarity which is essentially everything you need for a juicy, informative response!

Bonus Section: More ChatGPT Prompting Tips to Try

Here are a few more bite-sized tips to level up your prompting game:

• Use Delimiters: Surround long inputs with delimiters (like """ or Markdown) to keep things organized.

• Tell It What Not to Do: Clear instructions like “Don’t sound robotic” help steer the response in the right direction.

• Ask for Multiple Versions: Request variations like “Give me 3 tone variations” to explore different styles.

• Set Token or Word Limits: Specify limits for concise responses—great for tight deadlines!

• Reference Prior Messages: Mention earlier interactions to build context and continuity.

• Quiz Yourself: Ask ChatGPT to quiz you on topics you've just learned for deeper retention.

• Request Citations: If applicable, ask for citations or evidence to back up claims—because who doesn’t love a good source?

Conclusion

So, there you have it! ChatGPT isn’t magic, but with the right inputs, it feels magical. By implementing these six prompting habits (and a few bonus tips), you can transform your interactions from “meh” to “wow.” So bookmark this, share it, or better yet—try one of these prompts right now. Happy chatting!

In the early days of the internet, a personal blog was a writer's digital island. Today, the most effective creators build bridges, connecting their work to established communities across multiple platforms. Relying on a single platform can create a digital echo chamber, where your work only reaches those who already know you. This approach severely limits growth and discovery.

The primary benefit of multi-platform publishing is tapping into the built-in audiences of established sites. Platforms like Medium or LinkedIn already have millions of active readers searching for quality content. By sharing your work there, you place it directly in their path, which helps to increase article visibility far more quickly than a standalone blog ever could. It’s the difference between setting up a shop on a quiet side street versus opening a stall in a busy market.

Furthermore, publishing on high-authority domains offers a distinct SEO advantage. Search engines trust these established sites, giving your content a better chance to rank. With the right techniques, such as using canonical links to point back to your original article, you can consolidate this credibility without being penalised for duplicate content. This strategy ensures your work reaches new readers while strengthening your own digital footprint.

An Overview of Key Publishing Platforms

With a clear understanding of why you should publish widely, the next question is where. Choosing the right platforms depends entirely on your niche, your style, and the audience you want to reach. Not all platforms are created equal, and the best platforms for writers are those that align with their specific goals. Think of each one as a different type of venue, each with its own unique crowd and expectations.

Here is a look at some of the key players:

• Medium: This platform is known for its broad, general-interest audience and powerful network effects. It’s an excellent place for thought leadership, personal essays, and deep dives on a variety of topics. Its internal distribution system can help your stories find readers you would never have reached otherwise.
• Dev.to: A community built by and for software developers. If you write technical articles, tutorials, or commentary on the tech industry, Dev.to is an essential destination. The audience is engaged, knowledgeable, and appreciates well-explained code snippets and practical insights.
• LinkedIn Articles: This is the definitive platform for professional, industry-specific, and business-oriented content. Publishing here positions you as an expert in your field, reaching an audience of colleagues, potential employers, and industry leaders. It’s ideal for case studies, career advice, and market analysis.
• Personal Blogs & Newsletters (Substack, Ghost): This is your home base. It is the one space where you have complete control over your content, audience data, and monetization. While other platforms are for discovery, your personal site is where you build a direct relationship with your most loyal readers.

Developing Your Content Distribution Strategy

Now that you know the venues, it’s time to plan the tour. A successful content distribution strategy is not about shouting your message from every rooftop. Spreading yourself too thin across too many platforms can dilute your efforts and lead to burnout. Instead, focus on two or three platforms where your target audience is most active and engaged.

A proven approach is the "Pillar and Post" model. Your personal blog or newsletter acts as the central "pillar" where your original content lives. Other platforms like Medium or LinkedIn then serve as "posts" where you syndicate that content to reach new audiences. This model ensures you are building your own asset while leveraging the reach of others.

This brings us to a critical technical step for anyone wondering how to publish on multiple platforms without harming their search engine ranking: the canonical URL. A canonical link (rel="canonical") is a small piece of HTML code that tells search engines which version of an article is the original. As detailed in Google's own Search Central documentation, proper use of canonical tags is fundamental to content syndication. By adding this tag to your syndicated posts, you ensure all SEO authority flows back to your original pillar article, preventing duplicate content issues and consolidating your credibility.

Adapting Your Content for Each Audience

An effective multi-platform strategy requires more than just copying and pasting. Each platform has its own culture, format, and reader expectations. Simply reposting the same content everywhere is like giving the exact same speech at a business conference and a casual meetup. The message gets lost because the delivery is wrong. To truly connect, you must adapt your content for each specific audience.

Here are a few practical ways to tailor your work:

1. Reframe Your Titles and Introductions: The title that works on your SEO-optimised blog might not perform well on Medium. For LinkedIn, a title might be direct and professional, like "Three Metrics for Measuring Content ROI." On Medium, a more inquisitive or narrative-driven title, such as "What I Learned After Tracking My Content ROI for a Year," often performs better. The first few sentences should also be adjusted to hook each platform's unique readership.
2. Adjust the Body for Context: The core of your article can remain the same, but small additions make a big difference. When posting on Dev.to, ensure your article includes well-formatted code snippets. For a LinkedIn audience, you might embed a chart or add a paragraph that ties your topic to current business trends.
3. Tailor the Call-to-Action (CTA): What do you want the reader to do next? The answer should change with the platform. On Medium, you might ask readers to follow you for more stories. On LinkedIn, the goal could be to prompt connections or start a professional discussion in the comments. From your syndicated posts, the ultimate CTA should always guide readers back to your home base, perhaps by encouraging them to subscribe to your newsletter.

Tools for Efficient Content Management

Executing a thoughtful multi-platform strategy sounds great in theory, but the manual work can be overwhelming. Logging into each platform, reformatting your article, adjusting images, and setting canonical links for every single post is a significant drain on a writer's most valuable resource: time. We have all felt that friction, where administrative tasks get in the way of actual creation.

This is where content syndication tools become essential. These platforms are designed to automate the repetitive tasks of distribution. Instead of spending hours copying and pasting, you can focus on what you do best. Platforms like Crosspost are built to solve this exact problem, allowing creators to write once and publish everywhere with the correct formatting and metadata automatically applied.

By integrating these tools into your workflow, you reclaim hours of your week. You are freed from the tedious mechanics of publishing and can invest that time back into writing, researching, and engaging with your growing audience. It transforms your content strategy from a chore into a seamless extension of your creative process.

In the digital landscape of today, bloggers and digital marketers often find themselves at a critical crossroads when setting up their blogs: Should they host their blog on a subdomain or a subdirectory? This choice is not merely a technical one; it bears significant implications for SEO, branding, and overall site management. In this article, we will explore these two options, their advantages and disadvantages, and help you decide the best path for your blog.

Understanding Subdomains and Subdirectories

Before diving into the nuances of each approach, let’s clarify what we mean by subdomains and subdirectories:

• Subdomain: This is a distinct part of your main domain, serving as an independent entity. For example, if your main site is domain.com, a blog on a subdomain would be blog.domain.com.

• Subdirectory: This is a folder within your main domain. Continuing with our example, a blog in a subdirectory would appear as domain.com/blog.

The decision between these two structures is crucial because it impacts your site’s SEO performance, branding strategy, and technical flexibility.

Subdomain Overview

What is a Subdomain?

A subdomain is essentially a separate section of your website that can function independently from the main domain. Companies often use subdomains for various reasons, such as to host distinct content types or to target different audiences.

When to Use Subdomains

Subdomains are particularly useful for:

• Large Companies: Organizations with diverse offerings (like an e-commerce site, a blog, and a support center) may choose subdomains to separate each function clearly.

• Different Content Management Systems (CMS): If your primary website runs on one CMS and you prefer another for your blog (say, using WordPress for the blog), a subdomain allows you the flexibility to do so.

• Multilingual Sites: Companies targeting multiple languages often use subdomains (e.g., fr.domain.com for French content) to organize their content better.

SEO Considerations

When it comes to SEO, Google treats subdomains as separate entities. This can be advantageous in some cases, as it allows for focused content targeting. However, it also means that the authority built up on your main domain does not automatically transfer to the subdomain, potentially diluting your SEO efforts.

Pros and Cons of Subdomains

Pros:

• Greater flexibility in terms of design and technology.

• Clear separation of content types, which can enhance user experience.

Cons:

• SEO dilution due to separate domain authority.

• More complex tracking and analytics setup.

Subdirectory Overview

What is a Subdirectory?

A subdirectory, on the other hand, is part of your main domain’s structure. It is integrated into your main website and is often perceived as part of the same entity.

When to Use Subdirectories

Subdirectories are ideal for:

• Small to Mid-Size Businesses: Companies looking to build their brand and authority can benefit from the shared domain authority.

• SEO-Focused Sites: If your main goal is to enhance your SEO performance, utilizing a subdirectory can help consolidate your domain authority.

• Content Hubs: If your blog is a central part of your business strategy, keeping it in a subdirectory can help create a more cohesive user experience.

SEO Benefits

One of the most significant advantages of using a subdirectory is that it allows your blog to benefit from the domain authority of your main site. This can lead to improved rankings on search engines, as the content can leverage existing backlinks and traffic.

Pros and Cons of Subdirectories

Pros:

• Tight integration with the main website enhances brand unity.

• Easier transfer of SEO benefits and domain authority.

Cons:

• Potential technical limitations based on the main site’s CMS.

• Changes to the main site could inadvertently affect the blog.

SEO Implications

Google treats subdomains and subdirectories differently. While there’s an ongoing debate in the SEO community about which is better, many experts agree that subdirectories generally provide a stronger foundation for SEO performance.

Key Factors to Consider

1. Domain Authority: A subdirectory shares the main domain's authority, which can significantly enhance its SEO performance.

2. Crawl Efficiency: Google’s crawlers may find it easier to navigate and index a unified structure than separate domains.

3. Backlink Value: Backlinks to the main domain also benefit the subdirectory, which is not the case for subdomains.

Community Insights

Several studies and discussions in SEO communities, such as those by Moz and Search Engine Journal, support the idea that subdirectories often yield better SEO results, especially for businesses aiming for organic growth.

Technical & Operational Considerations

When deciding between a subdomain and a subdirectory, consider the following operational elements:

CMS Flexibility

If you wish to use different technologies for your blog and main site, a subdomain may be more suitable. For example, you could run your main site on a custom-built platform while using WordPress for your blog on a subdomain.

Tracking and Analytics

Google Analytics and Search Console handle subdomains and subdirectories differently. While you can track both setups with similar tools, subdomains require more granular setup to ensure you’re capturing data accurately.

Performance Impact

In terms of performance, a subdirectory may offer better speed and efficiency due to the shared resources of the main domain, while a subdomain might introduce additional latency.

Branding & User Experience

Brand perception can be influenced significantly by your choice of blog structure. A subdirectory usually provides a sense of unity and cohesiveness across your digital properties. Users may feel more comfortable navigating between the main site and the blog when they appear as part of the same domain, fostering a more seamless experience.

Navigation Continuity

While subdomains can serve specialized content, they often require users to adjust to a different URL and interface, which may disrupt the user experience. In contrast, subdirectories maintain a consistent user journey.

Which Should You Choose? (Decision Guide)

When making your decision, consider the following checklist:

• Do you need flexibility in technology? → Subdomain

• Is SEO growth your primary goal? → Subdirectory

• Is your blog a significant part of your brand? → Subdirectory

• Do you manage multiple sites with distinct purposes? → Subdomain

In most cases, particularly for smaller to mid-size businesses focused on SEO, subdirectories are preferred unless there’s a compelling reason to opt for a subdomain.

Conclusion

Choosing between a subdomain and a subdirectory is a pivotal decision that can impact your blog's performance, user experience, and overall brand perception. By weighing the pros and cons of each option and considering your long-term goals—whether they lean more towards SEO growth or technical flexibility—you can make an informed decision that aligns with your business strategy.

Ultimately, as with many aspects of digital marketing, there is no one-size-fits-all solution. Taking the time to evaluate your needs and objectives will serve you well in the long run.

Understanding Crossposting

Crossposting refers to the practice of publishing the same content across multiple platforms or websites. This can include social media, personal blogs, third-party websites, or content syndication networks. While it may sound counterintuitive at first, the benefits often outweigh the potential drawbacks when done strategically.

The SEO Advantages of Crossposting

1. Increased Content Reach

One of the most immediate benefits of crossposting is the increased reach your content can achieve. By sharing your articles on various platforms, you expose your brand to different audiences. Each platform has its own user base, and by crossposting, you can attract readers who may not have encountered your content otherwise.

For instance, sharing a blog post on LinkedIn can reach a professional audience, while posting the same article on Facebook might attract a more casual, general audience. This broader reach can lead to a higher number of backlinks and social shares, both of which are essential for improving SEO.

2. Boosting Domain Authority

Domain authority (DA) is a critical factor in how search engines rank your website. Crossposting can enhance your website's DA in several ways. First, when your content is shared across multiple reputable platforms, it signals to search engines that your content is valuable and trustworthy. This can lead to increased recognition from search engines, which often results in improved rankings.

Furthermore, crossposting can generate backlinks to your primary domain, especially if you are sharing your content on platforms that allow for a link back to your original article. These backlinks are crucial for SEO as they help to establish your site as a credible source of information.

3. Enhanced Keyword Visibility

Crossposting can also improve your keyword visibility. By sharing your articles on multiple platforms, you create more opportunities for your target keywords to be indexed by search engines. Each platform may rank differently for specific terms, so crossposting can help your content appear in various search results.

For example, if your article is optimized for the keyword "digital marketing strategies," crossposting it on platforms that cater to marketing professionals can increase the chances of your content being discovered by users searching for that specific term. This diversified approach can lead to increased organic traffic over time.

4. Social Signals and Engagement

Search engines consider social signals (such as likes, shares, and comments) as indicators of content quality. When you crosspost articles, you can tap into the engagement mechanics of various platforms. The more interaction your content receives, the more likely search engines are to view it as valuable, which can, in turn, boost your rankings.

Engaging with users on different platforms can also lead to discussions around your content, creating a sense of community. This engagement can result in additional shares and backlinks, further enhancing your SEO efforts.

5. Repurposing Content for Different Audiences

Crossposting allows brands to repurpose content, tailoring it for different audiences without starting from scratch. You can modify your articles slightly to suit the tone and preferences of each platform. For instance, a detailed blog post may be condensed into a series of social media posts or adapted into an infographic for visual platforms like Pinterest.

By repurposing content, you maximize your investment in content creation while simultaneously catering to diverse audience segments. This targeted approach can lead to higher engagement rates, driving more traffic back to your primary site.

6. Establishing Thought Leadership

Regularly crossposting valuable content positions your brand as a thought leader in your industry. When you consistently share insightful articles across various platforms, it builds credibility and trust among your audience. This trust can translate into organic traffic as users seek out your content as a reliable source of information.

Over time, being recognized as a thought leader can lead to speaking engagements, partnerships, and other opportunities that further enhance your brand's visibility and traffic.

Best Practices for Crossposting

While the benefits of crossposting are evident, it’s essential to approach this strategy thoughtfully to avoid potential pitfalls such as duplicate content penalties. Here are some best practices to ensure that your crossposting efforts are effective:

1. Use Canonical Tags: If you are crossposting the same article on multiple platforms, use canonical tags to indicate the original source. This informs search engines which version to prioritize in rankings.

2. Modify Content Slightly: Instead of posting the exact same article everywhere, consider modifying it for different platforms. Adjust the tone, format, or even the headline to better fit the audience of each platform.

3. Promote Engagement: Encourage readers to engage with your content by asking questions or inviting comments. This not only boosts social signals but can also lead to meaningful discussions.

4. Track Performance: Utilize analytics tools to monitor the performance of your crossposted articles. Track metrics like traffic sources, engagement rates, and conversions to evaluate the effectiveness of your strategy.

5. Choose Platforms Wisely: Not all platforms will be suitable for every piece of content. Consider your target audience and select the platforms where they are most active.

Conclusion

Crossposting articles is a powerful strategy in the digital marketing toolkit, offering numerous SEO benefits that can significantly enhance online visibility and traffic. By strategically distributing content across various platforms, businesses can boost their reach, improve domain authority, and establish themselves as thought leaders. As the digital landscape continues to evolve, embracing crossposting could be the key to staying ahead of the competition and maximizing the impact of your content. In the end, it’s not just about creating great articles; it’s about ensuring they reach the right audience in the right places.

The New Era of Content Creation

In the fast-paced world of digital publishing, the demand for consistent, high-quality content is relentless. Whether you run a niche blog, content-heavy startup, personal newsletter, or affiliate site, keeping up with publishing schedules can feel like a full-time job. But what if your blog could write itself — on autopilot?

That’s exactly what autoblogging makes possible. Autoblogging tools use AI and automation to generate, schedule, and even distribute blog content without manual writing. And two platforms are leading the charge in this space: Blogbuster, your go-to autopilot blog generator, and Crosspost, the one-click publishing and distribution tool.

In this feature, we’ll explore how Blogbuster can power your blog’s content engine while you sleep, and how pairing it with Crosspost transforms it into a seamless syndication powerhouse. This article will cover the Blogbuster setup, generation process, and strategic use cases and then show you how to publish and cross-post your new AI-written posts across the internet using Crosspost.

What is Blogbuster?

Blogbuster is an AI autoblogging tool that takes the manual work out of content creation. It generates original, SEO-friendly blog posts from just a few inputs — no writing, editing, or formatting needed.

BlogBuster: Turn Your Blog into an Autopilot Traffic Machine

Once set up, Blogbuster runs on autopilot, creating and scheduling articles daily, weekly, or monthly. You can choose content categories or let it pick trending topics from your niche.

Each post comes optimized for search, complete with structured headings, keywords, and even images to break up walls of text — making your blog look pro with zero effort.

What is Crosspost?

Crosspost is a content distribution tool that lets you publish your blog posts everywhere from one place. With a single click, you can send your articles to platforms like Medium, Substack, Hashnode, Dev.to, and more.

Crosspost - Write once, publish everywhere.

It’s built for creators who want maximum reach without copying and pasting across sites. Just connect your accounts, upload or paste your post, and Crosspost handles the rest.

Each version is formatted to match the destination platform, keeping your content clean and consistent — so you focus on writing once, and let Crosspost handle the rest.

Getting Started with Blogbuster

Starting with Blogbuster is surprisingly fast and intuitive. Here’s a breakdown of how to set up your autoblog in under 10 minutes:

1. Sign Up and Create a Project

Visit Blogbuster’s website and sign up for an account. After logging in, enter your domain URL and let Blogbuster scrape your project and generate the brand info, audience and tone in 2–3 minutes. You can also customize these if you want.

To get you started, Blogbuster will let you choose one of three suggested topics to generate an article about.

2. Set Your Content Preferences

Head over to Settings in Blogbuster to set your brand and content preferences. You can set preferences for brand logo, name, description, and target audience, as well as content preferences like length, specific instructions, exclusions, and much more.

For me, because tables are not supported on Medium and can have funny behaviours in different platforms, I added the instruction “Do not generate tables or any advanced formatting”.

3. Pick Topics or Let AI Decide

Next, head over to Topics. Here you can see the topics generated by Blogbuster based on your domain, or you can generate new ones if you are a paying customer.

For each generated topic, you can choose to schedule or generate immediately. For this tutorial, click “Generate Now” to generate the articles. This could take a while, and you will receive an email once the article is fully generated!

4. Publish Articles

Head over to Article to view generated articles. Here, you can open each article to make any edits you may want. When satisfied with what you have, publish the article.

5. Generate API token

To be able to import and crosspost articles generated by Blogbuster on Crosspost, you will need a Blogbuster API key. To get this, head over to Settings > Integrations and click on Generate to get a new key.

Store this key safely!

Setting up Crosspost

Now that we are done with the Blogbuster side of the setup, we now need to setup Crosspost to import and publish the generated articles across the internet.

1. Set up a Crosspost account

Head over to Crosspost to create a new account easily.

2. Add integrations

You will need to connect your Blogbuster account on Crosspost. Also, you will need to connect target platforms where you want to publish.
Navigate to Integrations > Blogbuster, paste in your Blogbuster API key, then click on “Choose” to select the tenant (project) you want to import from. Then save the integration.

Do this for other platforms (e.g DEV, Medium, Hashnode) where you want to publish to.

3. Import from Blogbuster

Click on the pencil icon on the navigation bar and then “New” to start a new article on Crosspost. On the edit page that shows next, click on “Import from…” and select Blogbuster.

This will open a modal that lists all published articles on Blogbuster and you will be able to choose one from the list. Select the one you wish to crosspost and “Import selected”.

4. Crosspost!

After making sure everything looks good and imported correctly — which I’m sure is the case — go ahead and click on the Continue button and select all connected platforms you wish to publish to.

You can also click on Advanced Settings to set properties like canonical URL, tags, SEO properties and more. When ready to publish, click on Publish and watch your content distributed everywhere at once!

Further reading:

• https://medium.com/write-once/why-crossposting-your-articles-is-a-superpower-if-you-do-it-right-7aa77b9e7282

• https://medium.com/write-once/the-ultimate-guide-to-streamlined-publishing-for-writers-and-bloggers-a8ef65760c7b

• https://www.blogbuster.so/blog/How-to-Use-AI-to-Craft-Evergreen-Blog-Content-That-Ranks-Long-Term

• https://www.coleruche.com/post/content-syndication-vs-crossposting-0be12da9

TL;DR:

Content syndication is when third parties republish your content (with credit).

Crossposting is when you publish the same content across multiple platforms yourself.

In the rapidly evolving digital landscape, content is king. Whether you’re a blogger, an entrepreneur, or a marketer, the ability to share and disseminate your content widely is crucial for building an audience and establishing authority in your niche. Two prevalent strategies for distributing content are content syndication and crossposting. While they may seem similar at first glance, they serve different purposes and have distinct implications for content creators and marketers. In this article, we will explore the nuances of content syndication and crossposting, helping you understand when and how to use each strategy effectively.

Understanding Content Syndication

Content syndication refers to the process of republishing your content on third-party sites, with the intent of reaching a broader audience. This practice can be beneficial in several ways:

1. Reach and Visibility: By syndicating your content, you can tap into the existing audience of larger platforms. This is particularly advantageous for new bloggers or brands looking to gain traction. For example, a well-established website in your niche may have thousands of visitors daily. If your article appears there, it can introduce your work to potential readers who may not have discovered you otherwise.

2. SEO Benefits: While some may worry about duplicate content penalties from search engines, reputable syndication platforms often include canonical tags that point back to the original article on your site. This means that search engines understand where the content originated, preserving your SEO ranking.

3. Brand Authority: Being featured on reputable sites can enhance your brand’s credibility. When audiences see your content on trusted platforms, they are more likely to view you as an authority in your field.

However, it’s essential to choose syndication partners wisely. Not all platforms offer the same benefits, and low-quality sites may harm your brand’s reputation.

The Concept of Crossposting

Crossposting, on the other hand, involves sharing the same piece of content across multiple platforms simultaneously, often with the intention of engaging different audiences on each platform. This technique is commonly used on social media channels, forums, and other online communities. Here are some key attributes of crossposting:

1. Audience Engagement: Different platforms attract different demographics and interests. By crossposting, you can engage with varied audiences, tailoring your content to fit the nuances of each platform. For instance, a professional article might be suitable for LinkedIn, while a more casual version could resonate better on Facebook or Twitter.

2. Consistency in Messaging: Crossposting allows for consistent messaging across various channels. When executed properly, this strategy reinforces your brand voice and keeps your audience informed, regardless of the platform they are using.

3. Time Efficiency: Content creation is a labor-intensive process. Crossposting allows you to maximize the value of your content by sharing it across multiple platforms quickly. This efficiency can be particularly beneficial for busy professionals who need to maintain an active online presence without dedicating excessive time to content creation.

However, crossposting can be tricky. Each platform has its own culture, and what works on one might not work on another. It’s important to adapt your content slightly—such as changing the tone or format—to suit the audience of each platform, rather than simply copying and pasting the same text everywhere.

Key Differences Between Syndication and Crossposting

While both content syndication and crossposting aim to increase visibility and reach, several key differences set them apart:

• Purpose: The primary purpose of syndication is to leverage the audience of another platform to gain exposure, while crossposting focuses on engaging different audiences across multiple platforms simultaneously.

• Control: In syndication, content creators often relinquish some control over how their content is presented, as it is republished by another site. In contrast, crossposting allows for more direct control, enabling you to tailor your content to fit each platform’s unique style and audience.

• SEO Implications: Syndicated content typically includes canonical links, protecting the original source’s SEO ranking. Conversely, crossposting may not always have these safeguards, which could lead to duplicate content issues if not managed correctly.

Best Practices for Content Syndication and Crossposting

To make the most of both syndication and crossposting, consider the following best practices:

1. Choose the Right Platforms: For syndication, select reputable sites that align with your brand values and target audience. For crossposting, ensure that the platforms you choose are relevant to your content and conducive to engagement.

2. Tailor Your Content: When crossposting, it’s essential to slightly modify your content for each platform. This could mean changing the headline, adjusting the tone, or adding platform-specific elements (like hashtags for Twitter or images for Instagram).

3. Monitor Performance: Use analytics tools to track how your content performs across different platforms. This information can guide your future content strategy, helping you identify what works best for your audience.

4. Utilize Tools: Platforms like Crosspost can assist in simplifying crossposting efforts. This user-friendly tool enables you to schedule posts, track engagement, and streamline your content distribution process, ensuring consistency and efficiency.

Conclusion

In conclusion, both content syndication and crossposting are valuable strategies for increasing your content's reach and engagement. While they share a common goal of enhancing visibility, they differ significantly in their execution and implications for content creators. Understanding these differences will empower you to make informed decisions about how to share your content effectively.

By leveraging the right combination of syndication and crossposting, and utilizing tools like Crosspost, you can enhance your online presence, engage with diverse audiences, and ultimately achieve your content marketing goals. As the digital landscape continues to evolve, mastering these strategies will be essential for anyone looking to thrive in the competitive world of content creation.

Once upon a time in the realm of digital marketing, there was a revolutionary concept that changed the way businesses approached online visibility: Search Engine Optimization, or SEO. As Google began to dominate the search landscape in the early 2000s, savvy marketers recognized the power of optimizing website content to rank higher in search results. The marriage of keyword strategy, backlinks, and user experience became the holy grail for driving traffic and engagement. Fast forward to today, and we find ourselves in a world where content marketing has evolved into a sophisticated ecosystem, thanks to the rise of generative AI tools like ChatGPT, Claude, Perplexity, and Gemini.

These AI models are not just reshaping how we create content; they are redefining the very essence of how we think about optimization. Enter Generative Engine Optimization (GEO), a modern approach that focuses on optimizing content not for traditional search engines but for generative AI models that deliver direct, conversational answers to user queries. As we navigate this new landscape, it's essential to understand what GEO entails, how it influences content strategy, and the key strategies that can enhance your efficacy in this evolving domain.

The Shift from SEO to GEO

Traditional SEO was primarily concerned with aligning content to the algorithms of search engines, ensuring that keywords were strategically placed and that backlinks were acquired to boost authority. However, with the advent of generative AI, the paradigm is shifting. These AI tools do not just index and rank content; they generate it, providing users with concise, relevant responses drawn from a vast array of sources. This means that the focus of content creators is no longer solely on driving traffic to their websites but also on ensuring that their content is optimized for these AI's understanding and generation processes.

Generative AI is built on complex algorithms that analyze language patterns, context, and user intent. As a result, content must be structured and presented in a way that these models can easily parse and utilize. GEO is thus born out of the necessity to adapt content strategies to a world where AI is the intermediary between the creator and the consumer.

Key Strategies for Generative Engine Optimization

As we embrace GEO, there are several critical strategies to consider that can help ensure your content resonates with both AI models and human readers.

1. Writing Factual and Easily Digestible Content

Generative AI thrives on clarity and accuracy. Therefore, it is essential to focus on factuality in your content. Information must be presented in a straightforward manner, free from jargon and complex language that could confuse both AI and users. Short paragraphs, bullet points, and clear headings can enhance readability, making it easier for generative models to extract relevant information.

2. Using Explainer or Q&A Formats

Generative AI tools often pull data to answer specific questions. Creating content in an explainer or Q&A format can significantly enhance the chances of your information being utilized by these models. Structuring your content to address common queries or to explain key concepts can help ensure that your insights are the ones that generative engines serve up when users seek answers.

3. Including Authorship and Trust Signals

In a world filled with misinformation, trust is paramount. Including authorship and credibility markers in your content can help establish authority. This can be achieved by integrating author bios, references to reputable sources, and statistics from trusted organizations. Generative AI models favor content that demonstrates expertise and reliability, making this an essential aspect of GEO.

4. Structuring Content for Machine Parsing

To enhance the likelihood of your content being recognized and used by generative AI, it’s vital to structure it in a way that machines can easily parse. This includes using clear headings, subheadings, and well-organized sections. Incorporating schema markup can also improve how search engines and generative models understand the context of your content, thereby enhancing its visibility.

5. Making Content Accessible to Real-Time Engines and Prompting Communities

Generative AI is continually learning and adapting. Therefore, your content should be accessible and relevant to real-time engines. This means keeping your information up-to-date and engaging with communities that share your content. By fostering dialogue and encouraging interaction, you can enhance your content's relevance and visibility in the eyes of generative engines.

Moreover, tools like Crosspost are already helping creators prepare for this shift by making multi-platform publishing effortless. By allowing content creators to write once and publish across various platforms, Crosspost simplifies the distribution process and aligns seamlessly with GEO principles. This ensures that your optimized content reaches diverse audiences, maximizing its impact.

Conclusion

As we stand on the precipice of this new era in content strategy, Generative Engine Optimization is a powerful concept that every content creator should embrace. By understanding the core principles of GEO and implementing key strategies, you can ensure that your content not only meets the needs of traditional search engines but also resonates with generative AI models that shape the future of information retrieval.

For those eager to delve deeper into the capabilities of modern tools in this evolving landscape, I invite you to explore this blog post. This resource will provide you with further insights into how you can streamline your content generation processes while adapting to the shifts in digital marketing.

In the world of content creation, staying ahead of the curve is not just advantageous; it is essential. Embrace GEO, adapt your strategies, and watch your content thrive in the age of generative AI.

The average person in the United States spends over 7 hours looking at a screen each day, according to Exploding Topics' 2024 screen time statistics. Much of that interaction is with websites and web applications, all brought to life by frontend development. If you're looking to step into this creative and in-demand field, understanding the fundamentals is key for starting frontend development.

Getting Started with Frontend Development

Frontend development is all about crafting what you directly see and interact with on a website or application. It’s the art and science of transforming design concepts into the responsive, functional digital interfaces that users engage with every day. Think of it as building the 'storefront' of the digital world. While the array of technologies involved might seem like a steep climb at first, remember that consistent effort, a structured approach to learning, and good guidance make mastering these skills entirely achievable and incredibly rewarding. This article will walk you through ten core tips, carefully chosen to help frontend basics new developers navigate the early stages of their learning journey and build a solid foundation for a future in this exciting field.

Tip 1-3: Mastering The Core Trio: HTML, CSS, JavaScript

At the heart of all web experiences are three cornerstone technologies. Understanding these is non-negotiable for any aspiring frontend developer, as they form the bedrock of all essential web dev skills.

Tip 1: Build Solid Structures with Semantic HTML

HTML, or HyperText Markup Language, provides the skeleton for your web content. It’s not just about putting text on a page; it’s about structuring it meaningfully. Using semantic HTML5 tags like <article>, <nav>, <header>, and <footer> does more than organize your content. It significantly boosts website accessibility for users relying on assistive technologies and improves how search engines understand your site.

Tip 2: Master Visual Styling with CSS Fundamentals

CSS, Cascading Style Sheets, is what brings visual life to your HTML structure. It controls everything from layout and colors to typography and spacing. Key concepts to grasp early include the box model (content, padding, border, margin), how selectors target HTML elements, and specificity, which dictates which styles apply when conflicts arise. For precision in styling, understanding different units is crucial; you can explore more about Units of Measurements in CSS to refine your approach.

Tip 3: Implement Interactivity using JavaScript Basics

JavaScript is the engine that powers interactivity and dynamic content on websites. For beginners, focusing on the HTML CSS JS basics is key. This means getting comfortable with core programming concepts such as variables for storing data, understanding different data types, writing functions for reusable code, and learning fundamental Document Object Model (DOM) manipulation to change webpage content and style in response to user actions.

Tip 4-6: Adopting Essential Tools and Practices

Beyond the core languages, certain tools and practices are fundamental to an efficient and professional workflow. Adopting these early will significantly streamline your development process.

Tip 4: Choose and Master Your Code Editor

Your code editor is your primary workspace. Visual Studio Code (VS Code) is a popular choice for its features and customization. Learn its productivity tools: extensions like Prettier for formatting, Live Server for real-time previews, and ESLint for error checking, plus keyboard shortcuts and the integrated terminal. This is one of the essential web dev skills to cultivate.

Tip 5: Implement Version Control with Git Early On

Git is an indispensable tool for source code management. Even if you're working on solo projects, using Git from the start is a best practice. It allows you to track changes, revert to previous stable versions if something goes wrong, and is crucial for collaboration. Get comfortable with basic commands:

• git add: Stage changes for commit.

• git commit -m "commit message": Save staged changes with a descriptive message.

• git push: Upload local commits to a remote repository.

• git pull: Fetch and merge changes from a remote repository.

• git branch <branch-name>: Create a new branch.

• git checkout <branch-name>: Switch to a different branch.

Tip 6: Leverage Browser Developer Tools for Debugging

Modern browsers like Chrome, Firefox, and Edge offer powerful developer tools. Use them for inspecting HTML and CSS, debugging JavaScript using breakpoints and variable inspection, analyzing performance, and monitoring network requests. Mastering the inspector, console, and network tabs is crucial. For a practical walkthrough, Mozilla Developer Network's guide on What are browser developer tools? is an excellent resource.

Tip 7-9: Building and Learning Effectively

Knowing the languages and tools is one thing; applying that knowledge effectively is another. These next tips focus on how to truly solidify your skills and build for the modern web.

Tip 7: Solidify Knowledge by Building Small, Tangible Projects

To truly learn frontend development, you must move beyond tutorials and build. Hands-on practice solidifies concepts and hones problem-solving. Start with small, tangible projects like:

• A personal portfolio to showcase your work.

• A simple to-do list app for JavaScript and DOM practice.

• Replicating a basic webpage layout to apply HTML and CSS.

• A basic calculator for logic.

• A weather app using a free API for data handling.

Tip 8: Prioritize Learning Responsive Design Principles

Websites must look and work well on all devices. Responsive design is crucial, especially with high mobile usage in the US. Key techniques include:

• Fluid grids using relative units.

• Flexible images and media that scale correctly.

• CSS Media Queries to apply styles based on device features like screen width.

Mastering these ensures a good user experience for everyone.

Tip 9: Write, Write, and Write Some More!

A very important tip I am glad I caught early on in my career is the importance and art of writing. It is not enough to learn all you will. It is super important to teach these online as well. Set up your own hosted blog, or simply write on Medium. 

Blogging forces you to organize your thoughts, spot gaps in your understanding, and retain knowledge better. It also builds your online footprint, shows proof of your growth, and helps others learn—turning you from just a learner into a contributor. Mohab dives deeper into the importance of writing in this Medium article.

Given that there are so many platforms to publish to (Medium, DEV, Hashnode, Ghost, etc), it makes it daunting to write and effectively get your content wide. But with tools like Crosspost, you can publish your articles once and effortlessly share them across platforms like Medium, Dev.to, and Substack—so more people benefit from what you’ve learned.

Tip 10-11: Advancing Your Frontend Skills

Once you have a firm grasp of the fundamentals, you can start exploring more advanced tools and cultivate habits for long-term growth in this dynamic field.

Tip 10: Consider a JavaScript Framework or Library After Mastering Basics

Once HTML, CSS, and vanilla JavaScript are solid, consider a framework like React, Vue.js, or Angular. These tools offer pre-built components and patterns for building complex UIs efficiently. But don't rush; strong fundamentals are key. Frameworks like React JS simplify tasks such as uploading images to a REST API backend in React JS. To understand React's popularity, resources like freeCodeCamp's React.js for Beginners – A 2024 Tutorial are helpful.

Tip 11: Cultivate a Habit of Continuous Learning and Curiosity

Frontend development is always changing. To effectively learn frontend development and stay current, adopt a mindset of lifelong learning. Stay updated by:

• Reading industry blogs.

• Following official documentation.

• Engaging with developer communities like Stack Overflow, Dev.to, Reddit, or local US meetups.

• Taking online courses for deeper dives.

This keeps your skills sharp.

Your Next Steps in Frontend

Where do you go from here? With these insights, your frontend journey is off to a strong start.

Recapping Your Foundational Toolkit: These ten beginner frontend tips provide a solid launchpad, covering core practices and knowledge to build upon.

The Ongoing Journey of a Developer: Frontend development is a continuous process of learning, problem-solving, and adapting. Be patient, persist through challenges, and celebrate your progress. Every problem solved is a step forward.

Finding Resources and Community Support: Seek quality learning materials. In-depth tutorials and practical guides can be found online everywhere, like on my blog Connect with other developers through online communities or local US-based groups. Sharing knowledge and getting support is invaluable. The path of a frontend developer is rewarding, full of creative opportunities.

In an environment brimming with content, getting your voice heard requires more than just compelling writing. Many creators find their carefully crafted articles reach only a fraction of their potential audience. This guide explores how a smart approach to publishing can amplify your message, helping you connect with more readers without multiplying your workload.

The Modern Writer’s Publishing Challenge

The digital landscape presents a curious paradox for writers and bloggers. While opportunities to share work have never been more abundant, the path to visibility is often cluttered with repetitive tasks and strategic dilemmas. The core issue is that creating great content is only half the battle; distributing it effectively is the other, often more complex, half.

There’s a growing expectation to publish on multiple platforms. Readers congregate in different digital spaces. Platforms like Medium attract a broad audience interested in diverse topics, Dev.to serves as a hub for the developer community, personal blogs offer a dedicated space for an author’s unique brand, and LinkedIn Articles cater to professional networking and industry insights. To truly grow an audience, a presence across several of these is becoming less of a choice and more of a necessity. Each platform offers access to distinct reader segments, and neglecting them means leaving potential engagement on the table.

This multi-platform ambition, however, often leads to a significant time sink through manual publishing. Writers frequently describe the frustration of adapting formatting for each site, the mind-numbing repetition of uploading, tagging, and scheduling content multiple times. These tasks, while seemingly small individually, accumulate, diverting precious hours away from the primary activities of writing, researching, and engaging with readers. It’s a drain that many creators feel acutely, wondering if the effort to reach wider is worth the sacrifice in creative output.

Beyond the time commitment, maintaining consistency and brand voice across these varied channels presents another hurdle. When managing multiple platforms manually, ensuring uniform quality, tone, style, and even simple branding elements like author bios or calls to action becomes a juggling act. The risk of inconsistencies is high, potentially diluting a writer’s carefully cultivated brand identity or, worse, confusing their audience with mixed messages or varying presentation standards.

Ultimately, content confined to a single platform may never reach its full potential impact. This siloed approach means that valuable insights and stories are missed by large swathes of potential readers. The absence of a streamlined publishing process translates directly into missed opportunities for broader visibility, engagement, and influence. These are the pain points that drive writers to seek more efficient ways to share their work.

Foundations of Effective Content Distribution

Moving beyond the frustrations of manual publishing requires a strategic shift in thinking. Before diving into tools or techniques, laying a solid foundation for your content distribution strategy is essential. This isn’t about working harder, but smarter, ensuring every piece of content has the best possible chance to find its audience.

The first step is defining your content distribution goals. What do you hope to achieve with your writing? Are you aiming for increased brand awareness, generating leads for a service, building a vibrant community, or establishing yourself as a thought leader in your niche? Your primary objectives will significantly influence where and how you distribute your content. For instance, if thought leadership is key, platforms that encourage in-depth articles and professional networking might take precedence. Clarity on these aims provides a compass for all subsequent distribution choices.

With goals in mind, the next crucial element is understanding your audience’s platform preferences. It’s tempting to cast a wide net, but not all platforms are suitable for all types of content or every target audience. Consider where your ideal readers spend their time. Developers, for example, are likely to frequent Dev.to for technical articles and community discussions, while a more general audience seeking lifestyle or business insights might be more active on Medium. Researching these preferences, perhaps by observing where similar successful creators engage, is vital. For those looking to explore this further, searching for ‘best practices for multi-platform content strategy for bloggers’ can yield valuable resources and deeper insights into audience analysis.

This leads naturally to the principle of ‘Write Once, Publish Strategically’. This concept is central to efficient content distribution. It involves creating one high-quality, well-crafted piece of content and then thoughtfully disseminating it across your chosen platforms. The aim is to maximize reach and impact with minimal redundant effort, ensuring your core message is delivered effectively in multiple relevant spaces.

It’s also important to clarify the distinction between crossposting articles and content repurposing, as these terms are sometimes used interchangeably. While both are valuable, this guide focuses on the former.

Crossposting Articles:

• Involves publishing largely the same article across multiple platforms.

• Focuses on extending the reach of existing written content with minimal changes.

• Aims for efficiency in distribution to tap into different platform audiences.

Content Repurposing:

• Involves transforming an existing piece of content into a different format (e.g., an article into a video, podcast episode, or infographic).

• Focuses on adapting the core message for different consumption preferences and platforms.

• Often requires more significant creative effort to reformat and re-present the information.

Understanding this difference helps maintain focus on streamlining the direct publishing of your articles to various platforms.

Actionable Steps to Streamline Your Publishing Process

Once you have a clear strategy, the next phase involves implementing practical steps to make your publishing workflow more efficient. These actions are designed to reduce friction and free up your time, allowing you to focus more on creation and less on the mechanics of distribution. Many of these can be considered essential blogging efficiency tips.

1. Creating a Master Content Calendar: A structured content calendar is more than just a schedule; it’s a strategic tool. By planning your content topics, target platforms, and publishing dates in advance, you can maintain a consistent output and coordinate your efforts far more effectively. This visual roadmap helps you see at a glance what needs to be written, edited, and published, preventing last-minute rushes and ensuring a steady flow of content to your audience. It transforms publishing from a reactive task to a proactive strategy.

2. Developing Templates and Basic Style Guides: Consistency is key to building a recognizable brand, but achieving it manually for every post on every platform can be tedious. Creating simple formatting templates, such as pre-set markdown for Dev.to or standard heading styles for Medium, can save considerable time. Alongside this, a concise style guide outlining your preferred tone, voice, common terminology, and image guidelines ensures that your content maintains a professional and uniform presentation with minimal effort for each new piece. Think of it as creating a kit of parts for quick assembly.

3. Batching Your Publishing Tasks for Efficiency: The human brain isn’t designed for constant context switching. Grouping similar tasks together, known as batching, can significantly improve focus and productivity. For example, you could dedicate specific blocks of time to writing several articles, then another block to formatting all of them for their respective platforms, and a final block to scheduling or publishing them. This approach minimizes the mental gear-shifting that occurs when you try to do everything for one article before moving to the next. Writers keen on mastering this can find more by searching for ‘content batching techniques for writers productivity’.

4. Optimizing Content for Each Platform (Without Sacrificing Efficiency): While the core of streamlined publishing is about using the same fundamental content, minor platform-specific adjustments can enhance performance. This doesn’t mean a full repurposing effort for each platform. Instead, consider small tweaks like crafting unique, compelling titles tailored to what resonates on a particular site, using relevant tags or categories specific to that platform’s discovery system, or slightly modifying introductions or conclusions to better align with the platform’s audience expectations. The goal is to find a practical balance: achieve maximum efficiency from your standardized content while making small, high-impact customizations where they matter most.

By implementing these steps, you can build a more robust and less time-consuming publishing process, allowing your content to work harder for you.

Choosing the Right Publishing Automation Tools

While manual streamlining techniques significantly improve efficiency, leveraging technology through publishing automation tools can further enhance your streamlined publishing efforts. These tools are designed to handle the repetitive aspects of distribution, allowing you to focus on what you do best: creating compelling content. Selecting the right tool, however, requires careful consideration of your specific needs.

When evaluating a crossposting solution, there are several key features to look for. These functionalities determine how effectively the tool can integrate into your workflow and support your distribution goals:

• Support for your primary publishing platforms: Ensure the tool seamlessly integrates with the platforms you use most, such as Medium, Dev.to, WordPress, or LinkedIn.

• An intuitive user interface: The tool should be easy to learn and use. A complicated interface can create more work than it saves.

• Content scheduling capabilities: The ability to schedule posts in advance is crucial for maintaining a consistent publishing rhythm without needing to be online at specific times.

• Effective handling of formatting nuances: Different platforms have different formatting requirements. A good tool will manage these variations, preserving your content’s intended appearance as much as possible.

The tangible benefits of automation are significant. Specialized tools minimize manual errors, such as formatting mistakes, forgotten tags, or missed posts, which can easily occur when juggling multiple platforms. More importantly, they free up substantial amounts of time. This reclaimed time can be reinvested into content creation, research, or, crucially, engaging with your audience. For instance, services like Crosspost are specifically designed to automate the distribution of articles to platforms like Medium and Dev.to, embodying these efficiencies by simplifying how writers publish on multiple platforms.

There is a range of publishing tools available, from simple browser extensions that offer basic copying features to comprehensive, dedicated platforms that provide a full suite of management and analytics capabilities. When evaluating different types of publishing tools, assess your specific needs. Consider your content volume: are you publishing daily, weekly, or monthly? What is your budget? A solo blogger with a few articles a month might have different requirements than a content team producing daily updates. The aim is to select a solution that is appropriate for your scale and complexity.

Finally, integrating automation smoothly into your existing workflow is key to its success. A new tool should complement, not complicate, your creative process. Start by using its core features, focusing on the aspects that provide the most immediate time savings. Gradually explore more advanced options as you become comfortable. The best automation tool is one that feels like a natural extension of your publishing habits, quietly working in the background to amplify your reach.

Amplifying Your Voice Across Platforms

Adopting a streamlined, multi-platform publishing approach offers more than just time savings; it fundamentally changes how your voice resonates in the digital sphere. The strategies and tools discussed are not merely about efficiency, but about maximizing the impact of your hard-earned content and building a stronger, more visible presence as a writer or blogger.

The most immediate outcome is the multiplier effect on reaching diverse audiences. When you publish on multiple platforms, you significantly broaden your content’s exposure. Each platform, be it Medium, Dev.to, or your personal blog, cultivates a unique user base with distinct interests and consumption habits. Effective crossposting articles allows you to tap into these varied communities, helping to increase blog reach far beyond what a single outlet could achieve. It’s about meeting readers where they are, rather than hoping they find you in one isolated corner of the internet.

There are also SEO considerations for strategic crossposting. Distributing your content on reputable platforms like Medium and Dev.to can contribute positively to your overall online visibility, partly due to their high domain authority. While concerns about content duplication sometimes arise, many platforms utilize mechanisms like canonical tags to indicate the original source to search engines. For many creators, the substantial benefit of increased reach and referral traffic from these authoritative sites often outweighs minor SEO complexities, especially when content is shared thoughtfully.

Furthermore, a regular and consistent appearance on multiple relevant platforms works to build a consistent brand presence and authority. When readers encounter your insightful articles across different channels, it reinforces your expertise and strengthens your personal or professional brand. This sustained visibility helps establish you as a knowledgeable and reliable voice in your niche, fostering trust and credibility over time. Each piece of content becomes another touchpoint, solidifying your reputation.

Finally, it’s crucial to remember that streamlined publishing is not just about the act of distribution; it also frees up invaluable time for engagement post-publishing. The efficiency gained means you have more capacity to interact with comments, respond to questions, and participate in discussions on each platform where your content appears. This interaction is vital for fostering a community around your work, gathering feedback for future content, and building genuine relationships with your readers. Ultimately, effective publishing is a means to a greater end: meaningful connection and amplified impact.

Photo by Alexa Williams on Unsplash

Today, it is not a new practice to use Markdown files as a data source for (statically generated) blogs. I use it to write on my blog, powered by Next.js and Vercel.

It comes with a number of advantages:

1. Simplicity and Focus: Markdown is easy to read and write. Its minimal syntax lets you focus on content, not formatting, making it perfect for distraction-free writing.

2. Portability: Markdown files are plain text, meaning they’re lightweight, cross-platform, and can be opened or edited with any text editor or version control system.

3. Version Control Friendly: Because Markdown is plain text, it works seamlessly with Git. You can easily track changes, collaborate via pull requests, and roll back edits.

4. Static Site Compatibility: Static site generators like Next.js, Gatsby, Jekyll, and Hugo support Markdown natively, making it ideal for content-driven sites and blogs.

5. Flexible Output: Markdown can be converted to HTML, PDF, DOCX, and more using tools like Pandoc or markdown parsers—great for repurposing content across platforms.

Modern blogs powered by static site generators like Next.js, Gatsby, Jekyll, and Hugo often rely on Markdown files for managing content. However, manually writing .md files and committing them to your repo for every blog post can be tedious. That’s where Crosspost’s Webhook integration feature comes in. It enables you to automate the creation of Markdown files from posts you write once, streamlining publishing across your blog and third-party platforms.

Understanding the workflow

Here’s how I use it:

The integration involves setting up a webhook that listens for new content events from Crosspost and providing this webhook’s URL to Crosspost. When a new article is published (or cross-posted) on Crosspost, Crosspost sends out event data to the provided webhook URL. The webhook triggers a function that:

1. Receives the article data: Captures the title, content, and metadata, etc.
2. Generates a Markdown file: Formats the content into Markdown syntax and saves it in your project’s designated folder.
3. Commits to Version Control: Checks out the current branch to a new one, creates and commits the new file to your Git repository while maintaining a history of changes, and automatically opens a new pull request for the new article file.
4. Triggers a site rebuild: If you’re using platforms like Netlify or Vercel, the new commit (and PR) can automatically trigger a site rebuild, giving you a preview of the new article. You can then simply merge the new PR, publishing your new content live.

Writing the webhook

As I mentioned, my blog is built on Next.js and deployed to Vercel. However, this will work almost the same way with little adjustments to suit your tech stack.

To get this to work, you will need some external packages:

1. Octokit: Octokit is GitHub’s official JavaScript/TypeScript client for interacting with the GitHub REST and GraphQL APIs. It allows developers to programmatically manage repositories, issues, pull requests, commits, and more using simple, structured methods.
2. Turndown: Turndown is a JavaScript library that converts HTML into clean, structured Markdown.

To install these packages, run the command:

yarn add @octokit/rest turndown

You will also need to create a GitHub personal access token (PAT) to authorize the creation of the remote branch and pull request. Visit the official documentation to create your PAT and provide the necessary Read and Write permissions.

Required permissions for GitHub PATs

It is advised to verify webhooks (of any source and type) to make sure they are intended and coming from the right source. Crosspost generates and provides a webhook secret, which can be found on the Webhook integration screen and is subsequently set in the X-Webhook-Signature header of the webhook POST calls. This can be used to confirm the call is actually coming from Crosspost and no one else who knows your webhook endpoint will send unwanted or malicious data to it.

Screenshot highlighting the webhook secret from Crosspost

Take care to store these highly sensitive tokens securely in a .env file. Never commit sensitive keys to git.

The next step is to create a new route handler. In this file, I added the code below:

import { Octokit } from '@octokit/rest'  
import { NextResponse } from 'next/server'  
import TurndownService from 'turndown'  
  
const REPO\_OWNER = 'your\_gh\_username'  
const REPO\_NAME = 'your\_blog\_repo\_name'  
const POSTS\_PATH = 'src/content/posts' // or path to your posts directory  
const GITHUB\_TOKEN = process.env.GITHUB\_TOKEN // your GH PAT, securely written in a .env file  
  
function slugify(str: string) {  
  return str  
    .toLowerCase()  
    .replace(/\[^a-z0-9\]+/g, '-')  
    .replace(/^-+|-+$/g, '')  
    .substring(0, 50)  
}  
  
export async function POST(request: Request) {  
  try {  
    // verify webhook signature from Crosspost  
    const signature = request.headers.get('X-Webhook-Signature')  
    const expectedSignature = process.env.AUTO\_PUBLISH\_WEBOOK\_SECRET // your Crosspost webook verification token  
    if (!signature || signature !== expectedSignature) {  
      return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })  
    }  
  
    const body = await request.json()  
    const {  
      id,  
      title,  
      description,  
      html\_content,  
      publishedAt,  
      slug,  
      canonicalUrl,  
      tags,  
    } = body  
  
    if (!title || !html\_content || !slug) {  
      throw new Error(  
        'One of the following required fields is missing: title, html\_content, slug',  
      )  
    }  
  
    if (!GITHUB\_TOKEN) {  
      throw new Error('Missing Github token in env')  
    }  
  
    // Convert HTML to Markdown  
    const turndownService = new TurndownService()  
    const markdownContent = turndownService.turndown(html\_content)  
  
    // Prepare frontmatter.   
    // This may differ from your own frontmatter structure  
    const frontmatter = \`---  
title: "${title.replace(/"/g, '"')}"  
description: "${description ? description.replace(/"/g, '"') : ''}"  
cover\_image: ""  
altText: "${title.replace(/"/g, '"')}"  
keywords: \[${(tags || \[\]).map((t: string) => \`"${t}"\`).join(', ')}\]  
published: true  
date: "${publishedAt || new Date().toISOString()}"  
canonicalUrl: "${canonicalUrl || ''}"  
originalId: "${id}"  
\---  
\`  
  
    const fileContent = \`${frontmatter}  
${markdownContent}  
\`  
  
    const fileName = \`${slug}.md\`  
    const filePath = \`${POSTS\_PATH}/${fileName}\`  
    const branchName = slugify(title) + '-' + new Date().getTime()  
  
    // Initialize Octokit  
    const octokit = new Octokit({ auth: GITHUB\_TOKEN })  
  
    // Get the default branch  
    const repo = await octokit.repos.get({ owner: REPO\_OWNER, repo: REPO\_NAME })  
    const defaultBranch = repo.data.default\_branch  
  
    // Create a new branch from the default branch  
    const defaultBranchRef = await octokit.git.getRef({  
      owner: REPO\_OWNER,  
      repo: REPO\_NAME,  
      ref: \`heads/${defaultBranch}\`,  
    })  
  
    await octokit.git.createRef({  
      owner: REPO\_OWNER,  
      repo: REPO\_NAME,  
      ref: \`refs/heads/${branchName}\`,  
      sha: defaultBranchRef.data.object.sha,  
    })  
  
    // Create the file in the new branch  
    await octokit.repos.createOrUpdateFileContents({  
      owner: REPO\_OWNER,  
      repo: REPO\_NAME,  
      path: filePath,  
      message: \`Add new post: ${title}\`,  
      content: Buffer.from(fileContent).toString('base64'),  
      branch: branchName,  
    })  
  
    // Create PR  
    const pr = await octokit.pulls.create({  
      owner: REPO\_OWNER,  
      repo: REPO\_NAME,  
      title: \`New post: ${title}\`,  
      head: branchName,  
      base: defaultBranch,  
      body: \`Automated PR to add new post: ${title}\`,  
    })  
  
    return NextResponse.json({ pr\_url: pr.data.html\_url })  
  } catch (e) {  
    console.warn(e)  
    let message = 'Unknown error'  
    if (typeof e === 'object' && e && 'message' in e) {  
      message = (e as { message: string }).message  
    } else if (typeof e === 'string') {  
      message = e  
    }  
    return NextResponse.json({ error: message }, { status: 500 })  
  }  
}

Code comments have been added to this file to explain what each block of code does. Also, note that my frontmatter (and generally, the Markdown content) structure may differ from what you have. So format accordingly. If all goes right, which it should, you will be able to see the new PR generated for you.

Here’s a demo showing this in action.

Automating the generation of Markdown articles with Crosspost was originally published in Write Once on Medium, where people are continuing the conversation by highlighting and responding to this story.

Photo by Joe Green on Unsplash

In today’s crowded digital landscape, writing great content is no longer enough. You need to make sure it reaches the right audience — and often, that means more than one platform.

This is where crossposting becomes your secret weapon. But while the idea seems simple — publish the same article across Medium, Dev.to, Hashnode, etc. — the execution is often messy. Done wrong, it can hurt your SEO, confuse readers, or make your content look spammy.

Done right? It multiplies your reach, builds your brand, and drives lasting traffic.

Let’s break it down.

What Exactly Is Crossposting?

Crossposting is the practice of sharing the same piece of content on multiple platforms. For example, you might publish an article on your blog, then repost it to Medium, Dev.to, and Hashnode to get in front of different communities.

But there’s a key distinction: crossposting is not copy-pasting.

Done properly, crossposting involves:

• Using canonical links to point search engines to the original
• Adapting content slightly for each platform’s audience
• Respecting formatting quirks of each platform

Why Crossposting Works

Here’s what you gain when you crosspost strategically:

More Reach for Less Work

Every platform has its own audience. By publishing on multiple sites, you tap into readers who may never discover your blog on its own.

SEO Benefits (If You Use Canonical URLs)

Canonical links tell Google which version is the “original,” avoiding duplicate content penalties. When done right, crossposting can actually boost your SEO with more backlinks and discoverability.

Audience Growth Across Platforms

Each community has its own vibe. Crossposting lets you plant flags in all of them, growing a diverse and loyal readership.

Future-Proofing Your Content

If a platform disappears (looking at you, Medium paywall experiments…), you’ve still got your work elsewhere. Think of it as content diversification.

The Pitfalls of Crossposting (and How to Avoid Them)

Let’s be honest: crossposting can be annoying.

Photo by 傅甬 华 on Unsplash

• You format your post in Markdown for Dev.to… but Medium wants rich text.
• You forget to add a canonical tag… and now Google thinks you plagiarized yourself.
• You’re copying, pasting, editing, tweaking… again and again.

This tedious, error-prone process is why many creators avoid crossposting entirely — or do it badly.

How to Crosspost Like a Pro

To do this right:

• Customize the intro for each platform’s tone
• Use canonical URLs to signal original authorship
• Adjust formatting for each platform’s quirks
• Space out your posts to avoid overlapping traffic
• Track performance across platforms

It’s a lot. Which is why I built a tool to help.

Meet Crosspost

I built Crosspost to scratch my own itch: I was tired of wasting time manually republishing my content.

Photo by Madison Oren on Unsplash

With Crosspost, you can:

• Write once
• Publish everywhere (Medium, Dev.to, Hashnode , Notion, etc— with more on the way)
• Automatically handle canonical tags, formatting, and syncing

It’s built for developers, indie hackers, and technical writers who want to spend more time writing and less time formatting.

Your content deserves more reach. Crossposting is a smart, high-leverage way to get it — if you do it properly.

And now, with the right tools, that’s easier than ever.

So the next time you publish something you’re proud of, don’t leave it sitting in one place. Spread it. Share it. Crosspost it.

Why Crossposting Your Articles Is a Superpower (If You Do It Right) was originally published in Write Once on Medium, where people are continuing the conversation by highlighting and responding to this story.

What are Server Actions?

Server Actions in Next.js 14 allow developers to define functions that run on the server, enabling them to perform tasks such as data fetching, form submissions, and other server-side logic without the need for additional API routes. This capability simplifies the architecture of applications by integrating server-side functionality directly into components, promoting a more cohesive development experience.

At their core, Server Actions are functions that can be invoked directly from client components. When a Server Action is called, it executes on the server, allowing you to harness the full power of your backend without the overhead of HTTP requests. This results in faster responses and a more seamless interaction for users.

Benefits of Using Server Actions

1. Improved Performance

One of the standout advantages of Server Actions is their ability to enhance performance. Since these functions execute on the server, they can access server resources directly, which reduces latency. By minimizing the number of round trips between the client and server, applications can respond more quickly to user interactions.

2. Simplified Codebase

With Server Actions, developers can eliminate the need for separate API endpoints for many common tasks. This results in a cleaner, more maintainable codebase. Instead of juggling multiple files and routes, you can encapsulate server logic directly within your components, leading to a more intuitive project structure.

3. Easier Data Management

Server Actions facilitate better control over data flows in your application. By handling data fetching and manipulation directly on the server, you can manage state more effectively, reducing the complexity often associated with client-side data handling.

4. Enhanced Security

With server-side execution, sensitive operations such as authentication, database access, and third-party API calls can be better secured. Server Actions help to prevent exposure of sensitive logic to the client, reducing the risk of malicious attacks.

Implementing Server Actions

To harness the power of Server Actions in your Next.js 14 application, follow these steps:

Step 1: Define a Server Action

You can define a Server Action by creating an async function within your component file. For example:

// app/page.js  
export const myServerAction = async (data) => {  
    // Perform some server-side logic, such as database operations  
    const result = await database.save(data);  
    return result;  
};

Step 2: Call the Server Action from the Client

You can invoke your Server Action from a client component using an event handler. This can be done in a form submission or any other user interaction:

// app/components/MyForm.js  
'use client';  
  
import { myServerAction } from '../page';  
  
const MyForm = () => {  
    const handleSubmit = async (event) => {  
        event.preventDefault();  
        const formData = new FormData(event.target);  
        const result = await myServerAction(formData);  
        console.log(result);  
    };  
  
    return (  
        <form onSubmit={handleSubmit}>  
            <input type="text" name="data" required />  
            <button type="submit">Submit</button>  
        </form>  
    );  
};

Step 3: Handling Responses

Once the Server Action is executed, you can handle the response within your client component. This could involve updating the UI, displaying messages, or redirecting users based on the outcome of the server operation.

Best Practices

When using Server Actions, consider the following best practices:

• Keep Actions Focused: Each Server Action should perform a single responsibility. This makes it easier to debug and reuse your actions across different components.
• Error Handling: Implement robust error handling within your Server Actions. This ensures that your application can gracefully handle failures and provide meaningful feedback to users.
• Optimize for Performance: Be mindful of any heavy operations within your Server Actions. Utilize caching strategies where appropriate to enhance performance further.

Conclusion

Server Actions in Next.js 14 represent a significant leap forward in simplifying server-client interactions. By allowing developers to run server-side logic directly within components, they improve performance, reduce complexity, and enhance security. As you explore this feature, you’ll find new ways to streamline your development process and create more responsive applications. Embrace Server Actions, and watch your Next.js applications reach new heights of efficiency and user satisfaction.

What is ReactNode?

ReactNode is a type that represents any type of React content that can be rendered. It's a union type that includes:

• React elements (created via JSX)
• Strings
• Numbers
• Arrays or fragments of the above
• null
• undefined
• booleans

Here's the TypeScript definition:

type ReactNode = React.ReactElement | string | number | React.ReactFragment | React.ReactPortal | boolean | null | undefined;

What is React.Element?

React.Element is a more specific type that represents a React element, which is the object returned by React.createElement() or JSX expressions. It's a concrete object with a specific structure.

Here's a simplified version of its TypeScript definition:

interface ReactElement<P = any, T extends string | JSXElementConstructor<any> = string | JSXElementConstructor<any>> {
  type: T;
  props: P;
  key: Key | null;
}

Key Differences

• Scope: ReactNode is broader and includes React.Element as well as primitive types and arrays. React.Element is more specific and only represents React elements.

• Usage: ReactNode is often used for component children or any prop that can accept various types of renderable content. React.Element is used when you specifically need a React element.

• Nullability: ReactNode can be null or undefined, while React.Element cannot.

• Type Safety: React.Element provides more type safety as it ensures you're working with a React element structure.

When to Use ReactNode

Use ReactNode when:

• Defining the type for children props.
• Working with content that could be of various types (elements, strings, numbers, etc.).
• Creating flexible components that can render different types of content.

Example:

interface Props {
  content: React.ReactNode;
}

const FlexibleComponent: React.FC<Props> = ({ content }) => {
  return <div>{content}</div>;
};

When to Use React.Element

Use React.Element when:

• You specifically need a React element and want to ensure type safety
• Working with higher-order components or render props that deal with elements
• Manipulating or analyzing the structure of React elements

Example:

interface Props {
  element: React.ReactElement;
}

const ElementWrapper: React.FC<Props> = ({ element }) => {
  return <div className="wrapper">{React.cloneElement(element, { className: 'modified' })}</div>;
};

Best Practices

• Default to ReactNode: When in doubt, especially for component children, use ReactNode. It provides more flexibility.

• Use React.Element for Specificity: When you need to ensure you're working with a React element and want to leverage its properties (like type or props), use React.Element.

• Consider Nullability: Remember that ReactNode can be null or undefined, so handle these cases in your components.

• Type Narrowing: When using ReactNode, you might need to narrow the type if you want to perform specific operations:

  if (React.isValidElement(node)) {
    // node is now treated as React.ReactElement
  }
  

• Generic Types: For more advanced use cases, consider using generic types with React.Element:

  function Wrapper<P>(props: { element: React.ReactElement<P> }) {
    return React.cloneElement(props.element, { className: 'wrapped' });
  }
  

Common Pitfalls and Potential Issues

When working with ReactNode and React.Element, it's important to be aware of potential pitfalls that can arise from using the wrong type. Here are some common issues and what could go wrong:

• Type Mismatch Errors:

  • Using React.Element when ReactNode is expected can lead to type errors, as React.Element is more restrictive.
  • Example: Trying to pass a string or number to a prop typed as React.Element will cause a compilation error.

• Unexpected Rendering Behavior:

  • Using ReactNode when you specifically need a React element can lead to unexpected rendering issues.
  • For instance, if you're using React.cloneElement() with a ReactNode, it might fail at runtime if the node isn't actually an element.

• Loss of Type Safety:

  • Overusing ReactNode can lead to a loss of type safety. While it's more flexible, it also means TypeScript can't provide as much help in catching errors.
  • This can result in runtime errors that could have been caught at compile-time with more specific typing.

• Null/Undefined Handling:

  • ReactNode can be null or undefined, but React.Element cannot. Forgetting to handle these cases can lead to runtime errors.
  • Example: Not checking for null when using a ReactNode prop could cause your component to crash if null is passed.

• Performance Implications:

  • Using ReactNode when React.Element would suffice might lead to unnecessary type checks at runtime, potentially impacting performance in large applications.

• Difficulty in Prop Manipulation:

  • When using ReactNode, you lose the ability to easily manipulate props of the passed elements.
  • If you need to clone and modify elements, using React.Element is more appropriate and safer.

To avoid these pitfalls:

• Always consider the specific needs of your component when choosing between ReactNode and React.Element.
• Use type narrowing and null checks when working with ReactNode.
• Prefer React.Element when you need to perform operations specific to React elements.
• Don't default to ReactNode for all cases; use it when you genuinely need the flexibility it offers.

By being aware of these potential issues, you can make more informed decisions about which type to use in different scenarios, leading to more robust and type-safe React applications.

Conclusion

Understanding the difference between ReactNode and React.Element is crucial for writing robust React applications, especially when using TypeScript. While ReactNode offers flexibility and is suitable for most cases where you need to render content, React.Element provides more specificity and type safety when working directly with React elements. By choosing the right type for your use case and being aware of potential pitfalls, you can improve the clarity, maintainability, and reliability of your React code.

Remember, the goal is to create components that are both flexible and type-safe. By mastering these types and understanding their implications, you'll be better equipped to achieve this balance in your React projects and avoid common issues that can arise from misusing these types.

What are Array<T> and T[]?

• Array<T>: This is a generic type provided by TypeScript. It signifies an array where each element is of type T.
• T[]: This is a shorthand notation for the Array<T> type. It also represents an array where each element is of type T.

Syntax Differences

The primary difference between Array<T> and T[] lies in their syntax. Here’s a quick comparison:

// Using Array<T>
let numbers: Array<number> = [1, 2, 3, 4];

// Using T[]
let numbersAlt: number[] = [1, 2, 3, 4];

Type Readability

In some cases, Array<T> can improve readability, especially when dealing with more complex types. Consider the following example:

// Using Array<T>
let arrayOfArrays: Array<Array<number>> = [[1, 2], [3, 4]];

// Using T[]
let arrayOfArraysAlt: number[][] = [[1, 2], [3, 4]];

While both notations are correct, Array<Array<number>> might be clearer in showing that the type is an array of arrays of numbers, whereas number[][] can sometimes be harder to parse visually.

Consistency with Other Generic Types

Using Array<T> can also be more consistent with other generic types in TypeScript. For instance, if you’re already using generics for other types like Promise<T> or Map<K, V>, it might make sense to use Array<T> for consistency:

let promises: Array<Promise<number>> = [Promise.resolve(1), Promise.resolve(2)];

Function Signatures

When defining function signatures, both Array<T> and T[] can be used interchangeably. However, in more complex generic functions, Array<T> might be preferred for clarity:

// Using Array<T>
function getFirstElement<T>(arr: Array<T>): T | undefined {
    return arr[0];
}

// Using T[]
function getFirstElementAlt<T>(arr: T[]): T | undefined {
    return arr[0];
}

Compatibility and Preferences

Both Array<T> and T[] are fully compatible with each other. It ultimately comes down to personal or team preference. Some developers prefer the concise T[] notation, while others favor the explicit Array<T> syntax for its readability and consistency.

Conclusion

In summary, Array<T> and T[] in TypeScript are two ways to define arrays, with subtle differences in syntax and readability. Both are equally valid and compatible, so choosing one over the other often comes down to personal preference or the need for consistency with other generic types.

Understanding these differences can help you write clearer, more maintainable TypeScript code. Whether you opt for Array<T> or T[], the key is to stay consistent with your choice across your codebase.

Happy coding!

Frontend development continuously adapts to enhance user accessibility (a11y). A key example is the automatic zoom on mobile browsers for input fields with a font size under 16 pixels. This feature, introduced with early smartphones around the mid-2000s, aims to improve readability on small screens.

The 16-Pixel Threshold

Set against the backdrop of increasing mobile internet usage, this feature was popularized by browsers like Safari on the first iPhone in 2007. The choice of 16 pixels as the threshold is based on average visual acuity and typical mobile screen reading distances, making smaller text more legible and interaction more user-friendly.

Implications for Developers

This auto-zoom behavior compels frontend developers to consider mobile user experience when designing web forms and input fields. A font size of 16 pixels or more can prevent unwanted zooming and maintain the intended layout, but it's crucial to balance this with the accessibility needs of users with visual impairments.

Best Practices

• Use Minimum Font Size of 16 Pixels: For design consistency and control over zoom behavior. This right here "fixes" the automatic zooming as well as maintains best a11y practices.
• Responsive Design: Adapt layouts for various screen sizes for optimal user experience.
• Accessibility Testing: Regularly check your site with accessibility tools and user feedback.

Conclusion

The auto-zoom feature in mobile browsers represents a significant step towards making web content accessible on smaller screens. Frontend developers must understand and incorporate this feature to create inclusive, user-friendly websites that cater to diverse user needs.

It is important to note that this feature is not a bug and nothing is broken in your design and implementation. Although, from an accessibility point of view, it is advised to use a minimum of 16px on form element sizes, but if doing this will break your UI, then you can safely ignore this behavior.

With the world of Web3 becoming increasingly costly to interact with, there comes the need at some point to look for alternative, cheap (and if possible, free) ways to get these tokens. That is where faucets come in.  
 
As the name suggests, faucets are programs and software that provide users with free tokens of the supported network. These tokens are usually quite small and may sometimes require users to complete certain tasks or meet specific requirements.

How do faucets work?

Typically, faucets involve the benefactor having a sufficient supply of these tokens and then providing a means for users to get these tokens for free by fulfilling certain requirements. These requirements can range from simple ones like posting to social media, subscribing to a newsletter or service, streaming videos, downloading content, or simply having an account with a service provider.  
 
Regarding the tokens, while very few of them are real ETH tokens spendable on the mainnet, most of them are actually ETH that is only usable on test networks like Sepolia or Goerli. These kinds of tokens are important for developers testing and developing on the blockchain where it would not make much sense to use real ETH which costs real money. Ideally would need to use fake ETH tokens to iterate new features and test out their code as many times as they need, for little or no money.  
These test tokens are also utilized by other participants in the Web3 world who participate in tasks and challenges that include testing out new blockchains and protocols.  
 

Top 5 faucets I have come across

Right away, I will be listing out some really nice Ethereum faucets I have come across, including shamelessly plugging in one of mine.

Goerli Drop

I built this simple faucet that gives out free test ETH tokens for the Goerli test network. The tokens can be as high as 0.05 ETH redeemable every 6 hours or so. The main requirement for getting this faucet is to be subscribed to my growing newsletter. On visiting the site, it automatically requests to switch to the Goerli network if MetaMask is installed and not on Goerli. Give it a try!

[UPDATE]: Goerli has been deprecated and is no longer supported. You can visit the new faucet I built for Sepolia.

Infura Faucet

This faucet was built by the incredible team at Infura, one of the leading blockchain technology companies. They have faucets for Sepolia and Linea networks. Their requirement? Simply create an account with them and log in to request for free 0.5 test ETH after completing a simple captcha. This is one of the most generous offerings I've encountered, and you are eligible for it once per day.

All That Node

The team at All That Node has a simple-to-use faucet that drips free 0.025 test ETH for Sepolia and Goerli once per day. No requirements are necessary. Simply specify where you'd like your tokens sent. (Please double-check your testnet address) and solve a captcha. However, at the time of writing this (Sept 10, 2023), the platform is down for maintenance.

Goerli Faucet and Sepolia Faucet

These awesome faucets were developed and are maintained by the Alchemy team. They are faucets that give out free 0.02 Goerli and 0.5 Sepolia ETH for the respective test networks, per day. To use this faucet, you have to be registered with the platform and signed in. However, for the Goerli faucet, you need to have a minimum mainnet balance of 0.001 ETH on the wallet address being used.

Ethereum Faucet by QuickNode

This faucet is one of the simplest faucets I have ever used. You only need to connect your wallet, select one of the many networks they support (or Ethereum in this case), choose between Sepolia and Goerli, and submit. They give out free 0.05 ETH, but if you wish to double this to 0.1 ETH, you can simply share the link to a tweet they require you to post. However, my only concern is that at the time of writing this, their user interface seemed a bit disorganized, with the original content of the screen overlapping on the left side, and no feedback was provided when I submitted the request.

Conclusion

This list does not cover all the faucets out there. There are still many I have not come across or used. But I believe the 5 listed out here are enough to get you started with whatever you require the tokens for. In case you wish to learn how to build one for yourself just like I did, I may be writing an article on how to build one. Stay connected and subscribe to my newsletter to know when this happens. And hey, you can get free Sepolia ETH while you're at it!

pragma solidity ^0.7.0;

contract TestContract {
    uint private score;

    function getScore() external view returns(uint){
        return score;
    }
}

The view key in the getScore function above is an example of Modifiers in Solidity.

Modifiers in Solidity are little helper functions that modify a function that it is attached to. Modifiers are called before the main function is called and we may need this behavior in cases like:

• Validating an input.
• Making checks before modifying the contract.
• Running a set of tasks or functions before running the main one.

There are built-in modifiers in Solidity and we can as well create our own custom modifiers.

Built-in Modifiers

The view example above is an example of the built-ins. There exist other examples like pure and payable.

view

This modifier is used to explicitly inform Solidity that you intend to only read the state from the contract. You are not allowed to modify or alter any state variable using a function containing this modifier. Attempting to do this will lead to an error and cancel the code execution.

For example, using the sample code above, we are not allowed to do this:

function getScore() external view returns(uint){
    score += 1; // TypeError: Function declared as view, but this expression (potentially) modifies the state
    return score;
}

pure

This modifier is used to inform Solidity that we have no intention of reading or modifying the contract state. In view, we can read but cannot set/alter state, while in pure we cannot even read the state. For, example:

function getScore() external pure returns(uint){
    return score; // TypeError: Function declared as pure, but this expression (potentially) reads from the environment or state and thus requires "view".
}

You may think, "When do we need this then?". We may need this modifier when we wish to make some internal calculations and checks where we do not need any variables from the existing state. For example,

pragma solidity ^0.7.0;

contract TestContract {
    uint private scoreA;
    uint private scoreB;

    function addScores(uint a, uint b) internal pure returns (uint) {
        return a * b;
    }

    function addAndGetScores() external view returns (uint) {
        return addScores(scoreA, scoreB);
    }
}

Above, addScores accepts arguments and only carries out instructions based on them. They do not read state or change it.

payable

This other modifier is used to inform Solidity that we expect some ether in form of Wei to be passed in along with the function. It is simply called as such:

pragma solidity ^0.7.0;

contract TestContract {
    uint private score;

    function setScore(uint newScore) external payable {
        score = newScore;
    }
}

When we do this without sending in some ether with the transaction, the function execution will fail.

Custom Modifiers

We may also decide to create our own custom modifiers that handle specific tasks before executing our functions. To do this, we simply define the modifier using the modifier keyword and can also use them alongside other modifiers:

pragma solidity ^0.7.0;

contract TestContract {
    uint private score;
    address manager;

    constructor() {
        manager = msg.sender;
    }

    modifier isManager() {
        require(msg.sender == manager);
        _;
    }

    function setScore(uint newScore) external payable isManager {
        score = newScore;
    }
}

Let us break down the contract code above:

• We added a new variable to store our manager, which in this case is the address of the wallet or contract that deploys this TestContract.
• We set this manager in the constructor.
• The next line is where we declare our modifier called isManager which just checks that the caller of the function it is attached to is the manager. This adds some layer of protection on top of our contract by preventing the general public or unintended users to modify the state of our contract.

The modifier function above has a line of code with just an underscore "_". This special symbol informs Solidity that this is the point where we inject the main function block. So it checks that the caller is the manager, and then runs score = newScore;

Also, note that modifiers can also accept arguments like regular functions.

pragma solidity ^0.7.0;

contract TestContract {
    uint private score;
    address manager;

    constructor() {
        manager = msg.sender;
    }

    modifier checkFee(uint fee) {
        require(fee > 100000);
        _;
    }

    function setScore(uint newScore) external payable checkFee(msg.value) {
        score = newScore;
    }
}

In the code above, the new checkFee modifier expects to be called with a value that it checks to be greater than 100000wei. This modifier is now used in setScore and the value of ether sent with the transaction is passed as the parameter.

Today we'd be talking about Nullish Coalescing in JavaScript. The nullish coalescing operator (??) is considered a logical operator - much like the 'OR' (||), 'AND' (&&) and 'NOT' (!) operators - that returns the right side operand if and only if the operand on the left-hand side has a null or undefined value. It is quite similar to the 'OR' operator, but with a significant difference which we will get to soon enough.

To see this in action, let's consider the code below:

// for null values
let x = null;
let y = x ?? "defaultValue";
console.log(y); //returns 'defaultValue'

//for undefined values
let m = undefined;
let n = m ?? "defaultValue";
console.log(n); //returns 'defaultValue'

This also works if the left-hand side operand has been declared but not yet assigned a value as this is also an undefined value, like in the example below.

let f;
let g = f ?? "defaultValue";
console.log(g); //returns 'defaultValue'

As I mentioned, the nullish operator is somewhat similar to the OR operator except for an important difference. The OR operator returns the right-hand side operand for not just null and undefined values but also for falsy values. Consider the code below:

// with nullish operator
let a = false;
let b = a ?? "defaultValue";
console.log(b); //returns false

//with OR operator
let k = false; //also works with 0
let l = a || "defaultValue";
console.log(b); //returns 'defaultValue'

You might be wondering what the use case for this is, let's consider the code block below:

import React from "react";
const profile = {
  numberOfPosts: 0,
  username: "",
};
let displayNumberOfPosts =
  numberOfPosts || "An error occured while fetching data";
export const Example = () => {
  return <p>{displayNumberOfPosts}</p>;
};

The above returns <p>An error occured while fetching data</p> because 0 is a falsy value hence the OR operator returns the right hand side operand, in this case being 'An error occured while fetching data' which is unintended. The desired result could be achieved by using the nullish coalescing operator as thus:

import React from "react";
const profile = {
  numberOfPosts: 0,
  username: "",
};
let displayNumberOfPosts =
  numberOfPosts ?? "An error occured while fetching data";
export const Example = () => {
  return <p>{displayNumberOfPosts}</p>;
};

The above will return <p>0</p> as the operator returns the right-hand side operand only if the left-hand side is a nullish value, and not a falsy one.

The nullish coalescing operator is currently a stage four proposal for ES2020 which is the last stage for the TC39 process and I'm sure we can't wait to start using it soon in the next version of JavaScript.

Thanks for taking the time to read this article. I will be writing even more; stay tuned!

With the relative ease that comes with using Gatsby, and the amazing love that comes from its community ever since I started using it, I decided to find out what other amazing things that come. with it. It then hit me, "could Gatsby be used to build out an online store as a static site?". At first, it seemed most unlikely, as I thought of the highly dynamic functionality that comes with e-commerce stores and could not possibly imagine how Gatsby could generate static pages for them. But then, hey, we live in a time where there is Gatsby and Netlify. Anything can be done on the web these days.

I then started to do a little digging to see what I could come up with. I saw a few articles on it, but they were mostly using not-so-popular technology or providers. I needed something quick and fast. Something that did not require me reading a big ass documentation in order to get things started.

I also came across this article from the Gatsby docs, but I still felt it was a bit limiting as it was an integration with Stripe, which is not totally supported in all countries, at least not Nigeria. I needed a solution that supported many payment providers and methods and I could only think of one. Shopify.

A few digs later I discovered an awesome Gatsby starter for e-commerce stores powered by Gatsby and Shopify. The joy! The starter already hast taken out the stressful parts of it all. No need to reinvent the wheel here and all it needs is a tweak here and there and some redesign to suit your taste. You can check out the starter here on Gatsby or directy get to the source code on Github.

Two issues are likely to arise when creating static online shops. First, dynamic product inventory. Your product availability should change in accordance to your inventory in the Shopify store. You wouldn't want your products to appear as available, because Gatsby has already statically built out the listing page, when in reality you are out of stock. For this issue, the starter I mentioned above has it all sorted out. According to their README,

"The Shopify product inventory is being checked in realtime, therefore no rebuilding and redeploy is needed when a product goes out of stock. This avoids problems where products could still be available even though they're out of stock due to redeploy delay."

Secondly, as the pages would be all pre-built by Gatsby, what happens when we change the details of a product, add a new product or delete an existing product? Would we have to log back to Netlify to trigger a build each time? Nope! For this issue, we also have a workaround for it.

Without much ado, let's begin.

###Shopify setup First, you would need to log into your Shopify account or create one if you do not have already. While logged in, create a new store and give it whatever name you wish. You will need this name, plus a Storefront access token which you will get soon. With the store created, go on to add a few products to the store. Gatsby's graphql would throw an error during build if there are no products in the store.

Next, we have to get a storefront token. For this, navigate to the Apps section of your store and continue to Manage private apps. Create a new private app, with any name under “Private app name” and leave the default permissions as Read access under Admin API. Enable the Shopify Storefront API by checking the box that says “Allow this app to access your storefront data using Storefront API”. Make sure to also grant access to read product and customer tags by checking their corresponding boxes. Then, copy the storefront access token that will be provided to you. This is not a secret and could be put in any publicly available JavaScript file.

###Gatsby setup To start up the project, in the command line, run:

gatsby new gatsby-shopify-starter https://github.com/AlexanderProd/gatsby-shopify-starter

This will take some time to start the project and install dependencies. Once done, open up the project folder in your favourite editor and open the .env.development and the .env.production files and change the default values of SHOP_NAME and SHOPIFY_ACCESS_TOKEN to your own store name and access token, respectively. That is about all you need to do for the setup. You can test this out by running gatsby develop. Please for this, you should be connected to the internet for Gatsby to fetch the product and build the product pages. When all is done, you should have a new ecommerce store running on your localhost. You can go ahead and make relevant changes to the project as suits your designs and use case. All done then deploy to Netlify.

###Handling automatic build With the store deployed to Netlify, we then have to set up an automatic build on Netlify each time we make product changes on the Shopify store. To do this, we need to set up Netlify's build hooks, which is a URL that continuoulsy listens for POST requests and triggers a build automatically when such requests hit the URL. For this, go the the app's Settings > Build & deploy > Build hooks and Add build hook. Put in a hook name and select a branch from git which the build should run with, ideally master. Hit Save. Upon save, a new hook URL endpoint will be displayed. Copy that and head over back to the Shopify store. Move to Settings > Notifications > Webhooks > Create webhook. For the event, choose Product creation, leave format as JSON and paste the URL from the Netlify build hook and hit Save webhook. Do this again two more times for Product deletion and Product update and any other event you feel may be necessary for a rebuild, while using the same URL from Netlify. And that is it, as you add/update/delete products, Netlify rebuilds the site in a few minutes to reflect changes.

For more stuff, like adding payment or delivery options, please do that in the Shopify dashboard. The Gatsby "front-end" just displays the info and preferences from the Shopify dashboard "back-end".

Extra stuff: Seeing you do not need the Shopify online store sales channel (as the Gatsby app serves the purpose), you can safely remove it as a sales channel. This makes you (or your client) avoid the $29 monthly charges on the Basic Shopify plan and instead, subscribe to the $9 monthly Shopify Lite plan.

PS: If you need someone to set up a store for you, you can hire me.

When I started out building my portfolio-cum-blog website with Gatsby and actually started writing, I came across an issue. For someone who also writes on Dev.to - where you can start writing out an article, only to draft it and move onto a new one - I got a bit disappointed why uptil now, Gatsby's blog starter does not include a built-in functionality of saving drafts and only publishing posts you set as "published", as seen on Dev.to.

There are other alternatives to this which I found online. Links to them will be listed at the end of this article. Also this article assumes you're running a blog powered by Gatsby's gatsby-starter-blog

My first thought on how to solve this was looking for the chunk of code that handles creation of pages from Markdown files, and I found this in gatsby-node.js:

exports.createPages = async ({ graphql, actions }) => {
  const { createPage } = actions;

  const blogPost = path.resolve(`./src/templates/blog-post.js`);
  const result = await graphql(
    `
      {
        allMarkdownRemark(
          sort: { fields: [frontmatter___date], order: DESC }
          limit: 1000
        ) {
          edges {
            node {
              fields {
                slug
              }
              frontmatter {
                title
              }
            }
          }
        }
      }
    `
  );

  if (result.errors) {
    throw result.errors;
  }

  // Create blog posts pages.
  const posts = result.data.allMarkdownRemark.edges;

  posts.forEach((post, index) => {
    const previous = index === posts.length - 1 ? null : posts[index + 1].node;
    const next = index === 0 ? null : posts[index - 1].node;

    createPage({
      path: post.node.fields.slug,
      component: blogPost,
      context: {
        slug: post.node.fields.slug,
        previous,
        next,
      },
    });
  });
};

As you can rightly guess, the pages are created from data gotten with the allMarkdownRemark query. This is where we can work our magic.

Right next to the sort command, we can add our own filter rule to get only posts we mark as published. To do this, you should add a variable published in your articles' frontmatter, which is set to true or false depending on the status of the article. For example, to set an article as a draft (i.e unpublshed) add this to the file's front matter: published: false.

Now that we have a way of marking posts as ready to be published or not, we get back to the GraphQL query and change it like so:

exports.createPages = async ({ graphql, actions }) => {
  const { createPage } = actions

  const blogPost = path.resolve(`./src/templates/blog-post.js`)
  const result = await graphql(
    `
      {
        allMarkdownRemark(sort: {fields: frontmatter___date, order: DESC}, filter: {frontmatter: { published: {eq: true} }}, limit: 1000)
        ...

        slug: post.node.fields.slug,
        previous,
        next,
      },
    })
  })
}

This change ensures that Gatsby only filters out posts we set it's published variable to true in it's fromtmatter. Please note to add this rule to wherever else you are doing some tasks with your posts, eg when in your src/pages/index.js file, where there's a similar query for listing out your articles, and also if you're creating your RSS feed with gatsby-plugin-feed.

As I stated before I started, there are other alternatives around the web for this. Check out this method by Janosh and this one by Chase Adams. Use whichever method you prefer, and if you have your own super cool method for this, please share with us some code snippets in the comment sections or paste the link to the article.

Now, while this won't be a tutorial to set up Gatsby with Markdown, I'll be showing you some awesome plugins I have come across so far, and I use them in my Gatsby blog site. Some of these plugins help in UI, UX, SEO, others help in integration with useful services, which otherwise would have been pretty difficult (or maybe not) to set up.

These plugins are not entirely top per se - there are more important plugins that comes with a Gatsby starter, but these are my favorite extras to add.

In no particular order, let's get started:

gatsby-plugin-mailchimp

What is a blog without subscribers, right? This plugin makes it ridiculously easy to link up your Mailchimp account with your Gatsby blog to enable you to subscribe email addresses to your Mailchimp list. To set it up is as easy as running yarn add gatsby-plugin-mailchimp to install the package and adding to below snippet to your gatsby-config.js file:

{
  resolve: "gatsby-plugin-mailchimp",
  options: {
    endpoint: // add your MC list endpoint here; see instructions below
  },
},

For more information, visit the page here.

###gatsby-plugin-nprogress Gatsby JS sites are blazing fast, that is the idea of static site generators. They load pages on click in less than a second. But if you have built, or visited a site built with Gatsby, you will agree with me this is not always the case.Sometimes, and for some reason, they delay a bit in loading pages. Most times there is no indicator to show the user that the page is loading, which they might perceive as an error and might end up continuously clicking on links, or might just leave entirely. This is where gatsby-plugin-nprogress comes in.

According to the gatsby plugin library, it "automatically shows the nprogress indicator when a page is delayed in loading (which Gatsby considers as one second after clicking on a link)."

To set up, yarn add gatsby-plugin-nprogress and add the line below to gatsby-config.js file:

// In your gatsby-config.js
plugins: [
  {
    resolve: `gatsby-plugin-nprogress`,
    options: {
      // Setting a color is optional.
      color: `tomato`,
      // Disable the loading spinner.
      showSpinner: false,
    },
  },
];

###gatsby-remark-prismjs This plugin adds syntax highlighting to code blocks in your markdown files using PrismJS. This makes your code snippets, samples, and blocks aesthetically pleasing.

To use, yarn add gatsby-transformer-remark gatsby-remark-prismjs prismjs. This installs all the required modules, including the official PrismJS library. For customization options and how to use, visit [their page](gatsby-transformer-remark gatsby-remark-prismjs prismjs).

###gatsby-plugin-disqus This helps you link your Disqus account to your blog. It enables you to activate comments and reactions to your blog pages. Thus, it allows interaction between you and your audience. From here, you can get feedback and see what your readers think and feel about your works and writing. For usage and instructions, visit here.

###gatsby-plugin-robots-txt This is a gatsby plugin that automatically creates robots.txt for your site. According to Neil Patel, "The robots.txt file, also known as the robots exclusion protocol or standard, is a text file that tells web robots (most often search engines) which pages on your site to crawl." Having a robots.txt file is good for SEO as it tells the search engine (e.g Googlebots) instructions on how to crawl your site. To add this to your site, run yarn add gatsby-plugin-robots-txt and for the simplest implementation, add the code below to your project's gatsby-config.js:

plugins: ["gatsby-plugin-robots-txt"];

For additional configurations, visit the plugin page

###gatsby-plugin-manifest Gatsby plugin which adds a manifest.webmanifest to make sites progressive web apps. This plugin comes with features that turn your app to a progressive web app - automatic icon generation, favicon support and caching, all taken care of. It is recommended to use this plugin together with gatsby-plugin-offline for best results. To use, run yarn add gatsby-plugin-offline gatsby-plugin-manifest. Open your config file and paste below:

plugins: [
    {
      resolve: `gatsby-plugin-manifest`,
      options: {
        name: `GatsbyJS`,
        short_name: `GatsbyJS`,
        start_url: `/`,
        background_color: `#f7f0eb`,
        theme_color: `#a2466c`,
        display: `standalone`,
      },
    },
    'gatsby-plugin-offline'
  ],

Make sure to replace necessary lines with your own details.

###gatsby-plugin-google-analytics

This is used to add google analytics to your blog. This helps you get useful information about your visitors like demographics, device information, pages and stuff like that. It helps in knowing which pages are most visited, which country represents most of your visitors, which devices s are most used by your visitors and so, helps you to make better content targeted at your particular choice of audience. To use, run yarn add gatsby-plugin-google-analytics and then add the code below to your plugins:

{
  resolve: `gatsby-plugin-google-analytics`,
    options: {
       trackingId: `YOUR-TRACKING-ID`,
},

For more options and configurations, visit the plugin page

###gatsby-plugin-sitemap This plugin generates a sitemap for your site. Sitemaps are highly recommended for SEO purposes. And it will do you a lot of good to add a plugin for it. To get started, install the plugin by running yarn add gatsby-plugin-sitemap and then add the following line of code to your Gatsby config:

plugins: [`gatsby-plugin-sitemap`];

The line above is the minimum configuration needed and the generates sitemap will include all of your site's pages by default. If for some reason, you don't want this behavior and need to exclude some pages, visit this page for additional configurations.

NOTE: This plugin only generates output when running in production mode! To test your sitemap, run: gatsby build && gatsby serve

The plugins above are just a very itsy-bitsy of the over 1000 supported plugins in the Gatsby library, but they're just the few I have worked with and loved. Some of these plugins come bundled in some starters and you may not need to install them yourselves.

I'll be very glad to get feedback on some of these plugins and to know which extra plugins you love. Please tell us in the comment section.

While the first option is quite great, I feel it is a bit too much of an overkill to use, especially if what you need from Bootstrap is just the juicy CSS. non-jQuery part and functionality like the grid system or typography. If so, we will go with the second option. This sounds easy, till you discover that Gatsby apps created with the starters have no index.html file like in normal React apps made with create-react-app, or any other front end project.

Now where do we include our CDN links? There is no html file, hence no head tag. This is where the purpose of this article comes into play.

Again, we have two options - hey! Life's full of options.Gatsby projects come with a seo.js file which can be found in src/components. This component uses React Helmet to function. This makes it easy for us to just make changes to the html file that will be produced when gatsby bundles our app. We can include the CDN link by so doing:

<Helmet>
  <link
    rel="stylesheet"
    href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/css/bootstrap.min.css"
    integrity="sha384-Gn5384xqQ1aoWXA+058RXPxPg6fy4IWvTNh0E263XmFcJlSAwiGgFAW/dAiS6JXm"
    crossorigin="anonymous"
  />
</Helmet>

This is relatively easy to do and should work well. I used this before, till I noticed that sometimes and for some reason, it did not work - it worked most of the time - and required the user to refresh the page for it to hopefully work. You can't expect users to do that!

This leads us to the second workaround.

A look into the project structure created for us when we bootstrap an app with a Gatsby starter should show a file in root folder called gatsby-browser.js. According to the Gatsby website, "This file is where Gatsby expects to find any usage of the Gatsby browser APIs (if any). These allow customization/extension of default Gatsby settings affecting the browser." What this means (to me), is that we can call APIs and import stuff that affects the browser, like our styles and custom JavaScript scripts. This sounds like a good enough point to introduce our CDN,

To do this, we have to let go of our CDN. Sorry that the article of this blog might be misleading as we will have to drop our CDN link here. All for the best. We have to install Bootstrap into our project. For this, run:

npm install bootstrap

or

yarn add bootstrap

This installs the official Bootstrap folders in our app. Next, open up the gatsby-browser.js file and import the CSS files from Bootstrap at the top of the file like so

//bootstrap
import "bootstrap/dist/css/bootstrap.css";

And that's it! Feel free to use Bootstrap styles as you wish. No hassles!

Thanks for following along and would love to have a feedback of how this helped you, or if you have your own way of linking them both up.

Ever since I learnt and started styling pages with CSS, I have always felt confused regarding which unit to use for styling my paragraphs, headings, paddings and margins. This is common among (frontend) developers, as there are quite a lot of options out there to use - more options than I knew of till I started writing this! I kept deferring learning the differences between these units, as I thought they did not really matter until Kayla created a small quiz on Twitter. And I failed it.

It was at this point that I decided to try and understand what they all are, and document it as well.

###So what are they? The units are categorized into Absolute and Relative lengths. Let's take them one after the other.

###Absolute Lengths These are length units that are fixed and appear as exactly that size. Absolute units are mostly discouraged to be used on screens, as 12px on a large screen might not look the same on an iPhone. They depend highly on the output medium, and hence should be ideally be used when the output medium is known, or a particular screen size is targeted.

"There is another reason to avoid absolute units for other uses other than print: You look at different screens from different distances. 1cm on a desktop screen looks small. But the same on a mobile phone directly in front of your eyes looks big. It's better to use relative units, such as em, instead."

-- w3.org

The absolute units are: px, in, cm, pt, pc, and mm. There might be others, but we will treat these ones for brevity sake.

• px: This defines a size in screen pixels. It equals one dot on the computer screen. A pixel is equal to 1/96th of an inch. W3 describes px as the magic unit of CSS.
• in: This means inches. 1in equals 96px.
• cm: Centimeters. Equals 37.8px.
• mm: Milimeters. 1mm is same as 3.778px.
• pc, pt: Defines measurements in picas and points, respectively. 1pt equals 1/72 of an inch, while 1pc equals 12pt.

###Relative Lengths These units define sizes and length relative to another length property. They are mostly preferred as they scale better across different mediums. They include em, rem, %, ex, ch, amongst others.

• em: Simply put, an em is the same as the current font size. As a default, modern browsers display fonts at 16px (12in), thus, a text styled at 1em is same as 16px For example, look at the style below:

p {
  font-size: 2em;
}

This sets the font size to 32px, i.e 2 * 16px. em is scalable and are mobile-device-friendly.

• rem: Stands for 'root em'. This is the font size relative to the root element, which is the html tag. Consider the style below:

html {
  font-size: 62.5%;
}
body {
  font-size: 100%;
}
p {
  font-size: 1rem;
}

The size of the p tag comes out as 62.5% (of 16px, which is 10px) and not 100% (16px) as it is relative to the html font size and not that of the body tag. The rem unit is not widely used, and so you might not need to use it.

• %: Defines a size relative to the parent element.
• ex and ch: ex defines measurement relative to the font's x-height, which is the size of the font's lowercase 'x' while ch is relative to the font's width of the character '0' (zero).

Conclusion

Really, the choice of what unit to use is left for you to choose, but most people use (and recommend) em and px.

"I tend to use px for borders, and rems for most everything else -- because it makes it easy to keep things consistent and make layout tweaks without a lot of effort."

-- Brian Vaughn

JavaScript Joe and JavaScript Joel both seem to be fans of px.

"When it comes to font sizes, I traditionally use something like TypographyJS because it basically sets up a system for me. However, I try to stick to measurements in multiples of 4px (e.g 4px, 8px, 12px, 16px etc) when I use px. This way things feel "uniform".

-- JavaScriptJoe

"I typically only use px. That could be my bias as when I started, px was the only thing absolutely available. Now I leave it up to the designers to tell me what the style is."

-- JavaScriptJoel

This is what a Twitter user, Florin, has to say:

"I use px mostly. Not very good with others."

-- Florin Pop

Now, whatever method you choose to use, it is recommended to use at least 16px (1em) for body text and em as the go-to unit. This ensures the font size is relative to the default font size, which is the size the reader can comfortably read. It also ensures the size scales well on different screen sizes and density. Although we can choose to ignore this, as modern browsers and devices provide tools to increase font size and display, it would not hurt to design with a11y in mind.

As was rightly pointed out by Brent Clark, using em also comes with it's own issues: it is relative to the size of the parent, which in turn depends on other parent(s). For example, consider the code below:

<!-- HTML -->
<body>
    <p class='outer-p'>
        Outer paragraph
        <p class='nested-p'> Nested paragraph</p>
    </p>
</body>

<!-- CSS -->
<style>
    body{font-size: 16px}
    .outer-p{font-size: 2em}
    .nested-p{font-size: 1.5em}
</style>

From the above code, we need the outer-p paragraph to be 2em, and rightly it will be 32px, as it will be x2 of the immediate parent, the body, which was already set to 16px. Now, if wanted to set our nested-p paragraph to 1.5em and expect it to come out as 24px (i.e 1.5 _ 16px), we'll be disappointed as the size comes out as 48px. This behaviour is because em is relative to whatever size the parent has. In this case, nested-p is a child of outer-p, which already has a size of 32px. This explains why it comes out as 48px, I.e 1.5 _ 32px. This behavior of em should be put into consideration when using it.

In order to avoid unwanted outcomes that might be associated with em, I believe that was why the rem was introduced. With this, just set the default style on the html directly and then use rem as your CSS unit, this way you're sure they all refer to the html tag style size and not on their parent's sizes.

For example, using the same code above, to get the desired sizes for outer-p and nested-p, which are 32px and 24px respectively, we'll refactor to this:

<!-- HTML -->
<body>
    <p class='outer-p'>
        Outer paragraph
        <p class='nested-p'> Nested paragraph</p>
    </p>
</body>

<!-- CSS -->
<style>
    html{font-size: 16px}
    .outer-p{font-size: 2rem}
    .nested-p{font-size: 1.5rem}
</style>

By doing so, the font sizes are now all relative to the root style, in this case html.

As for me, I will try to stick to this little snippet I found:

body {
  font-size: 62.5%; /* sets default font size to 10px i.e 62.5% of 16px */
}
p {
  font-size: 1.4em; /* 14px */
}

As I earlier mentioned, use whatever makes you comfortable. And do not sweat it if you don't really get the hang of it, I still don't get most of it.

If 1.4em results to 14px, why not then just use 14px instead?

Yes, it is an object. You can verify this by opening up your browser console and running typeof(console) and you should get “object” returned back.

Now that we have proven it is an object, like all other objects, it has many other methods in it apart from log().

“Why is it so important knowing these other methods?”, you may ask. Well, although you might just go on using the log method to debug your code, learning about and using other methods helps in better representation and easier debugging. And hey!, why not learn more to help us combat our common enemy — bugs. Besides, you dunno what your next job interviewer has under their sleeves.

Let’s get started, shall we?

Hopefully, your browser console is still up and running, if not open it up again, and never close it till we are done with this, as we will get back to them occasionally. To view other methods on the console, try running console.log(console) — the irony! The data below should be returned to us:

console {debug: ƒ, error: ƒ, info: ƒ, log: ƒ, warn: ƒ, …}
assert: ƒ assert()
clear: ƒ clear()
context: ƒ context()
count: ƒ count()
countReset: ƒ countReset()
debug: ƒ debug()
dir: ƒ dir()
dirxml: ƒ dirxml()
error: ƒ error()
group: ƒ group()
groupCollapsed: ƒ groupCollapsed()
groupEnd: ƒ groupEnd()
info: ƒ info()
log: ƒ log()
memory: (...)
profile: ƒ profile()
profileEnd: ƒ profileEnd()
table: ƒ table()
time: ƒ time()
timeEnd: ƒ timeEnd()
timeLog: ƒ timeLog()
timeStamp: ƒ timeStamp()
trace: ƒ trace()
warn: ƒ warn()
Symbol(Symbol.toStringTag): "Object"
get memory: ƒ ()
set memory: ƒ ()
__proto__: Object

This gives us so much more methods than we (rather, I) ever knew existed on the console. And like every other numerous lists, we will pick our most important ones.

###console.assert() The simplest case of using the assert() method, is when we want to display something on the console only and only if the assertion passed into the method is false. If by any means the assertion passes, nothing happens, or you get an undefined if you are using a browser console. To see this in action, pull up your console if not open (PUYCINO — this is not a real thing) and run the following code:

var x = 21;
console.assert(x % 2 === 0, "oops! x is not divisible by 2");
// or alternatively

var errMsg = "oops! x is not divisible by 2";
console.assert(x % 2 === 0, errMsg);

You should get an assertion error with the error message printed to the console. Try changing x to 20 or any other even number and run the assert code again, this time nothing happens.

###console.clear()

This method is simple enough. Running console.clear() just clears the console and displays Console was cleared message (as if we cannot see it has been cleared). Run this code whenever you feel your console is all clogged up and you need room.

###console.dir() and console.dirxml()

This method helps us to print out to the console all the properties (methods) of any valid JavaScript object passed into it. Remember when we said — and proved — that console was an object. Now lets use it as an argument in the console.dir() method. PUYCINO and run the code console.dir(console) and a familiar output will be displayed. You can also try console.dir(window) to view the properties on the native Window object. And this will come in handy someday, you’ll see!

dirxml is almost similar to dir with very small and insignificant differences.

###console.error()

This displays content as an error — red highlight, light red background and a red error (x) sign by the side. All features to let you know that what is being displayed is an error. Try running console.error('This is a typical error') and see what I mean.

The use case for this is when you are expecting an error in your code. Example, during a .catch block of an API call that returns a Promise.

###console.group(), console.groupCollapsed() and console.groupEnd()

These methods are used to group together blocks of code or similar whatever it is you’re trying to display to the console. group() signifies the start of the group. It accepts an optional label as an argument. The label serves as, well, the label for the group. groupEnd() marks the end of a group. groupCollapsed() works like group() but while all items in group() is automatically all listed out, groupCollapsed() displays them in a collapsed manner, you will have to manually click on a “dropdown” list beside it to list them all out. Let us see this in action. PUYCINO and paste the following:

console.group("My fav tech tools");
// Here, 'my fav tech tools' is the label for my group
console.log("React");
console.log("Twitter Bootstrap");
console.log("Django");
console.log("Django REST");
console.log("Axios");
console.groupEnd(); //ends the group

Groups can also be nested into another group. Let’s see how this and groupCollapsed() works:

console.groupCollapsed("My fav languages and tools");
console.group("JavaScript"); //nests in JavaScript group
console.log("React");
console.log("Redux");
console.log("Twitter Bootstrap");
console.groupEnd(); //exits nested group for JavaScript
console.groupCollapsed("Python"); //nests in a collapsed Python group
console.log("Django");
console.log("Django REST");
console.groupEnd(); //exits nested group for Python
console.groupEnd(); //exits all groups

As you can see, at first the displayed groups are collapsed and you will have to expand them manually. Next, you can see we nested in two more groups: JavaScript and Python.

Always remember to exit each nested group with groupEnd() as pointed out above.

###console.log()

I think we all are familiar with this. So no need to waste time. It basically just prints out something to the console without any level of warning or danger.

###console.table() This displays data in a tabular format. It takes in a compulsory data which must be an array or object — passing in a string does not work — and an optional columns as parameter. Let us see this in action. Again, PUYCINO (hey, by now there is no more need to include this). Paste in the following:

var nations = ["Nigeria", "USA", "Canada", "Algeria"];
console.table(nations);

This should print the data out in a tabular form with (index) and value columns. Using arrays, the (index) column is auto filled with the index of the instance. To specify what should be used as the table’s index, pass in objects instead. Here, the (index) column will be filled by the keys of the object while the value will be filled by the values of the object. Try below:

var nationsCurrency = { USA: "dollars", Nigeria: "naira", France: "franc" };
console.table(nationsCurrency);

###console.time() and console.timeEnd()

time() starts a timer you can use to track how long an operation takes. It takes in an optional label as argument. Calling timeEnd() with the same label ends the timer and ouputs the time (in miliseconds) that has elapsed since time() was called and code between time() and timeEnd() has executed.

console.time("test");
let mult = 2000 * 4444;
mult * 222;
console.timeEnd("test");

Best use case for this is to compare which two similar functions or logic is faster. Example, the code below compares the speed of execution of for and while loops.

console.time("test for loop");
for (i = 0; i < 100000; i++) {
  console.log(i);
}
console.timeEnd("test for loop");

console.time("test while loop");
while (i < 1000000) {
  i++;
}
console.timeEnd("test while loop");

From running the above code, we can effectively see that the for loop is faster than the while.

###console.warn()

Outputs a warning message to the browser console. It displays the data in a light yellow background with a warning icon by the side. Try it:

console.warn(
  "GOT is hugely graphical and full of violent. Watch at your own discretion."
);

We are done with the important methods. Hopefully by now you will have less console.log() lines during debugging sessions.

Or maybe not, either way thanks for getting this far.

Valar Morghulis!

DISCLAIMERS:

This tutorial assumes you have basic knowledge of Django and React JS. This is not a tutorial for them.

The processes here uses django and django rest framework for its backend configurations. But the React logic works for any backend framework - just do a little bit more googling regarding your framework.

###Tools and Frameworks

• React: We will be using React to build the UI components for our form. I presume by now you understand the conecpt of React and what it is.

• Axios: We shall use axios to make the post requests. Axios is a Promise based HTTP client for the browser and node.js. It is used to make XMLHttpRequests to a server.

• Django: Django is a web framework for the Python programming language.

• Django Rest Framework: DRF is a framework (a Django app — actually) that enables us build simple but yet highly customizable RESTful APIs.

• Django-CORS-Headers: django-cors-headers is a Django application for handling the server headers required for Cross-Origin Resource Sharing (CORS).

• Pillow: This is a Python Image Library you need to have installed when your models have an image field, else you will get an error when running migrations and migrating.

###Project Setup: Please note the command lines I will be using here is for Windows

The project will be divided into two directories — frontend and backend. So cd into your preferred directory and create the root project folder:

#cmd

mkdir react-form-data && cd react-form-data

Now, we will create two folders frontend and backend which will contain the codes respectively. The front end will be created by create-react-app — which I assume you are comfortable with — while the backend will be with django-admin.

Now while in the react-form-data directory, run the following commands:

#cmd

mkdir backend && cd backend
django-admin startproject backend .
cd .. && npx create-react-app frontend

The code above creates a backend directory and we move into it to create our django app also called backend. Remember to add the . so as not to create another folder there.

###Getting Started: We will start with the backend.As with most Python projects, we need to set up a virtual environment, using virtualenv. cd into the root react-form-data project folder with CLI and type in virtualenv env and start up the virtual environment with env\Scripts\activate. On running la in your root project folder you should see:

backend env frontend

Now, making sure the virtual environment is running, run the following in CLI to install the required packages:

cd backend
pip install django djangorestframework django-cors-headers Pillow

This installs the required packages. Now open the settings.py file in your favorite IDE and update the INSTALLED_APPS to include the installed apps:

INSTALLED_APPS = [
    ...,
    'rest_framework',  # for rest api
    'corsheaders',  # for cors policies
]

Now we create our own ‘post’ app to handle the API logic and views. cd into the root backend directory and run python manage.py startapp post. Remember to include this in INSTALLED_APPS.

Next, add these two lines

'corsheaders.middleware.CorsMiddleware'

and

'django.middleware.common.CommonMiddleware'

above other lines in the MIDDLEWARE section, making sure

corsheaders.middleware.CorsMiddleware

above all others. Your middlewares should look like these:

MIDDLEWARE = [
    'corsheaders.middleware.CorsMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

Right below the MIDDLEWARE section, add this line: CORS_ORIGIN_ALLOW_ALL = True. This enables all API requests from a different server to be allowed. Also, since we are dealing with uploaded images, add the following to the bottom of your settings.py file:

MEDIA_ROOT = os.path.join(BASE_DIR, 'media')
MEDIA_URL = '/media/'

Overall, your settings.py file should look like this:

Django settings for backend project.
Generated by 'django-admin startproject' using Django 2.1.7.
For more information on this file, see
https://docs.djangoproject.com/en/2.1/topics/settings/
For the full list of settings and their values, see
https://docs.djangoproject.com/en/2.1/ref/settings/
"""

import os

# Build paths inside the project like this: os.path.join(BASE_DIR, ...)
BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

# Quick-start development settings - unsuitable for production
# See https://docs.djangoproject.com/en/2.1/howto/deployment/checklist/

# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = '9zff9-n4#2g--_$4@g4uu-zauef(s^i3^z_!7wtpzduma59ku8'

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True

ALLOWED_HOSTS = []

# Application definition

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'post',
    'rest_framework',  # for django rest api
    'corsheaders',  # for rest api
]

MIDDLEWARE = [
    'corsheaders.middleware.CorsMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

CORS_ORIGIN_ALLOW_ALL = True

ROOT_URLCONF = 'backend.urls'

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]

WSGI_APPLICATION = 'backend.wsgi.application'

# Database
# https://docs.djangoproject.com/en/2.1/ref/settings/#databases

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    }
}

# Password validation
# https://docs.djangoproject.com/en/2.1/ref/settings/#auth-password-validators

AUTH_PASSWORD_VALIDATORS = [
    {
        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
    },
]

# Internationalization
# https://docs.djangoproject.com/en/2.1/topics/i18n/

LANGUAGE_CODE = 'en-us'

TIME_ZONE = 'UTC'

USE_I18N = True

USE_L10N = True

USE_TZ = True

# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/2.1/howto/static-files/

STATIC_URL = '/static/'

MEDIA_ROOT = os.path.join(BASE_DIR, 'media')
MEDIA_URL = '/media/'

Now let us create our models for the posts. Open up post/models.py and paste in the following code:

from django.db import models

# Create your models here.

class Post(models.Model):
    title = models.CharField(max_length=100)
    content = models.TextField()
    image = models.ImageField(upload_to='post_images')

    def __str__(self):
        return self.title

Create a new media directory at the same level as manage.py to store our uploaded images. Now, to register our model. Open up post/admin.py and paste the followng code:

from django.contrib import admin
from .models import Post

# Register your models here.

admin.site.register(Post)

Now, you must be wondering, when do we run migrations? Now! With the command line, cd into the root project folder and run: python manage.py makemigrations and then python manage.py migrate. Now, to the juicy part — serializers! Serializers is a way to convert Python data to API JSON format and vice-versa. Create a new serializers.py file in the post directory an paste the code:

from rest_framework import serializers
from .models import Post

class PostSerializer(serializers.ModelSerializer):
    class Meta:
        model = Post
        fields = '__all__'

We just created a new class that extends the ModelSerializer of DRF. model in class Meta just specifies the model to use, while fields can be a tuple or list holding the individual fields in the model, or takes in __all__ to just serialize all fields. Now, open up the post/views.py file and paste the following:

from .serializers import PostSerializer
from .models import Post
from rest_framework.views import APIView
from rest_framework.parsers import MultiPartParser, FormParser
from rest_framework.response import Response
from rest_framework import status
# Create your views here.

class PostView(APIView):
    parser_classes = (MultiPartParser, FormParser)

    def get(self, request, *args, **kwargs):
        posts = Post.objects.all()
        serializer = PostSerializer(posts, many=True)
        return Response(serializer.data)

    def post(self, request, *args, **kwargs):
        posts_serializer = PostSerializer(data=request.data)
        if posts_serializer.is_valid():
            posts_serializer.save()
            return Response(posts_serializer.data, status=status.HTTP_201_CREATED)
        else:
            print('error', posts_serializer.errors)
            return Response(posts_serializer.errors, status=status.HTTP_400_BAD_REQUEST)

I believe you understand the imports . The parser_class is used because we are dealing with request data that comes in as FormData. Two class methods get and post are defined to handle the respective requests. Now, to the urls. Create a new urls.py file in the post directory. Open it and add the following code:

from django.urls import path
from . import views

urlpatterns = [
    path('posts/', views.PostView.as_view(), name= 'posts_list'),
]

Now, to add this new url to our project urls, open up backend/urls.py and change the code to this:

from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('api/', include('post.urls')),
]

Now, let us create a super user and test what we have been doing all along. With command line, cd into the root backend directory and run python manage.py createsuperuser and follow the prompts to create one. Now fire up the server by running python manage.py runserver and go to localhost:8000/api/posts. You will be greeted with the following page, if everything works out well:

Now, no posts can be seen cos we have not added any. Navigate to localhost:8000/admin to add a few posts. Done? Navigate back to https://localhost:8000/api/posts. You should get this — but with the data you put in.

Now, our backend works correctly. Now to React.

Remember we had already created a React frontend directory with create-react-app. Now, using the command line, cd into the frontend directory and run npm install axios. This installs axios for making the HTTP requests. Now run npm run start. We should be greeted with the popular React welcome page. Now open the frontend directory in your editor and let us start by clearing a few things — delete the App.css , logo.svg and App.test.js files as we would not be needing them. Don’t forget to remove lines where they are referenced in App.js. As this is a little project, our code will live in App.js Modify your App.js file to look like:

import React, { Component } from "react";
import axios from "axios";

class App extends Component {
  state = {
    title: "",
    content: "",
    image: null,
  };

  handleChange = (e) => {
    this.setState({
      [e.target.id]: e.target.value,
    });
  };

  handleImageChange = (e) => {
    this.setState({
      image: e.target.files[0],
    });
  };

  handleSubmit = (e) => {
    e.preventDefault();
    console.log(this.state);
    let form_data = new FormData();
    form_data.append("image", this.state.image, this.state.image.name);
    form_data.append("title", this.state.title);
    form_data.append("content", this.state.content);
    let url = "http://localhost:8000/api/posts/";
    axios
      .post(url, form_data, {
        headers: {
          "content-type": "multipart/form-data",
        },
      })
      .then((res) => {
        console.log(res.data);
      })
      .catch((err) => console.log(err));
  };

  render() {
    return (
      <div className="App">
        <form onSubmit={this.handleSubmit}>
          <p>
            <input
              type="text"
              placeholder="Title"
              id="title"
              value={this.state.title}
              onChange={this.handleChange}
              required
            />
          </p>
          <p>
            <input
              type="text"
              placeholder="Content"
              id="content"
              value={this.state.content}
              onChange={this.handleChange}
              required
            />
          </p>
          <p>
            <input
              type="file"
              id="image"
              accept="image/png, image/jpeg"
              onChange={this.handleImageChange}
              required
            />
          </p>
          <input type="submit" />
        </form>
      </div>
    );
  }
}

export default App;

I am going to try and explai what is going on here, as this is the main focus of this article.

• In line 1 and line 2 , we imported React (and Component) and axios respectively.
• In line 6 we set our initial state, which is just the respective fields in our post model. We use this to pass the FormData to the backend.
• line 12 is where we handle form value changes to set our state to the value of the new input value. This method of using states in our forms in React is called Controlled Forms.
• line 18 is an important one. We also set the state, but now the image property of our state is set to the the first file data of the event target, since the target is an array of files.
• Another important part is the handleSubmit method in line 24. First, the default character of forms — which is reloading the web page — is prevented. Then a new instance of the in-built JavaScript’s FormData is instantiated by calling new FormData() in line 27 . One method of the FormData is append which takes in two required parameters — a key:value pair — with the first parameter being the key while the second is the value. The key should correspond to the field in your django models — this is important to avoid errors! The append method is called on the FormData passing in three different times to add the form values, now saved in the state. The FormData is now one large parcel of data that is now passed as the body of our axios POST call to our Django REST API.
• Please make note of the content-type in the axios headers. It should be set to multipart/form-data.

Now, go back to the web page and try to fill in the forms and add an image. Submit. You will get a JSON response logged in your console with the request data, and an ID — which shows it has been successfully uploaded to the backend and a new object created. To verify this, go to localhost:8000/api/posts (with your django local server running, of course) and you will see the newly added post.

Thanks for following along and I hope you got it right.