DEV Community: Elizabeth Sobiya

RAG: Giving AI Access to Your Own Data 🤖📚

Elizabeth Sobiya — Wed, 30 Sep 2026 11:22:24 +0000

Imagine asking ChatGPT:

“What is our company's leave policy?”

It can be a great question, but unless that information is in its knowledge, the model can't magically know your company's internal rules.

This is where RAG comes in.

So, what is RAG?

RAG = Retrieval-Augmented Generation

In simple terms:

Search first. Answer second.

Instead of asking the LLM to answer from what it already knows, we first retrieve relevant information from our own data and give that context to the model.

User Question
      ↓
Search your data
      ↓
Find relevant information
      ↓
Send it to the LLM
      ↓
Generate the answer

A simple example

Suppose you have 500 company documents.

A user asks:

“How many days of annual leave do I get?”

RAG searches those documents and finds:

“Employees receive 20 days of annual leave per year.”

That information is then passed to the LLM.

The LLM turns it into a natural response:

“You get 20 days of annual leave per year.”

The LLM didn't need to memorize your employee handbook.

It just needed to find the right piece of information.

What happens behind the scenes?

Before users start asking questions, your documents usually go through a preparation process:

Documents
   ↓
Split into smaller chunks
   ↓
Convert chunks into embeddings
   ↓
Store embeddings in a vector database

When a user asks something:

Question
   ↓
Convert question into an embedding
   ↓
Search for similar chunks
   ↓
Retrieve relevant content
   ↓
LLM generates the answer

This is the basic RAG pipeline.

Where can you use RAG?

Pretty much anywhere an AI needs access to external or private knowledge:

📄 Document Q&A
Ask questions about PDFs, reports, contracts, or research papers.

📚 Documentation assistants
Build an AI that understands your product or API documentation.

🏢 Internal knowledge
Search company policies, processes, and internal documents using natural language.

💬 Customer support
Retrieve relevant product information before generating a response.

RAG vs Fine-tuning

A simple way to remember the difference:

RAG → Give the model knowledge

Fine-tuning → Change the model's behavior

If your company's documentation changes frequently, RAG can be useful because you can update the knowledge base without retraining the model.

One important thing 🚨

RAG doesn't magically eliminate hallucinations.

If the system retrieves the wrong information, the LLM can still produce the wrong answer.

So a good RAG system isn't just:

LLM + Vector Database

It also involves good:

Chunking
Embeddings
Retrieval
Ranking
Prompting
Evaluation

And that's where things start getting interesting.

RAG is basically giving an LLM a searchable external memory.

In the next part, we'll break down what actually happens inside that pipeline, from chunking → embeddings → vector search → retrieval → final answer.

Sending Emails with Amazon SES (and Why Your Form Shouldn't Wait for Them)

Elizabeth Sobiya — Thu, 24 Sep 2026 17:52:19 +0000

I recently added email notifications to a contact form using Amazon SES (Simple Email Service). The setup was simple, but my first version had a problem: every form submission waited for the email to finish sending before the user got a response. In this post I'll walk through the basic SES setup and then show how I moved email sending into a background job so the form responds instantly.

Why Amazon SES?

SES is AWS's email sending service. It's cheap (a fraction of a dollar per thousand emails), reliable, and scales well beyond what most side projects will ever need. If you're already on AWS, it's an easy choice for transactional email like confirmations, notifications, and password resets.

Step 1: Verify a Sender Identity

SES won't send from an address until you prove you own it. In the AWS Console, go to Amazon SES → Configuration → Identities → Create identity. You can verify either a single email address or a whole domain.

Verifying a domain is the better long-term option. SES gives you DNS records to add, including DKIM records, which help your emails land in the inbox instead of spam. While you're in your DNS settings, it's also worth adding SPF and DMARC records.

Step 2: Get Out of the Sandbox

New SES accounts start in sandbox mode. In the sandbox you can only send to verified addresses, and there's a low daily sending limit. That's fine for testing, but before going live, request production access from SES → Account dashboard → Request production access. AWS usually asks how you'll use email and how you'll handle bounces and complaints.

Step 3: Create IAM Credentials

Create an IAM user (or role, if you're running on EC2/ECS/Lambda) with permission to send email. A minimal policy looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ses:SendEmail", "ses:SendRawEmail"],
      "Resource": "*"
    }
  ]
}

Add the credentials to your .env:

AWS_REGION=ap-south-1
AWS_ACCESS_KEY_ID=your_access_key
AWS_SECRET_ACCESS_KEY=your_secret_key
SES_FROM_EMAIL=no-reply@yourdomain.com

Make sure the region matches the region where you verified your identity. Identities are region-specific, so this is a common source of "email address not verified" errors.

Step 4: Send an Email from Node.js

Install the AWS SDK v3 SES client:

npm install @aws-sdk/client-sesv2

Then create a small helper:

// lib/email.js
import { SESv2Client, SendEmailCommand } from "@aws-sdk/client-sesv2";

const ses = new SESv2Client({ region: process.env.AWS_REGION });

export async function sendEmail({ to, subject, html, text }) {
  const command = new SendEmailCommand({
    FromEmailAddress: process.env.SES_FROM_EMAIL,
    Destination: { ToAddresses: [to] },
    Content: {
      Simple: {
        Subject: { Data: subject },
        Body: {
          Html: { Data: html },
          Text: { Data: text },
        },
      },
    },
  });

  return ses.send(command);
}

The SDK picks up AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY from the environment automatically, so you don't need to pass them in.

My First (Slow) Version

Here's roughly what my form submission route looked like at first:

app.post("/api/contact", async (req, res) => {
  const { name, email, message } = req.body;

  await saveSubmission({ name, email, message });

  // ❌ The user waits for this
  await sendEmail({
    to: "team@yourdomain.com",
    subject: `New contact form submission from ${name}`,
    html: `<p><b>${name}</b> (${email}) wrote:</p><p>${message}</p>`,
    text: `${name} (${email}) wrote:\n\n${message}`,
  });

  res.json({ success: true });
});

