DEV Community: Elizabeth Sobiya

I Paused My Open Source Project. It Wasn’t Laziness. It Was Imposter Syndrome.

Elizabeth Sobiya — Sun, 05 Apr 2026 07:24:10 +0000

I didn’t stop building because I ran out of ideas.
I didn’t stop because I was busy.
I stopped because, somewhere along the way, I started doubting myself.

And I didn’t even realize it.

The Silent Pause

I was working on my open source project with full energy in the beginning. Ideas were flowing. Architecture decisions felt exciting. Every small feature felt like progress.

Then slowly, something changed.

I started questioning everything.

“Is this architecture even correct?”
“What if I’m building this the wrong way?”
“What if someone more experienced looks at this and laughs?”
“Should I refactor everything before moving forward?”

Instead of building, I started thinking.

Instead of shipping, I started overanalyzing.

And eventually… I stopped.

Not officially. Not consciously. But the commits slowed down. Features stayed half-done. The project just sat there.

The Worst Part? I Didn’t Know It Was Imposter Syndrome

I thought I was being “careful.”

I thought I was “thinking deeply.”

I thought I was “waiting for clarity.”

But in reality, I was stuck.

Imposter syndrome doesn’t always show up as fear. Sometimes it shows up as perfectionism. Sometimes as endless research. Sometimes as “I’ll continue this once I’m more confident.”

And that “later” never comes.

The Breaking Point

After a long gap, I revisited my project.

I expected to feel the same confusion again.

But something surprising happened.

The architecture I chose?
It wasn’t perfect… but it wasn’t wrong either.

It was actually good enough.

That’s when it hit me:

I didn’t stop because the system was flawed.
I stopped because I didn’t trust myself.

The Realization That Changed Everything

I had been asking the wrong question.

Instead of:

“Is this the perfect architecture?”

I should have been asking:

“Is this good enough to move forward?”

Because here’s the truth:

You don’t validate architecture by thinking
You validate it by building
You validate it by breaking it
You validate it by iterating

No amount of overthinking will replace real usage.

The Trap of “What If I’m Wrong?”

This is where most builders get stuck.

You think:

What if I chose the wrong stack?
What if this doesn’t scale?
What if I have to rewrite everything later?

But here’s the uncomfortable truth:

You will make wrong decisions.

Everyone does.

The difference is:

Some people learn by building
Others stay stuck trying to avoid mistakes

And ironically, avoiding mistakes is the biggest mistake.

What I’m Doing Differently Now

I made a simple decision:

I’m going to build first. Judge later.

Not blindly. Not carelessly. But without freezing myself.

Here’s my current mindset:

1. Done > Perfect

Shipping something imperfect teaches more than planning something perfect.

2. Architecture is not permanent

You can refactor. You can rewrite. Nothing is locked forever.

3. Momentum matters more than correctness

A moving project improves. A paused project dies.

4. Doubt is normal

It doesn’t mean you’re wrong. It just means you care.

If You’re Building Something Right Now

And you’ve paused…

And you don’t know why…

It might not be laziness.

It might not be lack of skill.

It might just be imposter syndrome.

Ask yourself:

Did I stop because I truly don’t know what to do?
Or did I stop because I’m afraid I might be wrong?

Be honest.

One Small Shift

Instead of saying:

“I’ll continue once I’m confident”

Say:

“I’ll become confident because I continue”

That one shift changes everything.

Where I Am Now

I’m back to building.

Not because all my doubts are gone.
But because I’ve stopped waiting for them to disappear.

I don’t know if my decisions are perfect.

But I know this:

Thinking won’t answer it. Building will.

Final Thought

If you’re stuck in your project right now, this is your sign:

Go back.
Open the code.
Ship something small.

Not tomorrow. Today.

Because the only way out of imposter syndrome…

is through action.

Keep moving.

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!

CPU vs GPU: Understanding the Difference in Simple Terms

Elizabeth Sobiya — Wed, 01 May 2024 06:50:53 +0000

Introduction:
When it comes to computers, you might have heard about two important components: the CPU and the GPU. But what exactly are they, and how do they differ? In this article, we'll break down the differences between the CPU and GPU in simple terms that anyone can understand.

