Ask ten different creators that question and you'll get ten wildly different answers. A developer who live-codes on Twitch is nothing like a lifestyle creator on Instagram. A B2B thought leader on LinkedIn has completely different needs than a YouTube educator breaking down finance for Gen Z.

That's exactly the problem I ran into building my AI operator for content creators. I needed a way to actually understand each user before we could help them. A basic onboarding form wasn't going to cut it.

So I built an AI agent that holds a real conversation with users, asks the right follow-up questions, and produces a detailed niche profile — all during onboarding. Here's how it works, and more importantly, why I built it this way.

The Problem With Standard Onboarding

Most onboarding flows ask you to fill out a form. Pick your niche from a dropdown. Choose your goals. Click next.

The problem? Content creation doesn't fit in a dropdown.

The difference between "tech content" and "beginner-friendly Python tutorials for career switchers" is enormous. One is useless to an AI system trying to help you. The other tells you everything.

I needed onboarding to be a conversation — not a form. And I needed that conversation to be persistent, resumable, and capable of reasoning across multiple turns.

That's when I turned to LangGraph.

What Even Is LangGraph?

At a high level, LangGraph is a library for building stateful, multi-step AI workflows as a graph.

Think of it like a state machine for AI agents. You define nodes (things the agent can do) and edges (the rules for moving between them). What makes it powerful is that it handles state persistence natively — meaning your agent can pause, wait for external input (like a user answering a question), and pick back up exactly where it left off.

Here's the mental model: LangGraph is like a choose-your-own-adventure book where the AI decides which page to turn to — and can bookmark its place.

How I Structured the Agent

The agent has two nodes:

analyze — This is where the heavy lifting happens. It builds a prompt from the user's initial niche description (and any follow-up answers they've provided), calls the LLM with structured output via Zod schemas, and returns one of two things:

1. A set of follow-up questions (when it needs more info)

2. A completed finalNicheDescription (when it has enough to work with)

awaitUser — This calls LangGraph's interrupt() function, which pauses execution and saves all of the agent state to Postgres, indicating that we have gotten to a "checkpoint". The agent literally stops running and waits. When the user submits their answers, the frontend resumes the graph by sending back the answers with a Command({ resume: answers }).

The routing logic is simple: after analyze, if the agent is done (or has looped 3 times), go to END. Otherwise, go to awaitUser and loop back to analyze once answers come in.

// Simplified edge logic
const shouldContinue = (state: NicheAgentState) => {
  if (state.isComplete || state.iterationCount >= 3) return "END";
  return "awaitUser";
};

That 3-iteration cap is important. More on that in a second.

The Part Most Tutorials Skip: Checkpointing Across HTTP Requests

Here's where things get interesting.

Each time the user submits answers, they're making a new HTTP request. The agent has no memory between requests — unless you explicitly persist it somewhere. This is where LangGraph's Postgres checkpointer comes in.

Every time the graph hits an interrupt(), it saves the entire agent state to Postgres. When the next request comes in with the same threadId, the graph loads that checkpoint and resumes as if nothing happened.

// Route handler: start vs resume
if (action === "start") {
  input = { initialNiche: niche };
} else {
  input = new Command({ resume: answers });
}

await graph.stream(input, {
  configurable: { thread_id: threadId }
});

The threadId is what ties everything together. It gets sent to the client on the first questions SSE event, and the client sends it back with every subsequent request. Lose the threadId, and the graph can't find its checkpoint — the conversation is gone.

This is also why the agent survives server restarts. The state lives in Postgres, not in memory.

Where People Go Wrong: Over-Questioning

Here's a mistake I almost made.

My first instinct was to let the agent ask as many questions as it needed until it was fully confident. Makes sense in theory. In practice, it's a disaster.

Users don't want to answer six rounds of questions during onboarding. They'll drop off. They'll give lazy answers. They'll start saying "I don't know" just to get through it.

The 3-iteration cap forces the agent to be decisive. By the third loop, it has to commit to a finalNicheDescription regardless of how confident it feels. This actually made the output better, not worse — it stopped the agent from nitpicking and made it prioritise the signal it already had.

Constraints make AI systems more useful, not less.

The Structured Output Problem

One thing I got wrong early on: trusting the LLM to return consistent JSON.

Even with a well-crafted prompt, raw LLM output is unpredictable. The agent might return valid JSON one call and a slightly different shape the next. That breaks your downstream code.

The fix was using withStructuredOutput(analysisSchema) — where analysisSchema is a Zod schema that the LLM must conform to. If it doesn't, the call fails and you get a proper error instead of silently broken data.

const model = getModel(AI_MODELS.GROK_REASONING)
  .withStructuredOutput(analysisSchema);

The output schema captures everything the agent might return: reasoningSteps, isComplete, questions[], and finalDescription (which itself has a detailed shape: niche, subNiche, contentPillars, targetAudience, tone, and whether the creator covers current affairs).

That last field — doesCurrentAffairs — sounds minor but it genuinely changes how the AI operator writes content. Small structured fields like that pay off downstream.

Streaming the Reasoning to the UI

Users get nervous when nothing happens. A spinner for 10 seconds feels broken.

Since the agent does real multi-step reasoning before deciding what to ask, I wanted to stream those reasoning steps to the UI in real-time via Server-Sent Events (SSE). Each step shows up as the agent "thinks through" the creator's niche.

The route handler inspects each LangGraph update as it streams and emits typed SSE events:

• reasoning_step — intermediate thinking, shown progressively

• questions — the follow-up questions for the user (includes threadId)

• final_result — the completed niche profile

On the client side, the component reads the SSE stream manually, buffers partial chunks, and updates state as events arrive. It's a bit fiddly, but the UX payoff is worth it — users can see the agent working, which builds trust.

What Does the Final Output Look Like?

After at most 3 loops, the agent returns a DetailedNiche that looks something like this:

{
  "niche": "Software development",
  "subNiche": "Backend engineering for self-taught developers",
  "contentPillars": ["System design", "API architecture", "Career growth"],
  "targetAudience": "Self-taught developers transitioning to mid-level roles",
  "tone": "Practical, no-fluff, peer-to-peer",
  "doesCurrentAffairs": "sometimes"
}