It worked, but it had real problems. The form took noticeably longer to respond because each request waited on a network call to AWS. Worse, if SES was slow, throttled, or failed, the whole submission returned an error, even though the data had already been saved. The user would see "something went wrong" and might submit again, creating duplicates.

The fix is to recognize that sending the email is not part of the form submission. The user only cares that their submission was received. The email is a side effect that can happen a moment later.

Option 1: Fire and Forget

The quickest fix is to stop awaiting the email:

app.post("/api/contact", async (req, res) => {
  const { name, email, message } = req.body;

  await saveSubmission({ name, email, message });

  // Don't await, but always catch, or you'll get unhandled rejections
  sendEmail({ /* ... */ }).catch((err) => {
    console.error("Failed to send contact email:", err);
  });

  res.json({ success: true });
});

The response is instant now. But there's a catch: if the email fails, it's just logged and lost. If the server restarts mid-send, it's lost too. There are no retries. For a hobby project this may be acceptable, but for anything important you want a proper job queue.

Option 2: A Real Background Job with BullMQ

A job queue stores the work somewhere durable (Redis, in this case), and a separate worker processes it with retries. I used BullMQ:

npm install bullmq

Create the queue:

// queues/emailQueue.js
import { Queue } from "bullmq";

export const connection = {
  host: process.env.REDIS_HOST || "127.0.0.1",
  port: Number(process.env.REDIS_PORT) || 6379,
};

export const emailQueue = new Queue("emails", { connection });

Add a job from the route:

import { emailQueue } from "./queues/emailQueue.js";

app.post("/api/contact", async (req, res) => {
  const { name, email, message } = req.body;

  await saveSubmission({ name, email, message });

  // ✅ Just enqueue: takes a few milliseconds
  await emailQueue.add(
    "contact-notification",
    { name, email, message },
    {
      attempts: 5,
      backoff: { type: "exponential", delay: 2000 },
      removeOnComplete: true,
      removeOnFail: 100,
    }
  );

  res.json({ success: true });
});

Process jobs in a worker:

// workers/emailWorker.js
import { Worker } from "bullmq";
import { connection } from "../queues/emailQueue.js";
import { sendEmail } from "../lib/email.js";

const worker = new Worker(
  "emails",
  async (job) => {
    const { name, email, message } = job.data;

    await sendEmail({
      to: "team@yourdomain.com",
      subject: `New contact form submission from ${name}`,
      html: `<p><b>${name}</b> (${email}) wrote:</p><p>${message}</p>`,
      text: `${name} (${email}) wrote:\n\n${message}`,
    });
  },
  { connection, concurrency: 5 }
);

worker.on("failed", (job, err) => {
  console.error(`Email job ${job?.id} failed:`, err.message);
});

Run the worker as its own process (node workers/emailWorker.js) alongside your API. Now the form responds right away, and if SES hiccups, BullMQ retries with exponential backoff (2s, 4s, 8s, and so on). If a job fails all five attempts, it stays in the failed set so you can inspect or retry it.

The concurrency option also helps you stay under your SES sending rate limit, since it caps how many emails the worker sends at once.

Not using Redis? If you're all-in on AWS, Amazon SQS plus a Lambda consumer is a great alternative. The API pushes a message to SQS, and a Lambda function sends the email. You get retries and a dead-letter queue built in.

Before vs After

	Awaiting email in request	Background job
Response time	Includes SES network call	Just the DB write + enqueue
SES failure	Form shows an error	User sees success, job retries
Retries	None	Automatic with backoff
Server restart mid-send	Email lost	Job still in queue

A Few Extra Tips

Handle bounces and complaints. SES tracks your bounce and complaint rates, and high rates can get your account paused. Set up SNS notifications (or an SES configuration set with event destinations) so you can stop emailing addresses that bounce.

Always send a plain-text version alongside HTML. Some clients prefer it, and it slightly improves deliverability.

Escape user input before putting it into HTML emails. In the examples above, name and message come straight from the form, so in a real app you should sanitize them to avoid HTML injection.

Keep the email content in the job payload minimal. Store IDs if the data is large, and let the worker fetch what it needs.

Wrapping Up

Setting up SES comes down to verifying an identity, leaving the sandbox, creating IAM credentials, and calling SendEmailCommand. The bigger lesson for me was architectural: anything that isn't essential to the user's request, like sending emails, generating PDFs, or calling webhooks, shouldn't block the response. Save the data, enqueue the side effect, and respond. Your users get a faster form, and your emails get retries for free.

Have you handled emails differently in your projects? I'd love to hear how in the comments! 👇

I couldn't find an npm package to sort filenames into buckets, so I built one

Elizabeth Sobiya — Tue, 14 Jul 2026 14:59:29 +0000

Last week I was building a file-management feature. Users could upload
documents, and I needed to sort them into sections. One bucket for
NOCs, one for agreements, one for invoices, one for anything else.

Simple enough. I opened npm expecting to find a package for it.

What I found instead

Every search under "sort files" or "classify filename" returned one of
three things:

sort-package-json variants (sorting keys inside package.json)
Natural-sort utilities (alphabetical ordering of file lists)
File-type detectors (identifying MIME types from extensions)

Nothing that took a list of filenames and a list of rules and gave
back named buckets.

I asked around. A few devs suggested "just use .filter()". Fair, for
one bucket. But once you need:

Multiple buckets with priority order
A fallback bucket for unmatched files
Natural sort inside each bucket
Rules from a config file or user input

...you're rewriting the same 40 lines in every project. That's
package-shaped.

So I built `classify-filename`

import { classify } from 'classify-filename';

const files = [
  'NOC_2024.pdf',
  'noc_letter.pdf',
  'agreement_v1.docx',
  'invoice_2.pdf',
  'invoice_10.pdf',
  'random.txt',
];

const result = classify(files, [
  { name: 'noc',        match: /^noc/i },
  { name: 'agreements', match: 'agreement' },
  { name: 'invoices',   match: /^invoice/i },
]);

The result:

{
  sections: {
    noc:           ['noc_letter.pdf', 'NOC_2024.pdf'],
    agreements:    ['agreement_v1.docx'],
    invoices:      ['invoice_2.pdf', 'invoice_10.pdf'],
    uncategorized: ['random.txt'],
  }
}