1. What is a CPU?

The CPU, or Central Processing Unit, is like the brain of a computer. It handles tasks such as running programs, performing calculations, and managing data. Think of it as the command center that controls everything your computer does.

2. What is a GPU?

The GPU, or Graphics Processing Unit, is a specialized processor designed to handle graphics-related tasks. It's responsible for rendering images, videos, and animations on your screen. Unlike the CPU, which is more general-purpose, the GPU is optimized for parallel processing, making it ideal for graphics-intensive applications.

3. How do they differ?

The main difference between the CPU and GPU lies in their architecture and function.
- CPU: The CPU typically has fewer cores (processing units) but higher clock speeds. It excels at sequential tasks that require a lot of processing power, such as running software applications and multitasking.
- GPU: The GPU, on the other hand, has thousands of smaller cores optimized for parallel processing. While each core may not be as powerful as a CPU core, they work together to handle tasks simultaneously, making the GPU ideal for tasks like gaming, video editing, and 3D rendering.

4. Analogies to Understand:

CPU: Think of the CPU as the manager of a company. It's responsible for making decisions, delegating tasks, and ensuring everything runs smoothly.
GPU: Imagine the GPU as a team of workers in a factory, each specialized in a specific task. Together, they can produce goods much faster than a single worker could on their own.

5. When to Use Each:

Use the CPU for general-purpose computing tasks like browsing the web, word processing, and running everyday applications.
Use the GPU for tasks that require heavy graphical processing, such as gaming, video editing, 3D modeling, and machine learning.

Conclusion:
In summary, the CPU and GPU are both essential components of a computer, each serving a different purpose. While the CPU acts as the brain, handling general computing tasks, the GPU specializes in graphics-related tasks, thanks to its parallel processing capabilities. Understanding the difference between the two can help you make informed decisions when building or upgrading your system.

Let's Dive into the World of Web Sockets: A Beginner's Guide

Elizabeth Sobiya — Thu, 25 Apr 2024 06:38:23 +0000

Hey there, fellow devs! Today, we're going to dive into an exciting journey into the world of web sockets. 🚀 Have you ever wondered how real-time communication between your browser and a server happens? Well, that's where web sockets come into play!

What are Web Sockets?

Think of web sockets as a two-way communication channel between a client (your browser) and a server. Unlike traditional HTTP requests, which are unidirectional (client sends a request, server responds), web sockets allow for full-duplex communication, meaning both the client and the server can send messages to each other simultaneously.

Why Do We Need Web Sockets?

Imagine you're building a chat application, and you want messages to appear instantly for all users without needing to refresh the page. Or perhaps you're working on a real-time multiplayer game where players need to see each other's moves in real-time. This is where web sockets shine! They provide a low-latency, high-performance solution for real-time communication.

How Do Web Sockets Work?

Okay, let's break it down into simple steps:

Opening the Connection: First, the client (browser) initiates a connection to the server by sending a special HTTP request called a WebSocket handshake request.
Establishing the Connection: Once the server receives the handshake request, it responds with a WebSocket handshake response, indicating that the connection has been established.
Bi-Directional Communication: Now that the connection is open, both the client and the server can send messages to each other whenever they want, without the overhead of HTTP headers.
Closing the Connection: When either the client or the server decides to terminate the connection, they can send a close message, and the connection will be gracefully closed.

Hands-On Example: Let's Build a Real-Time Chat App!

To help solidify our understanding, let's build a simple real-time chat application using web sockets. Here's what we'll need:

Frontend: HTML, CSS, JavaScript (or your favorite frontend framework like React)
Backend: Node.js (or any server-side technology of your choice)

We'll set up a WebSocket server on the backend and create a client-side application that connects to the server and sends/receives messages in real-time. Along the way, we'll learn about handling WebSocket events, broadcasting messages to multiple clients, and more!

Conclusion:

And there you have it, folks! We've scratched the surface of web sockets and explored their incredible capabilities for real-time communication on the web. From chat applications to multiplayer games, web sockets open up a world of possibilities for building interactive, engaging web experiences. So, what are you waiting for? Start experimenting with web sockets in your projects and see where they take you!

Happy coding! 🎉