This gets persisted to Supabase via an upsert on user_id, and every subsequent AI feature in the platform uses it as context. The onboarding agent essentially writes the creative brief that the rest of the system follows.

When Should You Build Something Like This?

If your product serves a wide spectrum of users and the type of user fundamentally changes what your product should do — you probably need personalised onboarding.

A generic onboarding form gets you a generic product experience. An agent that asks the right questions gets you a product that feels like it was built specifically for that user.

The LangGraph + Postgres checkpointing pattern is the right call when:

• Your onboarding requires multiple turns (back-and-forth, not just a form submit)

• You need the conversation to survive page refreshes and server restarts

• The output needs to be structured and validated (not just a free-text summary)

If your onboarding is a single form with five fields, you don't need any of this. But if you're building a product where "who is this user, exactly?" is a hard question — this pattern is worth every line of complexity.

If this sounds familiar, you're not alone. Building a notifications system that can handle production traffic is way harder than it looks. In this post, I'm going to walk you through exactly how I built a notification service that can handle real-world load while staying reliable.

Let me start by showing you what we're dealing with here.

The Challenge

You might be thinking: "How hard can sending notifications be?" Well, buckle up. Here's what you actually need to handle:

You need to send thousands of notifications simultaneously without overwhelming the Push Notifications API. You need to retry failed messages intelligently so they eventually deliver. You need to track what fails and why. You need to monitor everything so you catch issues before your users do.

And you need to do all of this while keeping your database load reasonable. That last one is super important because your primary database is probably doing a lot of other work too.

So yeah. It's not just a "send notification and hope it gets delivered."

The Architecture

Here's the system I built. It has several key pieces working together:

FastAPI Application: Webhooks and triggers hit this. It enqueues notifications but doesn't wait for them to actually send.

NotificationEnqueueService: Figures out who needs to receive the notification based on sharing settings, grabs their push tokens, and gets everything ready.

CacheService: A two-tier cache using Redis for speed and Supabase as a fallback. This is crucial for performance.

NotificationService: The workhorse. It processes messages from the queue, handles retries, talks to Expo, and moves failures to a dead letter queue.

Supabase Queue (pgmq): Message queue that persists notifications until they're sent. The setup had 2 queues, an initial queue for persisting notifications and a dead-letter queue for persisting failed notifications.

NotificationScheduler: Runs every 15 minutes to process pending notifications in batches.

Expo Push Notification API: Actually delivers the notifications to user devices.

The key insight here is that sending notifications is async. Your API returns immediately. Then the scheduler processes them in the background. This keeps your endpoints fast and prevents your database from getting hammered.

Where Performance Matters

Let's talk about the parts of this system that actually affect how well it scales.

Caching Strategy

Notification settings and push tokens get requested a lot. If you hit the database for every single user every single time you need their settings, your database is toast.

So I implemented a lazy-loading cache using Redis:

1. Check Redis first (super fast)

2. On cache miss, fetch from Supabase (slower but still reasonable)

3. Cache the result for an hour

4. If Redis is down, just use Supabase directly

The key thing is: never fail if Redis is unavailable. Your notifications are too important. Always have a fallback.

This approach reduced database queries by about 80 percent for frequently accessed data. That's a massive difference when you're handling high volume.

Batch Operations

Fetching notification settings one user at a time would be incredibly slow. Instead, I use Redis MGET to fetch multiple items in one call. Then any items that aren't cached get fetched from Supabase in a single batch query.

So instead of 1000 database calls, you might make 5 or 10. The difference is night and day.

Concurrency Control

The Expo API has rate limits. If you hammer it with too many concurrent requests, it will reject you. But you also don't want to send notifications one at a time because that's painfully slow.

So I use asyncio.Semaphore in Pyhon to limit concurrent sends. By default it's set to 20 concurrent requests, and can easily be scaled up or down based on your Expo rate limits. This keeps the Expo API happy while still moving through the queue quickly.

When you hit a rate limit, the system backs off exponentially. First retry after 2 seconds, then 4, then 8, and so on. This gives the API time to breathe without losing messages.

Handling Failures Gracefully

Here's the thing about production systems: things fail. Your job is to make sure failures don't cascade and destroy everything.

Dead Letter Queue

If a notification fails to send after retries, it moves to a dead letter queue for manual review. But I don't keep failures around forever. After 3 failures, the message is logged and discarded.

Why log it and not just ignore it? Because you need visibility into what's breaking. I use PostHog to capture these errors with full context. Then you can actually investigate and fix issues instead of wondering why notifications are missing.

Exponential Backoff

When a message fails, you don't want to immediately retry. And you definitely don't want to retry at the same time as everything else that failed. Exponential backoff with some randomness spreads out retry attempts so you don't create a thundering herd that brings the whole system down.

The Real World Problems I Ran Into

Building this thing in production meant running into some annoying edge cases.

Environment Variable Shenanigans

I had my REDISDB environment variable set to a string instead of a number. This caused a ValueError when the code tried to convert it to an integer. Dumb mistake, but it happens. The fix was simple: create a helper function that safely parses integer environment variables and gracefully falls back to defaults.

This made me realize something important. Your configuration parsing needs to be bulletproof. If it crashes, your entire service is down before it even starts.

Breaking Changes in Dependencies

The Expo SDK updated to version 2.2.0 and changed exception names from PushResponseError to PushServerError. Plus the constructor signature changed. This broke all my error handling.

The lesson here is tedious but important: vendor dependencies carefully. Test your error handling paths. Keep an eye on changelog updates, especially for critical dependencies.

Redis Availability

Redis going down shouldn't cause the whole system to fail. But I had to explicitly handle this in the cache layer. If Redis doesn't respond, don't crash. Just use Supabase. Yes, it's slower. But slow is better than broken.

Testing All This Complexity

With this many moving parts, you absolutely need comprehensive tests. I wrote 50 tests covering unit, integration, and scheduler scenarios.

The tricky part was mocking all the dependencies correctly. Supabase, Redis, and Expo all needed to be mocked in a way that actually tests the logic. I used pytest fixtures for each service and monkeypatching for dependency injection.

One thing I learned: test the happy path, but spend even more time on error cases. The happy path usually works. It's the errors that bite you in production.