Notice invoice_2.pdf comes before invoice_10.pdf. That's natural
sort, the default behavior, because alphabetical sort would put 10
before 2 and that's usually not what you want with filenames.

Design decisions I actually thought about

A few choices that felt small but mattered.

Section order is priority order.
If a file matches two sections, the earlier one wins. No priority
numbers, no most-specific-match algorithm. Array order is the mental
model users already have when they write a list of rules.

Case-insensitive by default.
Files are messy. NOC_2024.pdf and noc_letter.pdf should land in
the same bucket without the user thinking about it. Regex matchers
still respect their own flags. If you write /^NOC/ you probably
meant it.

A fallback bucket, not a silent drop.
Unmatched files go to uncategorized by default. Silent drops cause
the "where did my files go?" bug I've written before. You can opt into
the drop by passing fallback: false.

An explain mode for debugging.
Set explain: true and the result includes a filename to section map,
so when someone asks "why did noc_agreement.pdf end up in NOC and
not agreements?", you can see the answer in one glance.

What's not in v1 (on purpose)

No glob support. Regex covers it. Adding globs invites ambiguity with substring matches unless done as an explicit wrapper. Planned for v1.1.
No file-metadata rules. Filename only for now. Size, date, and extension helpers coming in v1.2.
No CLI. This is a library. If people want to organize a folder from the command line, that's v1.3.

Each of these could have gone into v1. I left them out because the
scope creep would have delayed shipping, and the API stays cleaner if
each feature earns its way in with real user demand.

The stack

TypeScript, dual CJS + ESM output via tsup
Zero runtime dependencies
Tested with Vitest, around 15 tests covering the matcher and classifier
~2 KB minified

Try it

npm install classify-filename

One thing I'd genuinely like feedback on: section-array-order as
priority. Does that feel natural to you, or would you rather see an
explicit priority: number field?

Would love to hear how you'd approach this. If you find it useful, a
star on the repo helps me know it's worth pushing v1.1 out.

HawkDoc: An Open Source Notion-Style Editor Built on Lexical

Elizabeth Sobiya — Mon, 09 Mar 2026 14:46:34 +0000

I was trying to use SuperDoc for a project and kept running into limitations. Customisation was harder than expected and the performance was not where I needed it.

So I decided to build my own editor called HawkDoc, using Claude as a coding assistant for a large part of the development.

HawkDoc focuses on fast document editing with zero-lag typing. Many editors re-render large parts of the UI on every keystroke or ship heavy dependencies just to support basic formatting. I wanted something simpler and faster.

Tech Stack

Lexical (Meta) as the editor engine. Its node-based architecture avoids full re-renders during formatting operations.
Yjs + Hocuspocus for real-time collaboration using CRDTs, allowing conflict-free document syncing.
Redis + PostgreSQL for storage. Yjs deltas are first written to Redis and flushed to Postgres every 30 seconds so the database does not receive keystroke-level writes.
React + TypeScript for the frontend UI.
@react-pdf/renderer for client-side PDF export with watermark support.

What Works Today

Block-based editor
Slash commands
Template variable injection ({{variable_name}} rendered as styled chips)
Image uploads
Markdown, HTML, and PDF export
Auto-save
Selection bubble menu

What Is Still in Progress

Real-time collaboration UI
Document workspace and file list
DOCX import
Version history
Authentication UI (JWT backend already implemented)

Claude Code helped speed up a lot of the early development, especially when building the editor integrations and export pipeline.

I would be curious to hear how other developers are using AI coding assistants when building new tools.

The project is MIT licensed and open for feedback and contributions.

GitHub

https://github.com/hawk-doc/hawkdoc

Why SuperDoc Shows Only the Last Image: A DOCX Internals Investigation

Elizabeth Sobiya — Mon, 02 Mar 2026 16:20:00 +0000

While integrating DOCX generation into our document editor pipeline, I ran into one of the most confusing rendering issues I have seen so far.

A DOCX generated with multiple images displayed perfectly in Word, LibreOffice, and Google Docs. But inside the SuperDoc editor, every image slot showed the same image. Always the last one.

This post is not about a final fix yet. It is a breakdown of the debugging journey and what I discovered while tracing the root cause.

The Symptom

The generated report contained multiple property images arranged in a grid.

Expected inside editor:

Image 1 → slot 1
Image 2 → slot 2
Image 3 → slot 3

Actual result inside SuperDoc:

Slot 1 → last image
Slot 2 → last image
Slot 3 → last image

Every slot displayed the same image.

Strangely:

Microsoft Word → correct
LibreOffice → correct
Google Docs → correct
SuperDoc editor → wrong

So the DOCX itself was valid. The issue appeared editor-specific.

Environment

Tool	Version
SuperDoc	1.16.x
docx-templates	4.15.0
Node	20.x

Images inserted using docx-templates loops and loaded into editor via docxUrl.

First Check: Is DOCX Corrupt?

Initial assumption was that the DOCX generation might be broken.

So I verified:

Opened in Word
Opened in LibreOffice
Converted to PDF
Uploaded to Google Docs

Everything rendered correctly everywhere except inside the editor.

That ruled out basic DOCX corruption.

Deep Debugging Approach

Since DOCX files are just zip archives, I extracted and inspected raw XML:


word/document.xml
word/_rels/document.xml.rels
word/media/

Goal was to see how images were referenced internally.

Finding 1: Non-Standard Relationship IDs

Normally DOCX uses relationship IDs like:


rId1
rId2
rId3

But generated DOCX contained:


img2073076884
img99887766

Custom hash-based IDs.

Example:

xml <Relationship Id="img2073076884" Type=".../image" Target="media/template_document.xml_img2073076884.jpg"/>`

This is valid but not standard.

Test performed

Converted all relationship IDs to standard rId1, rId2, etc and updated references.

Result:
No change in editor behaviour.
All image slots still showed the last image.

So relationships were not the main cause.

Finding 2: Media Filenames

Generated filenames looked like:

` template_document.xml_img2073076884.jpg `

Instead of standard:

` image1.jpg image2.jpg `

Renamed them to standard format and updated references.

Result:
Still broken in editor.

So filename convention was not the cause.

Finding 3: Images Inside Tables?

Another suspicion was that images inside table cells were being flattened or merged.

Checked raw XML structure.

Images were already in standalone paragraphs.
Not nested inside complex table drawing structures.

Result:
No structural issue found.

Finding 4: Base64 External References

As a further isolation step, I also converted images to base64-encoded external references to rule out any media file resolution issue inside the editor.

Result:
Still broken. All slots continued showing the last image.

At this point, the problem had to be in how the editor was interpreting drawing node identity, not how images were stored or referenced.

The Strongest Lead So Far (Unverified)

While inspecting drawing XML for each image, one pattern appeared:

`xml <pic:cNvPr id="0" name="image1.jpg"/> <pic:cNvPr id="0" name="image2.jpg"/> <pic:cNvPr id="0" name="image3.jpg"/> `

Every image had:

` id="0" `

According to the OOXML spec, this attribute is meant to be a unique identifier per drawing object within a document.

But docx-templates appears to be assigning id="0" to all generated images.

My working theory: SuperDoc uses ProseMirror under the hood for document rendering. If ProseMirror or SuperDoc's DOCX parser is using pic:cNvPr id to distinguish drawing nodes, duplicate IDs across all images could cause it to treat them as the same node, with the last image loaded winning every slot.

That said, this is a hypothesis, not a confirmed fix. The next step is to patch docx-templates output to inject unique sequential IDs, do a clean server restart, and verify the result properly. A failed test earlier in this session turned out to be against old compiled code because the server hadn't been restarted after a rebuild.

What Has Been Tried So Far

Attempt	Result
Extract images from table	No change
Rename relationship IDs to rId1/rId2	No change
Rename media filenames to image1.jpg	No change
Convert images to base64 external refs	No change
Inspect drawing XML	Found duplicate `id="0"` across all images
Patch to unique IDs	Not fully verified yet

Current Status

Issue is still under investigation.

Leading hypothesis: duplicate pic:cNvPr id="0" across all images is causing the editor to collapse them into a single node.

Next step: inject unique IDs, do a full server restart, and run a clean verification.

Lessons From This Debugging Session

1. If it works in Word, it can still be wrong

Word tolerates many OOXML violations silently. Editors and converters are stricter. Never assume Word rendering equals correctness.

2. Always inspect DOCX internally

DOCX debugging becomes much faster once you treat it as a zip file. Unzip it, inspect the XML, search for patterns, verify structure.

3. Rendering engines behave differently

Tool	Strictness
Word	Very forgiving
Google Docs	Moderate
LibreOffice	Strict
Editor engines	Very strict

Editor-specific bugs often come from structural assumptions the spec makes but Word quietly ignores.

Why I'm Documenting This

This bug is still unresolved. But the debugging journey itself surfaced important learnings about DOCX internals, rendering engine strictness, and real-world document pipelines.

If you've encountered similar behaviour with DOCX image rendering, I'd genuinely like to hear what you found.

Microservices: Not Just an Architecture, but a Way of Thinking

Elizabeth Sobiya — Tue, 03 Feb 2026 13:04:27 +0000

There is a moment in every developer’s journey where a single codebase starts to feel heavy. Small changes take longer. Deployments feel risky. One bug fix somehow breaks three unrelated features. That is usually when the word microservices enters the conversation.

Microservices are often introduced as a solution, but they are not magic. They are a mindset shift.

Instead of building one large system that does everything, microservices encourage us to build small, focused services that do one thing well, and communicate clearly with others.

At first, this sounds like extra work. More repos, more deployments, more coordination. And honestly, it is. But when done for the right reasons, the payoff is real.

Why Microservices Exist (And When They Make Sense)

Microservices were born out of pain. Pain from scaling teams, not just servers.

When multiple teams work on the same monolith:

Merge conflicts increase
Release cycles slow down
One change requires everyone’s approval

Microservices help by giving teams ownership. Each service has:

A clear responsibility
Its own lifecycle
Freedom to evolve independently

That said, microservices are not for every project. If you are a small team or still validating a product, a well-structured monolith is often the smarter choice. Microservices shine when:

The domain is complex
Teams need autonomy
Scalability and reliability really matter

What a Microservice Really Is

A microservice is not just a smaller backend.

A true microservice:

Owns its own data
Has a single, well-defined purpose
Communicates via APIs or events
Can be deployed independently

Think of it like a team member. You do not want one person doing everything. You want people who are clear about their role, dependable, and easy to collaborate with.

How to Start Exploring Microservices Without Overwhelm

You do not need to rebuild everything to learn microservices.

Here are practical ways to explore them safely:

1. Start by Splitting by Responsibility

Look at your current system and ask:

Authentication
Payments
Notifications
Reporting

These are natural boundaries. Even mentally separating them helps you understand service boundaries.

2. Build One Service Independently

Pick one small feature and build it as a separate service:

A notification service
A file processing service
A background job worker

Deploy it independently. Observe how it feels to version, test, and scale it alone.

3. Learn Communication Patterns

Microservices live and die by communication:

REST APIs for simplicity
Async messaging for scalability
Events for loose coupling

Understanding when to use which is more important than choosing the “best” tool.

4. Embrace Observability Early

Logs, metrics, and tracing are not optional here. When things go wrong in microservices, visibility is your safety net.

The Hidden Lesson Microservices Teach

The biggest thing microservices teach is discipline.

You are forced to:

Define clear contracts
Respect boundaries
Write better documentation
Think about failures upfront

Even if you never fully adopt microservices, this way of thinking makes you a better engineer.

Final Thoughts

Microservices are not a destination. They are a tool, and like all tools, they work best when used with intention.

If you are curious, start small. Experiment. Break things in side projects. Learn why companies chose this path, and also why some walked back.

And if nothing else, let microservices remind you of this simple truth:

Good software is less about size, and more about clarity.

Understanding Session Storage in Web Development: Pros, Cons, and Implementations

Elizabeth Sobiya — Tue, 22 Jul 2025 15:06:48 +0000

Managing user data on the client side is crucial for modern web applications. One of the most important—yet often misunderstood—features for temporary client-side storage is session storage.

In this post, you'll learn what session storage is, how to implement it, and when to use it effectively by weighing its advantages and disadvantages.

🧩 What Is Session Storage?

Session storage is part of the Web Storage API that lets you store key-value pairs temporarily in a user’s browser.

Unlike local storage—which persists data until explicitly deleted—data in session storage is cleared automatically when the tab or browser window is closed.

🔑 Key Highlights

Scope: Isolated to a specific browser tab or window
Persistence: Automatically cleared on tab/window close
Capacity: Typically 5–10 MB per origin
Access: Restricted by the same-origin policy

🎯 Why Use Session Storage?

Session storage is ideal when data is temporary and shouldn’t persist beyond a single session.

✅ Common Use Cases:

Multi-step forms: Preserve form inputs across steps or accidental reloads
Shopping carts: Keep selected items while users browse
Auth tokens: Store temporary tokens without cross-tab sharing
UI preferences: Save temporary states like sidebar collapse or themes

🛠️ Basic Implementation

Session storage is super easy to use. Here's a basic breakdown:

// Store data
sessionStorage.setItem('key', 'value');

// Retrieve data
const value = sessionStorage.getItem('key');

// Remove a specific item
sessionStorage.removeItem('key');

// Clear all session storage
sessionStorage.clear();

📝 Note: Session storage only stores strings. For objects or arrays, use JSON.stringify() before saving and JSON.parse() when retrieving.

🎨 Example: Saving a UI Theme

// Set dark theme
sessionStorage.setItem('theme', 'dark');

// Retrieve theme
const theme = sessionStorage.getItem('theme'); // 'dark'

// Remove theme
sessionStorage.removeItem('theme');

📈 Pros & Cons of Session Storage

✅ Pros	❌ Cons
Tab-level isolation (no cross-tab sharing)	Data is lost when tab/window is closed
Larger capacity than cookies (5–10 MB)	Not suitable for persistent or critical data
Automatic cleanup (no need to manage expiry)	Cannot share state between tabs/windows
Simple, synchronous API	Vulnerable to XSS if inputs aren’t sanitized
Reduces server load for temporary data	Blocking issues if used for large data due to synchronous nature
Useful for one-tab-only auth/token scenarios	Not supported in some very old browsers

🔐 Security Considerations

Since session storage is entirely client-side:

Never store sensitive data like passwords or payment details.
Be cautious of XSS attacks—sanitize inputs and validate data.
If you're handling authentication, prefer secure, HttpOnly cookies for persistent or sensitive tokens.

🧠 When to Use Session Storage

✅ Ideal When:

You need temporary data storage (e.g., form inputs, temporary tokens)
You want to prevent cross-tab sharing (e.g., multi-login environments)
You’re handling non-sensitive, short-lived UI states

🚫 Avoid When:

You need data persistence across sessions or tabs
The data must be available on the server (cookies are better here)
You’re storing sensitive information

🧪 Best Practices

JSON.stringify() complex data before saving
Handle quota errors gracefully (especially in Safari/private mode)
Clean up unused session data to prevent clutter
Always test across browsers for compatibility

✅ Conclusion

Session storage is a powerful, lightweight tool for handling temporary, tab-specific data. Used properly, it enhances UX, improves performance, and simplifies state management.

But remember—it’s not a one-size-fits-all solution. Always evaluate the nature of your data, persistence needs, and security before deciding on your storage strategy.

React Design Patterns That’ll Make You a Better Dev

Elizabeth Sobiya — Thu, 01 May 2025 11:41:48 +0000

Hey folks! 👋

If you've been working with React for a bit, you’ve probably heard people throw around terms like HOC, Render Props, Container-Presenter, or even Compound Components.

Sounds fancy, right? But what do these actually mean—and more importantly—why should you care?

Let’s break down a few common React design patterns, no theory overload, just straight-up use cases and examples you’d see in your day-to-day code.

🧱 1. Container and Presentational Pattern

What it is:

Split components by logic (container) and UI (presentational).

Why:

Keeps things clean. Easy to test, reuse, and manage.

Example:

// Container
function UserContainer() {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetchUser().then(setUser);
  }, []);

  return <UserProfile user={user} />;
}

// Presentational
function UserProfile({ user }) {
  if (!user) return <p>Loading...</p>;
  return <div>{user.name}</div>;
}

✔️ Logic stays in one place.

✔️ UI stays dumb and pretty.

🌀 2. Higher Order Components (HOC)

What it is:

A function that takes a component and returns a new one with extra powers.

Why:

Great for code reuse (e.g., auth, logging, theming).

Example:

function withLogger(WrappedComponent) {
  return function(props) {
    useEffect(() => {
      console.log('Component loaded!');
    }, []);

    return <WrappedComponent {...props} />;
  };
}

const FancyButtonWithLog = withLogger(FancyButton);

⚠️ Be careful: Too many HOCs = wrapper hell.

🔁 3. Render Props

What it is:

You pass a function as a prop and call it inside the component to render stuff.

Why:

Flexible. Cleaner than HOCs in some cases.

Example:

function MouseTracker({ render }) {
  const [pos, setPos] = useState({ x: 0, y: 0 });

  useEffect(() => {
    const handler = e => setPos({ x: e.clientX, y: e.clientY });
    window.addEventListener('mousemove', handler);
    return () => window.removeEventListener('mousemove', handler);
  }, []);

  return render(pos);
}

// Usage
<MouseTracker render={({ x, y }) => <h1>{x}, {y}</h1>} />

🧠 Think of it like passing a component’s brain to another component’s face.

🧩 4. Compound Components

What it is:

Multiple components that work together using React context.

Why:

Great for building reusable UI libraries or dynamic forms.

Example:

function Tabs({ children }) {
  const [active, setActive] = useState(0);
  return (
    <TabContext.Provider value={{ active, setActive }}>
      {children}
    </TabContext.Provider>
  );
}

Tabs.Tab = ({ index, children }) => {
  const { active, setActive } = useContext(TabContext);
  return (
    <button onClick={() => setActive(index)} style={{ fontWeight: active === index ? 'bold' : 'normal' }}>
      {children}
    </button>
  );
};

Tabs.Panel = ({ index, children }) => {
  const { active } = useContext(TabContext);
  return active === index ? <div>{children}</div> : null;
};

Use like:

<Tabs>
  <Tabs.Tab index={0}>Home</Tabs.Tab>
  <Tabs.Tab index={1}>Profile</Tabs.Tab>

  <Tabs.Panel index={0}>Welcome Home</Tabs.Panel>
  <Tabs.Panel index={1}>Your Profile</Tabs.Panel>
</Tabs>

🚀 Fancy but powerful. Think Lego bricks that click together.

🧠 TL;DR

React design patterns aren’t magic—they’re just better ways to organize your components and logic so your code stays readable and maintainable.

If you’ve made it this far, you’ve already used these patterns at some point—even if you didn’t know their names. 💡

Let me know in the comments which one you use the most—or if there’s one you want me to explain with memes and analogies next time 😄

Getting Started with Yup Validations in React: A Beginner's Guide

Elizabeth Sobiya — Sun, 28 Jul 2024 14:14:40 +0000

Hey there, fellow developers! 👋 If you've been working with forms in React, you know how tedious validation can get. But fear not! Today, we're diving into Yup, a JavaScript schema builder for value parsing and validation. Yup makes form validation in React a breeze. Let’s break it down step-by-step in a beginner-friendly way.

What is Yup?

Yup is a JavaScript library that helps you define and validate data schemas. Think of it as a tool that ensures the data your forms receive is exactly as expected. Whether you need to check if an email is valid or if a password meets certain criteria, Yup has you covered.

Why Use Yup?

Simplicity: Define complex validation logic with straightforward, readable code.
Integration: Works seamlessly with form libraries like Formik.
Flexibility: Easily create custom validation methods.

Installing Yup

First things first, let’s get Yup installed in your React project. You can do this using npm or yarn:

npm install yup

yarn add yup

Basic Usage of Yup

Let’s start with a simple example to understand how Yup works. Suppose we have a form where we need to validate an email and a password.

Step 1: Import Yup

In your React component, import Yup:

import * as Yup from 'yup';

Step 2: Define Your Schema

Next, define a validation schema for your form data. Here’s an example:

const validationSchema = Yup.object().shape({
  email: Yup.string().email('Invalid email address').required('Email is required'),
  password: Yup.string().min(6, 'Password must be at least 6 characters').required('Password is required'),
});

Step 3: Validate Data

Now, you can use this schema to validate your form data. Here’s a basic example:

const formData = {
  email: 'user@example.com',
  password: 'password123',
};

validationSchema
  .validate(formData)
  .then((valid) => {
    console.log('Validation passed:', valid);
  })
  .catch((error) => {
    console.log('Validation failed:', error);
  });

Using Yup with Formik

Formik is a popular library for managing form state in React. Yup integrates beautifully with Formik, making form validation even simpler.

Step 1: Install Formik

First, install Formik:

npm install formik

yarn add formik

Step 2: Create a Form with Formik and Yup

Here’s a complete example of how to use Formik with Yup for form validation:

import React from 'react';
import { Formik, Form, Field, ErrorMessage } from 'formik';
import * as Yup from 'yup';

const SignupSchema = Yup.object().shape({
  email: Yup.string().email('Invalid email').required('Required'),
  password: Yup.string().min(6, 'Password too short').required('Required'),
});

const MyForm = () => (
  <div>
    <h1>Signup</h1>
    <Formik
      initialValues={{ email: '', password: '' }}
      validationSchema={SignupSchema}
      onSubmit={(values) => {
        console.log(values);
      }}
    >
      {({ errors, touched }) => (
        <Form>
          <div>
            <label>Email</label>
            <Field name="email" type="email" />
            <ErrorMessage name="email" component="div" />
          </div>

          <div>
            <label>Password</label>
            <Field name="password" type="password" />
            <ErrorMessage name="password" component="div" />
          </div>

          <button type="submit">Submit</button>
        </Form>
      )}
    </Formik>
  </div>
);

export default MyForm;

In this example, we:

Define the Schema: Using Yup, we define the rules for the email and password fields.
Setup Formik: We initialize Formik with the schema and initial values.
Render the Form: We use Formik’s components to create the form, displaying validation errors using ErrorMessage.

Real-World Use Cases for Yup

1. User Registration Forms

When registering users, it’s essential to validate their input. Yup can ensure the email is valid, the password meets complexity requirements, and usernames are not empty.

const registrationSchema = Yup.object().shape({
  username: Yup.string().required('Username is required'),
  email: Yup.string().email('Invalid email').required('Email is required'),
  password: Yup.string().min(8, 'Password must be at least 8 characters').required('Password is required'),
});

2. Complex Nested Forms

Yup can handle nested objects and arrays, making it perfect for forms that require detailed and complex validation.

const profileSchema = Yup.object().shape({
  name: Yup.string().required('Name is required'),
  address: Yup.object().shape({
    street: Yup.string().required('Street is required'),
    city: Yup.string().required('City is required'),
    zip: Yup.string().required('ZIP code is required'),
  }),
});

3. Custom Validation Logic

Sometimes, you need custom validation. Yup allows you to create your own validation methods.

const customSchema = Yup.object().shape({
  username: Yup.string().test('is-john-doe', 'Username cannot be John Doe', (value) => value !== 'John Doe'),
});

Conclusion

Yup is a powerful library that makes form validation in React straightforward and efficient. By defining schemas and integrating with libraries like Formik, you can ensure that your forms are reliable and user-friendly.

I hope this guide helps you get started with Yup. Happy coding! If you have any questions or need further clarification, feel free to ask in the comments below.

Understanding DNS: The Backbone of the Internet

Elizabeth Sobiya — Sun, 09 Jun 2024 14:59:09 +0000

Understanding DNS: The Backbone of the Internet

Hey, developers! Today, we're diving into a fundamental yet often overlooked part of the internet: the Domain Name System (DNS). Whether you're a seasoned developer or just starting out, understanding DNS is crucial for navigating the web and creating robust applications. So, let's break it down in simple terms and explore why DNS is so important.

What is DNS?

Imagine you're trying to visit a friend's house. You know their name, but you need their address to get there. DNS acts like the internet's phonebook, translating human-friendly domain names (like www.example.com) into IP addresses (like 192.0.2.1) that computers use to identify each other on the network.

How Does DNS Work?

When you type a URL into your browser, several steps happen behind the scenes:

Querying the Resolver: Your computer contacts a DNS resolver, usually provided by your internet service provider (ISP), asking for the IP address of the domain.
Checking the Cache: The resolver first checks its cache to see if it already knows the IP address. If it does, it returns the address immediately.
Recursive Queries: If the address isn't in the cache, the resolver performs a series of queries. It starts by asking one of the root DNS servers, which knows where to find top-level domain (TLD) servers (like .com, .org, etc.).
TLD Servers: The root server directs the resolver to the appropriate TLD server, which in turn points to the authoritative DNS server for the specific domain.
Authoritative DNS Server: The authoritative server holds the DNS records for the domain and responds with the IP address.
Returning the IP Address: The resolver sends the IP address back to your computer, which then uses it to connect to the website's server.

Types of DNS Records

DNS records are stored in the authoritative servers and contain various pieces of information about the domain. Here are some common types:

A Record: Maps a domain to an IPv4 address.
AAAA Record: Maps a domain to an IPv6 address.
CNAME Record: Alias of one name to another (e.g., www.example.com to example.com).
MX Record: Specifies mail servers for the domain.
TXT Record: Holds text information, often used for verification and security purposes.

Why DNS Matters

1. User Experience

DNS makes it easy for users to access websites using memorable domain names instead of complex IP addresses. Imagine if you had to remember 172.217.5.110 instead of www.google.com!

2. Scalability

DNS allows websites to use multiple servers across different locations. This helps distribute the load and improves performance, making the internet scalable and efficient.

3. Security

DNS can enhance security through features like DNSSEC (Domain Name System Security Extensions), which helps protect against certain types of attacks by ensuring the responses from DNS servers are authentic.

4. Email Delivery

DNS plays a crucial role in email delivery. MX records ensure that emails are routed to the correct mail servers, helping maintain reliable communication.

Real-World Example: Setting Up a DNS Record

Let's say you've just launched a new website and want to link your domain name to your web server's IP address. Here's a simplified step-by-step guide:

Register Your Domain: Choose and register your domain name with a domain registrar.
Find Your DNS Settings: Log into your domain registrar's control panel and find the DNS settings.
Add an A Record: Create a new A record and enter your web server's IP address.
Save Changes: Save your changes and wait for them to propagate (this can take anywhere from a few minutes to 48 hours).
Test Your Setup: Open your browser and type your domain name. If everything is set up correctly, you should see your website.

Conclusion

DNS is an essential part of the internet's infrastructure, enabling us to use easy-to-remember domain names to access websites. Understanding how DNS works can help you troubleshoot issues, improve website performance, and enhance security.

So next time you type a URL into your browser, take a moment to appreciate the complex system working behind the scenes to connect you to the right website. Happy coding!

Feel free to share your thoughts and questions in the comments below. Let's keep learning together!

Unlocking Real-Time Chat with GetStream.io: A Developer's Guide 💬

Elizabeth Sobiya — Wed, 05 Jun 2024 14:09:02 +0000

In today's fast-paced digital world, real-time communication is key. Whether you're building a messaging app, a social media platform, or a customer support system, integrating a reliable and scalable chat solution is crucial. This is where GetStream.io comes into play. GetStream.io offers a robust chat API that makes it easy to add real-time chat functionality to your applications. In this post, we'll explore how to leverage GetStream.io to create seamless and engaging chat experiences.

Why Choose GetStream.io?

1. Scalability and Performance

GetStream.io is designed to handle millions of concurrent users, ensuring your chat application can scale effortlessly as your user base grows. The API is built with performance in mind, providing low-latency communication that's crucial for real-time interactions.

2. Feature-Rich Chat API

GetStream.io offers a plethora of features out-of-the-box, including:

Real-time messaging: Instant delivery of messages.
User presence: Show when users are online or offline.
Typing indicators: Notify users when someone is typing.
Message history: Persist and retrieve past conversations.
Push notifications: Keep users engaged with timely alerts.

3. Easy Integration

With well-documented SDKs and APIs for various platforms (JavaScript, iOS, Android, and more), integrating GetStream.io into your application is straightforward. You can quickly get up and running with minimal setup.

Getting Started with GetStream.io

Step 1: Sign Up and Create an App

First, you'll need to sign up for a GetStream.io account. Once you've registered, create a new app in the GetStream.io dashboard. This will provide you with the necessary API keys to connect your application to the GetStream.io service.

Step 2: Install the SDK

Next, install the GetStream.io SDK for your platform. For a React application, you can use the following command:

npm install stream-chat-react

Step 3: Initialize the Client

Initialize the GetStream.io client in your application using the API key you received:

import { StreamChat } from 'stream-chat';

const client = StreamChat.getInstance('YOUR_API_KEY');

Step 4: Connect a User

To interact with the chat service, you'll need to connect a user. You'll typically do this after a user logs into your application:

client.connectUser(
  {
    id: 'user-id',
    name: 'User Name',
    image: 'https://path-to-avatar/image.jpg',
  },
  userToken // Token generated for the user
);

Step 5: Create or Join a Channel

Now, let's create or join a chat channel:

const channel = client.channel('messaging', 'channel-id', {
  name: 'General Chat',
});

await channel.watch();

Step 6: Send and Receive Messages

With the channel set up, you can now send and receive messages:

// Sending a message
await channel.sendMessage({
  text: 'Hello, world!',
});

// Receiving messages
channel.on('message.new', (event) => {
  console.log(event.message);
});

Step 7: Implement UI Components

GetStream.io provides pre-built React components for common chat features, making it easy to create a polished chat interface. Here's a basic example using the Channel and MessageList components:

import { Chat, Channel, ChannelHeader, MessageList, MessageInput } from 'stream-chat-react';
import 'stream-chat-react/dist/css/index.css';

const App = () => (
  <Chat client={client} theme="messaging light">
    <Channel channel={channel}>
      <ChannelHeader />
      <MessageList />
      <MessageInput />
    </Channel>
  </Chat>
);

Conclusion

Integrating real-time chat into your application has never been easier thanks to GetStream.io. With its powerful API, scalability, and ease of use, you can quickly add chat functionality to your app and create engaging, real-time experiences for your users. Whether you're building a small project or a large-scale application, GetStream.io has the tools you need to succeed.

Ready to get started? Head over to GetStream.io and start building your real-time chat application today!

Feel free to share your experiences and any questions you have in the comments below. Happy coding!

Unraveling Currying in JavaScript: A Beginner's Guide with Real-World Examples

Elizabeth Sobiya — Sun, 19 May 2024 15:03:50 +0000

Hey there, fellow devs! Today, we're diving into a fascinating and powerful concept in JavaScript called currying. If you've ever wondered how to make your functions more flexible and reusable, this post is for you. We'll break down what currying is, why it's useful, and how to implement it with easy-to-follow examples. Let's get started! 🚀

What is Currying?

Currying is a functional programming technique that transforms a function with multiple arguments into a sequence of functions, each taking a single argument. In simpler terms, it means breaking down a function that takes several arguments into a series of functions that each take one argument and return another function.

Why Use Currying?

Reusability: Currying allows you to create reusable, more specific functions from general functions.
Readability: Curried functions can make your code more readable and expressive.
Partial Application: Currying makes it easy to fix some arguments of a function and generate a new function.

Currying in Action

Let's start with a simple example to illustrate currying in JavaScript.

Example 1: Basic Currying with Volume Calculation

Suppose we have a function that calculates the volume of a box given its length, width, and height:

function calculateVolume(length, width, height) {
  return length * width * height;
}

console.log(calculateVolume(3, 4, 5)); // Output: 60

Now, let's transform this function into a curried version:

function curriedVolume(length) {
  return function (width) {
    return function (height) {
      return length * width * height;
    };
  };
}

// Usage
const volumeWithLength3 = curriedVolume(3);
const volumeWithLength3AndWidth4 = volumeWithLength3(4);
console.log(volumeWithLength3AndWidth4(5)); // Output: 60

In this example, curriedVolume is a function that takes length and returns another function that takes width, which in turn returns another function that takes height and finally returns the volume.

Example 2: Real-World Example with Logger Function

Let's consider a logging function that logs messages with different log levels and timestamps:

function logMessage(timestamp, level, message) {
  console.log(`[${timestamp}] [${level}]: ${message}`);
}

// Usage
logMessage(new Date(), 'INFO', 'User logged in successfully.');

Now, let's curry this function to create more specific logging functions:

function curriedLog(timestamp) {
  return function (level) {
    return function (message) {
      console.log(`[${timestamp}] [${level}]: ${message}`);
    };
  };
}

// Usage
const logToday = curriedLog(new Date());
const logInfoToday = logToday('INFO');
logInfoToday('User logged in successfully.');

With currying, we created specific logging functions for different log levels, enhancing code reusability and readability.

Conclusion

Currying is a powerful technique in functional programming that can make your JavaScript code more modular, reusable, and expressive. By transforming functions to accept arguments one at a time, you open up new possibilities for partial application and function composition.

Give currying a try in your next project and see how it can simplify your codebase. Happy coding! 🎉

Feel free to leave your thoughts, questions, or examples of currying in the comments below. Let's learn together!

DEV Community: Elizabeth Sobiya

RAG: Giving AI Access to Your Own Data 🤖📚

So, what is RAG?

A simple example

What happens behind the scenes?

Where can you use RAG?

RAG vs Fine-tuning

One important thing 🚨

Sending Emails with Amazon SES (and Why Your Form Shouldn't Wait for Them)

Why Amazon SES?

Step 1: Verify a Sender Identity

Step 2: Get Out of the Sandbox

Step 3: Create IAM Credentials

Step 4: Send an Email from Node.js

My First (Slow) Version

Option 1: Fire and Forget

Option 2: A Real Background Job with BullMQ

Before vs After

A Few Extra Tips

Wrapping Up

I couldn't find an npm package to sort filenames into buckets, so I built one

What I found instead

So I built classify-filename

Design decisions I actually thought about

What's not in v1 (on purpose)

The stack

Try it

HawkDoc: An Open Source Notion-Style Editor Built on Lexical

Tech Stack

What Works Today

What Is Still in Progress

GitHub

Why SuperDoc Shows Only the Last Image: A DOCX Internals Investigation

The Symptom

Environment

First Check: Is DOCX Corrupt?

Deep Debugging Approach

Finding 1: Non-Standard Relationship IDs

Test performed

Finding 2: Media Filenames

Finding 3: Images Inside Tables?

Finding 4: Base64 External References

The Strongest Lead So Far (Unverified)

What Has Been Tried So Far

Current Status

Lessons From This Debugging Session

1. If it works in Word, it can still be wrong

2. Always inspect DOCX internally

3. Rendering engines behave differently

Why I'm Documenting This

Microservices: Not Just an Architecture, but a Way of Thinking

Why Microservices Exist (And When They Make Sense)

What a Microservice Really Is

How to Start Exploring Microservices Without Overwhelm

1. Start by Splitting by Responsibility

2. Build One Service Independently

3. Learn Communication Patterns

4. Embrace Observability Early

The Hidden Lesson Microservices Teach

Final Thoughts

Understanding Session Storage in Web Development: Pros, Cons, and Implementations

🧩 What Is Session Storage?

🔑 Key Highlights

🎯 Why Use Session Storage?

✅ Common Use Cases:

🛠️ Basic Implementation

🎨 Example: Saving a UI Theme

📈 Pros & Cons of Session Storage

🔐 Security Considerations

🧠 When to Use Session Storage

🧪 Best Practices

✅ Conclusion

React Design Patterns That’ll Make You a Better Dev

🧱 1. Container and Presentational Pattern

🌀 2. Higher Order Components (HOC)

🔁 3. Render Props

🧩 4. Compound Components

🧠 TL;DR

Getting Started with Yup Validations in React: A Beginner's Guide

What is Yup?

So I built `classify-filename`