Performance Gains That Actually Matter

Let's get concrete about what this architecture actually does for you:

Caching: 80 percent reduction in database queries for notification settings and push tokens.

Batch Operations: Instead of 1000 individual database calls, you make maybe 10. That's a massive difference.

Concurrency Control: You can process notifications at high volume without overwhelming the Expo API.

Queue Processing: Handles 100 messages per scheduler run. You can increase this if needed.

Lazy Loading: Only caches data when it's actually used, so memory usage stays reasonable.

Put these together and you've got a system that can actually scale.

Key Takeaways

If you're building a notifications system, here's what matters:

1. Always have fallbacks. Redis is great, but Supabase fallback is what keeps you alive when things break.

2. Test thoroughly. 50 tests might sound like a lot, but for critical infrastructure it's the minimum.

3. Handle errors gracefully. Never let a single failure break the whole system. Log it, track it, but keep moving.

4. Monitor everything. PostHog integration gives you visibility into what's actually happening. You can't fix what you can't see.

5. Design for scale from the start. Concurrency control and batch processing aren't optional if you plan to grow.

Wrapping Up

Building a notification system that handles real production load is hard. You need reliability, performance, and observability all at the same time. But when you get it right, you've got something that scales, fails gracefully, and gives you the visibility to fix issues before they become disasters.

The system I built here uses Python, FastAPI, Supabase, Redis, Expo Server SDK, PostHog, and the APScheduler in Fast API. All of these are solid production-ready tools. The real trick is putting them together in a way that doesn't fall over when things get busy.

If you're tackling this problem, I hope this gives you some ideas for how to approach it. Notifications might seem simple on the surface, but getting them right in production is where the real engineering happens.

A sitemap is a file that gives search engines information about what pages, media content, or files are important on your website. Sitemaps are very effective on large-scale websites and better help search engines discover URLs for your website.

Sitemaps are usually in XML format (XML is a markup language with a similar structure to HTML), but sitemaps can also be written in plaintext or RSS (RSS has a similar structure to XML).

What Does a Sitemap Look Like?

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
    <url>
        <loc>https://www.example.com/</loc>
        <lastmod>2023-09-01</lastmod>
        <changefreq>daily</changefreq>
        <priority>1.0</priority>
    </url>
    <url>
        <loc>https://www.example.com/about</loc>
        <lastmod>2023-08-25</lastmod>
        <changefreq>monthly</changefreq>
        <priority>0.8</priority>
    </url>
    <!-- More URLs can be added here -->
</urlset>

Explanation of the Elements

• <urlset>: The root element that encapsulates all the URLs in the sitemap. It uses a standard XML namespace.

• <url>: This element represents a single URL in the sitemap.

• <loc>: The location of the URL (i.e., the full URL of the page).

• <lastmod>: The date when the URL was last modified. This helps search engines understand how recently the content has been updated.

• <changefreq>: Indicates how often the content at the URL is expected to change (e.g., "daily," "weekly," "monthly").

• <priority>: A value between 0.0 and 1.0 that indicates the priority of the URL relative to other pages on the site.

Creating your own Sitemaps

Now that you know what a sitemap looks like, you are free to create your own sitemaps manually, but there are many sitemap generator tools online like xml-sitemaps.com to help you generate your sitemap. If you're using WordPress, plugins like Yoast SEO can help you generate your sitemaps. If you build your web applications with a framework like Next.js, you can write your sitemaps using Typescript which is later converted to an XML-based sitemap at build time.

Submitting your Sitemaps

According to Google Search Central, "a sitemap is merely a hint: it doesn't guarantee that Google will download the sitemap or use the sitemap for crawling URLs on the site.". In order to make your sitemap available to Google, you can either:

1. Submit the sitemap on the Google Search console

2. Use the Google Search Console API

Make sure to keep your sitemaps updated regularly and do not overload your sitemaps in order to maintain their efficiency.

If you want to know more about sitemaps, you can checkout Google Search Central at https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview

If you came this far, thanks a lot for reading, and if you'd like to discover more tips like this or you want to connect with me, connect with me on LinkedIn!

AWS had suspended my account over the unpaid charges from the RDS instance that was still running(which was so funny because I swore I turned those off), and just like that my beloved cloud storage was gone. But then I remembered that Google Cloud had a similar service with their storage buckets.

So I thought to myself this was a good time to learn Terraform as I had heard so many good things about it. So if you've never heard about Terraform, it is an infrastructure-as-code tool that enables you to spin up infrastructure and set up resources in the cloud (clear of AWS CloudFormation btw, an argument for another day).

Using Terraform I was able to quickly set up my environment on Google Cloud Platform and provision a new storage bucket in my project right from my code editor. The wonderful thing about Terraform is that it is cloud-agnostic as it is not for a specific cloud vendor and can be used with multiple cloud vendors or providers like AWS, Google Cloud Platform, or Microsoft Azure just to name a few.

To get started with Terraform:

1. Install the Terraform binary for your device, depending on your OS. You can get the latest version of Terraform from https://developer.hashicorp.com/terraform/install

2. Add Terraform to PATH.

   Instructions for Windows: https://stackoverflow.com/a/55949463

   Instructions for MacOS and Linux: https://stackoverflow.com/a/50445479

3. Make sure you have the AWS CLI or Google Cloud CLI installed and you have authenticated into the respective CLI

4. Create the Terraform configuration at the root of your project in a file called main.tf

    terraform {
      required_providers {
        aws = {
          source  = "hashicorp/aws"
          version = "~> 4.16"
        }
   
        google = {
          source = "hashicorp/google"
          version = "4.51.0"
        }
      }
    }
   
    provider "google" {
      project = "sylvan-repeater-407810"
      region  = "us-east4"
      zone    = "us-east4-c"
      credentials = file("./docguard-service-key.json")
    }
   
    resource "google_storage_bucket" "docguard-bucket" {
      name = "docguard-bucket-v1"
      location = "us-east4"
    }
   

   The above block of code is called the Terraform configuration.

   The terraform {} section will contain all the settings including the required providers you need in your project.

   The provider {} section shows the details for the provider(s) you want to use, for example in this configuration, I used the google provider and it contained the project id, region, availability zone, and my credentials file.

   The resource {} section contains the resource or service you're trying to set up on a particular provider. For example, in this configuration, I was using the "google_storage_bucket" service on the "google" provider, and I called the storage bucket "docguard-bucket-v1".

   You may be wondering what the difference is between required_providers and provider . required_providers will and must contain all the Cloud Providers you will be using in your project so that they can be installed by Terraform, while provider shows the configuration for each of the providers you specified in required_providers.

   Another important thing to note in this is that, provider shows what cloud vendor you're using in your configuration. You can have more than one provider block. While resource shows what resources you want to set up for each provider.

5. Now that your Terraform configuration is done, we have to start up Terraform using terraform init . This lets Terraform download the providers and everything needed to build your infrastructure.

6. Next, you can validate if the changes in your configuration (main.tf) are valid using the terraform validate . If the changes in your configuration are valid, the CLI will return a success message.

7. Finally, you can apply your changes and push your provisioned infrastructure to your cloud provider using the terraform apply command.

And that's it. Basic cloud computing all from your code editor with minimal effort. If you liked this article, give it a like or comment, and feel free to connect with me on LinkedIn or Twitter.

Thanks for reading, and I'll see you in the next one!

Caching Design Patterns

You have a cache yes, but how do you get data into it? Caching Design Patterns are different rules you use to populate your cache (get data into your cache). Each design pattern has its advantages and disadvantages, therefore you should use a certain pattern depending on what your app/system requires. Let's Dive In!

1. Cache Aside/Lazy Loading: In this design pattern, the app checks the cache first, if there is a cache hit, it returns the result to the app, but if there is a cache miss, the app then checks the primary database, retrieves the result, then updates the cache, before returning the result to the app.

   This is pretty simple to implement, plus only requested data will be kept in the cache, and should the cache fail, it won't be fatal. It just results in increased latency till the cache is populated again.

   But there are some downsides: any cache miss results in 3 extra trips, one to the primary database, the trip back to the cache, and the trip back to the app. Data can also get stale, and it is the responsibility of the developer to invalidate this data (more on this later)

2. Write Through: In this design pattern, the cache is updated immediately after writes are made to the database. This reduces the number of trips needed to get data into the cache (2 trips as opposed to 3 in lazy-loading) and data in the cache is never stale.

   But the downside of this is that: cache churn is a huge possibility (lots of data in the cache that will never be read), and the cache may never be filled with certain data till a write of it has been made to the database.

Cache Eviction

A cache size is designed to be small, so that search is fast and efficient. But due to its small size, the cache is bound to get full. It is our responsibility as developers to decide how the data in the cache gets removed, whether the cache is full or not. This is called cache eviction. There are 3 main ways of implementing cache eviction, which are:

1. Explicit Deletion: This means explicitly removing a certain piece of data from the cache. This can be used whether the cache is full or not.

2. Removing the LRU data: LRU stands for least recently used. This means removing the data that was retrieved the earliest from the cache. This eviction strategy is used when the cache is full. This can be easily implemented by tracking when a certain piece of data was last retrieved.

3. Using a TTL: TTL means Time-To-Live. Essentially this means every piece of data in the cache will only live in the cache for a certain amount of time, like 60 minutes. Once that time elapses, the data is removed from the cache. Adding TTLs to your cached data can be very useful for combatting cache churn in the write-through design pattern. This is used to prevent the cache from keeping stale data and can be used if the cache is full or not.

Lastly, if your cache evictions happen too frequently, you might want to consider scaling up or scaling out your cache. Scaling up means increasing the cache size while scaling out means adding more cache nodes to your system.

If you enjoyed this, don't forget to leave a like or a comment, and you can connect with me on LinkedIn or Twitter. Thanks for reading and I'll see you in the next one!

Let's say you had a bad with a lot of items in it, like some books and a laptop. Each time you needed something, you had to go all the way to your bag, pick it up, and take it back once you were done with it. And if you needed that item again, you would have to go all the way back to your bag and pick it up again. Obviously, this would start to get annoying at some point. What if you could keep each item you used on a close by table when you were done with it, so if you needed it again, you could just pick it up from the table, instead of going all the way to your bag. That's caching right there!

Caching is a mechanism aimed at improving software performance by storing frequently accessed data for future requests of that same data.

But we're still storing the same frequently accessed data somewhere so how exactly does it make things faster? The frequently accessed data being stored is stored somewhere called a cache, and retrieving an item from a cache database, is much faster than retrieving an item from a traditional database. Why? Because a cache database stores items in memory and not in storage or on the disk. And memory is much faster than the disk.

Why should we cache data?

As explained earlier, we cache data to improve the performance of our application. Obtaining cached data takes less time to complete, and you potentially reduce the amount of load on your primary database.

When should we cache data?

Like every other tool and pattern, caching has where it shines. Caching is optimal when you have data that doesn't change frequently. If your data changes very frequently then caching would not be the best solution to improve performance because the data in the cache will constantly be stale (outdated).

Caching Terminologies

1. Cache Hit: When data is requested from a cache and the data is present in the cache, it's called a cache hit.

2. Cache Miss: When data is requested from a cache and the data is not present in the cache, it's called a cache miss.

3. Stale Data: When a price of data in the cache is outdated, the data is referred to as stale.

4. Invalidation: This is the process of declaring a particular piece of data as stale (and possibly re-fetching it).

5. Least Recently Used (LRU): This is the data in the cache that has not been requested for the longest.

6. Time-To-Live (TTL): This is the amount of time a piece of data can live in a cache.

How to implement caching

On the Frontend (Client-side)

We can implement caching on the client side by using the @tanstack/react-query library as a wrapper around our API calls. It comes with an in-built cache.

In this example, the cache is identified by a key, which is 'users'. When the API request is made, it checks the cache to see if the data with that key is present. If it's not, it makes a request to the server and automatically caches the result.

const fetchUsers = async () => {
  const response = await fetch('https://api.example.com/users');
  if (!response.ok) {
    throw new Error('Network response was not ok');
  }
  return response.json();
};

const UsersComponent = () => {
     const { isLoading, isError, data, error } = useQuery('users', 
fetchUsers);
    //Users compoenent implementation
}

Tanstack Query allows you to customize your cache settings like the time before data is declared stale, or a mechanism to invalidate cached data. You can check them all in the official documentation https://tanstack.com/query/latest/docs/framework/react/overview

On The Backend (Server-side)

On the server side of things, caching is mostly used when making calls to the database. We can implement caching by using an in-memory database called Redis.

const express = require('express');
const redis = require('redis');
const { User } = require('./models')

const app = express();
const client = redis.createClient();

// Helper function to check cache and fetch data
async function getData(key, fetchData) {
  const cachedData = await client.get(key);

  //If data is in the cache
  if (cachedData) {
    return JSON.parse(cachedData);
  }

  //Else
  const freshData = await fetchData();
  client.set(key, JSON.stringify(freshData));
  return freshData;
}

// Function to fetch data from database using Sequelize
async function getDatabaseData() {
  return await Users.findAll();
}

// API endpoint with cache
app.get('/api/data', async (req, res) => {
  try {
    const data = await getData('database-data-key', getDatabaseData);
    return res.json(data);
  } catch (error) {
    console.error(error);
    return res.status(500).send('Internal Server Error');
  }
});

In this example, we're using Redis with Node.js to cache calls from our SQL database (it can be any database of your choice). When the request is made to that endpoint, it checks the cache first. If the data is in the cache, it returns it from the cache, else it checks the database, and then updates that value in the cache (although this flow I just explained is not always the case, as there are different caching strategies).

I like to keep things short so that's it for today, if you liked this, be sure to leave a like or a comment and connect with me on LinkedIn at https://linkedin.com/in/fortunealebiosu and stay tuned for the next part of this series.

The useEffect hook is used for side effects (data fetching, updating the DOM, subscribing to real-time events, etc). I'm sure you're aware of the second parameter of useEffect, the dependency array, which holds the state that useEffect will react to when that state changes. You might want certain code to run when that state is equal to a certain value, and if your first instinct is a useEffect, you'd want to look at things a different way. Let's say we have a state to track how many digits we've entered into an input.

const PinComponent = () => {
    const [pin, setPin] = useState("");

    useEffect(() => {
        if (pin.length > 4) {
            alert("PIN is already 4 digits")
        }
    }, [pin]);

    return (
        <input 
            value={pin} 
            onChange={(e) => setPin(e.target.value)} 
        />
    )
}

We can avoid the useEffect by checking the pin length inside the onChange function before a new digit is entered.

const PinComponent = () => {
    const [pin, setPin] = useState("");

    const handleChange = (e) => {
        if (pin.length > 4) {
            alert("PIN is already 4 digits")
        }
        setPin(e.target.value)
    }

    return (
        <input 
            value={pin} 
            onChange={handleClick} 
        />
    )
}

Also, note that whether the dependency array is empty or not, useEffect will run at least once (when your component is mounted). Keep that in mind to avoid unexpected results.

2. Group elements that need certain state into components.

I'm sure you remember one of the fundamentals of React, when a state changes your component re-renders. We might have a big component, with lots of elements like a whole page with several state, and when a single state changes, this whole component re-renders and this not performant at all. Let's take a login page, for example. We have email, and password as state. Whenever the user enters any character in the email or password field, the whole login page re-renders.

import React, { useState } from "react";

const LoginPage = () => {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");
  const [rememberMe, setRememberMe] = useState(false);

  const handleEmailChange = (e) => setEmail(e.target.value);
  const handlePasswordChange = (e) => setPassword(e.target.value);
  const handleRememberMeChange = () => setRememberMe(!rememberMe);

  const handleSubmit = (e) => {
    e.preventDefault();

    // Perform login logic here using 'email' and 'password'
    console.log("Logging in with:", email, password);
    console.log("Remember Me:", rememberMe);
  };

  return (
    <div>
      <h2>Login Form</h2>
      <form onSubmit={handleSubmit}>
        <label>
          Email:
          <input 
            type="email" 
            value={email} 
            onChange={handleEmailChange} 
            required 
           />
        </label>
        <br />
        <label>
          Password:
          <input 
            type="password" 
            value={password} 
            onChange={handlePasswordChange} 
            required 
           />
        </label>
        <br />
        <label>
          <input 
            type="checkbox" 
            checked={rememberMe} 
            onChange={handleRememberMeChange} 
          />
          Remember Me
        </label>
        <br />
        <button type="submit">Login</button>
      </form>
      <p>
        <a href="/forgot-password">Forgot Password?</a>
      </p>
    </div>
  );
};

export default LoginForm;

We can improve this by creating a separate component for the from fiels and then using it inside the LoginPage component. As used below.

import React, { useState } from "react";

const LoginForm = () => {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");
  const [rememberMe, setRememberMe] = useState(false);

  const handleEmailChange = (e) => setEmail(e.target.value);
  const handlePasswordChange = (e) => setPassword(e.target.value);
  const handleRememberMeChange = () => setRememberMe(!rememberMe);

  const handleSubmit = (e) => {
    e.preventDefault();

    // Perform login logic here using 'email' and 'password'
    console.log("Logging in with:", email, password);
    console.log("Remember Me:", rememberMe);
  };

  return (
    <form onSubmit={handleSubmit}>
        <label>
          Email:
          <input 
            type="email" 
            value={email} 
            onChange={handleEmailChange} 
            required 
           />
        </label>
        <br />
        <label>
          Password:
          <input 
            type="password" 
            value={password} 
            onChange={handlePasswordChange} 
            required 
           />
        </label>
        <br />
        <label>
          <input 
            type="checkbox" 
            checked={rememberMe} 
            onChange={handleRememberMeChange} 
          />
          Remember Me
        </label>
        <br />
        <button type="submit">Login</button>
      </form>
  );
};

export default LoginForm;

const LoginPage = () => {

  return (
    <div>
      <h2>Login Form</h2>
      <LoginForm/>
      <p>
        <a href="/forgot-password">Forgot Password?</a>
      </p>
    </div>
  );
};

export default LoginForm;

3. Using UI libraries unjudiciously

   It's not uncommon to get help from a UI library to build out UI components like buttons, inputs, and the likes. Creating UI components from scratch can be very time-consuming and distracting from the actual task at hand. I have a LinkedIn post on the best UI libraries here. But you should know how to use UI libraries judiciously because UI libraries add a significant amount of JavaScript to your JavaScript bundle (higher bundle size leads to slower initial page load). Don't install a UI library just because of a single UI component, neither should you use more than one UI library in your project. Look at every option you have and pick according to your needs. If the UI library you use does not have the UI component you seek, look for code samples of people online who have created such a component, or install an NPM package for such a component (still adds to your bundle size but not as much).

4. Knowing when to not use React

   To be a better React developer, you should also know when not to use React. Yes, React is a great tool for building UI's on the web and it has great developer experience, but React should not be your go-to tool for everything. React just like every tool has its pros and cons, it's great for interactivity (although Solid.js beats it in this aspect), but it's bad for SEO by default, and SEO is a business-critical need. You might wonder how React is bad for SEO. React ships a lot of JavaScript to the browser by default, and that bundle slows down the initial page load of your webpage. Content rendered on the browser with React is not pure HTML, so it cannot be crawled by search engine bots making it not so good for Search Engine Optimization (SEO). If you need to build a landing page or a static website (where SEO is critical) that just displays information, your go-to should be plain HTML, CSS, and JS. If you feel like you need something more sophisticated or with better developer experience, use frameworks like Qwik or Astro that ship little or no JavaScript to the browser by default. But when you need to build a web app with highly interactive views, React (although Next.js is an even better choice) is your best bet.

That's all for today, please leave a like and let me know in the comments if you enjoyed this. You can also reach out to me on Twitter and LinkedIn. Until next time, see you later friends.

Simply put, authentication is the process of identifying a user or a person when they try to access a resource. If you've ever had to show an ID before entering into a building, that's a form of authentication. Verifying if a user is who they say they are. And if you're not who you say you are, well that would be rather unfortunate.

Authentication vs Authorization

There is always confusion about the difference between authentication and authorization. Some may even think they mean the same thing. They do not, authentication is verifying a user's identity while authorization is verifying if an authenticated user has permission to access a particular resource or perform a certain action.

For example, on the popular social media app WhatsApp, authentication happens when you sign in with your phone number and a token (the OTP). But even if you are authenticated, you will not be allowed to add users to a group chat if you are not an admin, because you have not been authorized to do so. That authorization will happen when you have been made an admin.

Authentication Factors

An authentication factor is a category of security credentials that is used to verify a user who is trying to access a particular resource (a resource could be a mobile app or a website). There are different authentication factors, which are:

1. Knowledge Factor

   This is an authentication category that is based on what the user knows. For example: username/email and password, security questions, PIN, etc.

2. Qualities Factor

   This is an authentication factor that is based on what qualities or attributes the user has. For example: facial recognition, voice recognition, fingerprint detection, etc.

3. Possession Factor

   This is an authentication factor that is based on what the user has in their possession. For example: a device to receive OTP, or a hardware device to generate a token to give access.

4. Location Factor

   This is an authentication factor that is based on the location of the user trying to access the resource. For example: a mechanism that does not allow users from a specific location to use a website.

Now you must know that each of these authentication factors can be compromised, or in other words have their risks. The knowledge factor can be compromised when users use passwords or PINs that are easy to guess by attackers. The possession factor can be compromised when the device which the user uses to authenticate is stolen. And the list goes on. So it is important, to know the pros and cons of each factor and use an appropriate factor of the kind of resource you are trying to protect.

Multi-Factor Authentication (MFA) vs Two-Factor Authentication (2FA)

Before I continue, I must congratulate you on reading this far, a lot of people do not have this level of attention span.

You might not have heard of MFA, but I'm sure you heard about 2FA, and after the previous section on authentication factors, I'm sure things are starting to click in your head at this very moment. If they're not, it's perfectly fine, let's hop to it.

Two-factor authentication involves using examples from 2 different authentication factors to verify a user, for example, using username and password from the knowledge factor and OTP from the possession factor.

While multi-factor authentication involves using 2 different examples from any authentication factor, for example, using both username and password & security questions from the knowledge factor.

Authentication Strategies

As a software engineer, there are different strategies for implementing authentication. These are the different auth strategies, they will be discussed in better detail in an upcoming article.

1. Basic Authentication

2. Session Based

3. Token Based

4. JWT (JSON Web Tokens)

5. Single Sign On (SSO)

6. OAuth

If you learned something new, or like content like this be sure to leave a like or a comment. Thanks for reading, and see you soon!

1. Not using useEffect to fetch data

   useEffect is a great hook (some might not agree), and while this isn't exactly bad, it is not recommended for apps in production. You can use this if you are just learning the basics of data fetching in React, but once you get comfortable with data fetching in React you should look to use a library to implement your data fetching.

   

You can a library like @tanstack/react-query or SWR to fetch data and they automatically give you loading and error states as well as a bunch of other helpers. My go-to is @tanstack/react-query , and here's how you can fetch the people data in the previous example.

1. Using custom hooks to fetch data

   Using the previous example in #1, you might want to use this people data in another component, of course, it makes sense to just copy and paste from the previous component to the new component, right? Well, that's bad because you break the DRY (Don't Repeat Yourself) principle by doing that. When you realize you have the write the same piece of code more than once, always put that piece of code in a function.

   In React, whenever you have to fetch data, always do so in a custom hook because you never know when you're going to use that data in a different component, and it creates a nice separation of concerns. You can create a custom hook in React by simply defining a function with a name beginning with use , for example, usePeople or useCollection . Custom Hooks cannot be async functions, and can only be used in a React component.

   Here's how we create a custom hook for our people data below.

   

We can then use the usePeople hook in the people component, as well as any other component.

1. Lazy Loading

   When you deploy a React app, that app gets built into a JavaScript bundle on whatever hosting platform you decide on. When you visit that app on the web, the JS bundle gets sent to and downloaded by the browser, along with the single index.html file and your minified CSS files all at once. The JS bundle takes longer to get downloaded, and content is not rendered on the screen till that bundle has been downloaded completely (the time to complete this is called initial page load).

   But with lazy loading, the JS bundle is split into smaller chunks and is only downloaded and executed by the browser when it is needed.

   Here's how to implement lazy loading. Below we have 3 pages: Home, About, and ForgotPassword.

   

   

   

Now we lazy load the About Page and Forgot Password Page, using lazy() . When we navigate to the Forgot Password Page or About Page, it will take a while to render because the browser is downloading the JS bundle for those pages. To render a fallback while the bundle is downloading, we use the <Suspense/> component with the fallback prop. The fallback component cannot be lazy-loaded.

You can lazy load all the pages of your application if you have a very complex application, but generally, you'd want to use lazy loading for pages that would most likely never be navigated to like ForgotPassword Page, because it would not make sense for the bundle of the ForgotPassword Page to be downloaded if the page will not be navigated to.

1. Implement Error Boundaries

   Sometimes your app can crash or run into unexpected errors while your users use it. To render a fallback UI and catch errors when they happen, implement an Error Boundary in your app. You can do so using the react-error-boundary package as done below. You can also use Error Boundaries to report errors to whatever error logging service you are using by passing in a function to the onError prop on the ErrorBoundary component.

   

2. Use Typescript

   This is 2024, if you're still not using Typescript in your React Apps, then I don't know what to tell you😐. Except you're maintaining legacy code that must be kept in JavaScript or you're a total beginner at React, I highly recommend you use Typescript in all your projects.

That's all for today, please leave a like and let me know in the comments if you want a Part 2. You can also reach out to me on Twitter and LinkedIn. Until next time, see you later friends.

Today I’m going to be sharing with you some typescript utility types you can use in your code to give you that senior developer feel, and also so you can stop sprinkling type any everywhere in your codebase.

Let's begin, shall we......

1. Partial

So let's say you wanted to create a user object, as you know you can create a type or an interface for that object like below.

Let’s say you wanted to update some properties of this user object, you can define a function called update with a parameter of type User, and then spread the values of this parameter into the user object.

If we try to use this function, you can see we get an error. The values in our parameter don’t match the User type, because phone_number, id and password fields are missing.

For a quick fix, you could make all the properties on the User type optional, but that is such a junior dev move. Now this is where the Partial utility types shines.

Partial makes all your fields optional without actually modifying the existing User type, so you can calmly update your user object without the editor screaming at you.

1. Omit

Sometimes you have to create a new user in your database and you send the created user to your server via POST request from your frontend, and then your server assigns an ID to your user before sending it to the database. This can be easily done by defining a createUser function from your front end.

But here’s the problem, the ID is not given till it gets to the server, but we’re still gonna use the User type when we retrieve the user from the server, which would have been assigned an ID by then, so removing the id property is not an option.

You could easily make the id property optional, which is also such an amateur move, you can do better.

This is where the Omit utility shines. With the Omit utility, you can create a new type by removing 1 or more properties from a type you previously created.

Now you can send that user to your back end without any fears or editor hell.

1. Pick

Now, Pick is basically just the reverse of Omit. Assuming you wanted to create a new type that has some of the properties of a previous class you created. Instead of creating an entirely new type, you have the Pick utility types at your disposal. As it implies, this utility picks certain properties from an existing type, which are defined by you. For example:

This approach basically breaks the DRY rule(Don't Repeat Yourself), because both interfaces have almost the same properties.

This is much better init😂

1. ReturnType

Let’s say you defined a function that returned a string or a number, like below. You can use the ReturnType utility to get the type of what the sayHello function returns.

This is extremely useful if you don’t want to create an entirely new type for what a function may return.

That’s all for this week guys, if you liked this article be sure to leave a reaction and a comment, and for tips and tricks like these be sure to follow me here on Hashnode and on my Twitter at @alebiosu_thedev.

Alight till next week, and remember, stop sprinkling any😶

If that sounds great, lets hop in!

1. Using TypeScript (TSX)

If you are not using TSX by now, you're wrong fr.

Except if you *just* started your React journey, it's completely understandable. If not, then I have no words😐. Do yourself a favour and pick up TypeScript. I'll be releasing a React with TypeScript post soon for that

2. Defining Interfaces correctly for your props

Let's say we were creating an input component, using regular HTML input. We could define an interface to show what props the component would receive. For example, the interface below is receiving props for our Input Component.

This code isn't very flexible, if we needed to add more props like disabled or required. We would need to add them into the interface, increasing how much we'd have to write into the interface. I know some of you like typing a lot, but your typing is bad in this case💀.

Since our component is based on the HTML input, we could use the React.HTMLProps to simplify our work and make out code look a lot cleaner.

We could go further to make our component, this looks very satisfying to look at. I mean look at how those props are spread so cleanly😮‍💨.

3. Using defaultProps

Sometimes you want some of your props to have a default value in case you didn't supply a value into them. For example, you create a button component with width and height as props.

Here the width and the height would be optional, so using the ternary operator we could specify that if the width and height are undefined, they would have values of 200px and 50px respectively. There's one word to describe this approach. INELEGANT.

Let's try something else

Using the nullish coalescing operator, we could make this look better. Just like in the previous code, if the width and height are not defined via props, they would have values of 200px and 50px respectively.

But come on, you can do better than that. You are a senior dev in the making🌚. Let's try an even better approach.

Using the defaultProps object, we can define default values for our props in case they are not defined. Now doesn't this look clean👀. And it works for both JSX and TSX.

That's all for this week, if you like helpful tips like this don't forget to like this article and comment. You can also follow me on Twitter and subscribe to my blog for more content like this.

Until next time, byeeeee

If that sounds interesting, let's jump right in!

Disclaimer: Some of these may make you cry even more, so grab a tissue.

Let's begin shall we!

:invalid

This is used to style an <input> when it is invalid, for example when specify <input type="number"> and you type in text, the input is invalid.

The :invalid pseudoclass in action

:disabled

The :disabled pseudoclass is used to style a <button> when the disabled attribute is set to true.

:first-of-type/:last-of-type

This is used when you want to style the first/last of a particular element, for example

:first-of-type

:last-of-type

:is() 😅

The :is() psuedo-class is used to style every element that matches the argument provided in the parantheses, for example

:is(ul, ol){
  color: red;
}

This would style every ol and ul with the red color.

You can gain much more from the :is() pseudo-class when you try to style multiple children/descendants at once, as shown above.

Traditionally if we wanted to style the last list item of both ol and ul, we would have to do this

ul > li:last-of-type, ol > li:last-of-type {
  color: red;

The first one seems much nicer, doesn't it😏

:has() 😅

The :has() pseudo-class is used to style descendants of a particular element or possibly style a sibling element. Previously, if we wanted to style multiple descendants of an element, we would have to select each descendant separately, like this

.

But now, we can use the :has(), to select both elements together .

To style a sibling element, use the "+" operator together with the :has() pseudo-class, for example

<div>
     <h1>Hello!</h1>
     <h2>How are you</h2>
</div>

 h1:has(+ h2){
  color: red;
}

*😅 means the pseudo-class is not fully supported by all browsers, like Samsung Internet and Firefox(Android and Desktop)

That's all for this week. Don't forget to leave a like or a reaction and if you want to see related content, do give me a follow. Thank you!😄

That enough to drive me nuts.

Today I'm going to give you some tips to make sure your CSS is CSS-ing. If that sounds interesting, let's jump right in.

Tip 1: Actually Learn CSS…

Not Tailwind, Not Bootstrap, but the OG CSS. A lot of devs skip learning the actual CSS, and jump into a commitment to some random CSS framework and its long ass class names👀. If you are under this category of developers, fall out😑

Why do you do the things that you do?

Please do yourself a favour and actually learn the fundamentals, because it teaches you how CSS actually works, plus you don’t have to keep bearing the pain of looking at Bootstrap’s horrible styling. Enough said, next tipppp…….

Tip 2: Learn the Box-Model

The box model is the most fundamental piece of information you need to know as someone who writes CSS because it illustrates how your HTML elements are styled with CSS. Incase you haven't heard of Box Model before or you're one of those guys who decided to skip it :/, I've got good news. The Box Model is actually really easy to understand, and you're going to learn it right now.

Every element in your HTML code is a box (your h1, nav, div, etc).The content of the box is whatever you put inside that tag .You can give each box a width and a height. The box can also have a border of any thickness. If you want to make space around the box, you give it a margin, if you want to squeeze-in the contents of the box, give it some padding. And that all there is to it. Seeeeee……that wasn’t bad, was it?😏

Quick heads up: Sometimes you may give an element some padding, and it seems as though the padding increased the width or the height of your element causing it to overflow, use box-sizing: border-box; to get it back to it's orginal size.

Tip 3: display: flex; is your friend

If you are trying to arrange some items on your webpage, display: flex; is always the way to go, except you’re trying to arrange it in rows and columns(then you use display: grid, more on that later). When you apply display: flex to an element or a container, the contents of that elements flow either horizontally or vertically(row or column respectively), but by default it is horizontally. You can control this with the flex-direction property. To arrange the items on the vertical axis, use the align-items property.

To arrange the items on the horizontal axis, use the justify-content property.

This is just a fraction of what flexbox can do, for a complete guide on flex, click here. The most complete tutorial on flex I've seen.

Tip #4: flex vs grid??:

Don’t know when to choose between display:flex and display:grid? Lemme help you out with that You use display: grid when you are trying to arrange different boxes/items in rows and columns. Grid basically focuses on both row and colums. Unlike grid, flexbox(display: flex) arranges items in just one direction, either row or column. You can change this with the flex-direction property.

You can use flexbox for something like this.

You can use grid for something like this.

Tip 5: Use CSS shorthands

If you prefer the one at the left, well I got no words😐.

Basically I'm saying, you should learn to use CSS shorthands, so you don't end up overcomplicating things. This may not seem like a big deal, but in the long run, this would probably lead to a larger CSS file that the browser has to download when users visit your site. If you find it difficult trying to memorize the order of the shorthand values, just think of clockwise rotation: top -> right -> bottom -> left. Therefore, margin: 15px 10px 4px 8px; means 15px for top margin, 10px for right, 4px for bottom, and 8px for left.

Bonus Tip👀

If you want an element to appear on top of another, use the z-index property. An element with higher z-index will appear on top of an element with a lower one. i.e. An element with z-index: 10; will appear on top of another withz-index: 3;

That's all for this week. Thank you for reading 🤭. If you liked this article, please drop a reaction and let me know in the comments if you want to see a part 2 of this article.

If you found this helpful, give me a follow for more related content.

From what we know, div’s do not have any semantic meaning, so why do you keep spamming them in your code?🙂

Today I’m going to be sharing with you a foolproof way of writing a proper HTML markup, while using semantic tags as well, not the spamming of div’s that most beginners are used to.

Tip #1:

Separating your HTML body using header, main and footer tag.

You should always separate the contents of your body tag, using the header, main and footer tag.

Not just by using DIVS!!

This is.......eww

Isn't this nicer?🙂

This helps anyone who looks at your code to understand what is fully going on. Elements like nav should always go inside your header. The main content of your website/webpage should go into your main. And the footer of your website, clearly would go into the footer.

For those who may not know what a footer is.

Tip #2:

When making a navbar always use the nav tag. This and indicates that the highlited section of code is what represents the navbar. Also use a div tag to wrap all the elements of your navbar together.

This prevents your navbar from overflowing when your give it some left and right padding.

Tip #3:

Use the section tag to separate or group similar contents of your webpage together.

Every element inside the red rectangles should be wrapped with the section tag.

Again, stop using divs for this purpose.

Tip #4:

Use div’s as containers to hold 2 or more elements together. For example your want to hold two buttons together, or a h3 and a p tag together.

One thing I also see regularly which I feel is bad practice is using divs as buttons. We have the button tag for that. If you want to list items in a container, use the ol or ul tag.

If you don't want the bullet points on your ol and ul tags, you can always set the list-style-type property to none in your CSS

Don't do this.

Do this instead

Tip #5:

Keep off Inline Styling

Like for real, stay away from it as much as possible. It makes your code look really unreadable and bloated in my opinion. Perhaps your could try internal styling (still bloats your code, not as bad as before) or even better, external css. Doing this keeps your HTML nice and clean, while separating concerns really well.

Look at how bloated this looks.

That's all for this week. Thank you for reading 🤭. And remember, cut it out with the div's!

If you found this helpful, give me a follow for more related content.

Also follow or send me a message on Twitter @alebiosu_thedev to know more about me or for a collaboration.