DEV Community: Wale Bashir

Using Bitmasks for Role-Based Permissions: Stop Querying Your Database

Wale Bashir — Tue, 06 Jan 2026 23:17:04 +0000

In Part 1, I showed you how bitmasks work - the maths, the operators, the theory. Now let's actually use them.

If you're building an app with user permissions (and you probably are), you're likely doing one of two things:

Querying your database on every request: SELECT permissions FROM users WHERE id = ?
Storing permissions in your JWT and hoping they don't go stale

Both have problems. Let me show you a third way. 🛠️

The Problem with Database Queries

Here's what most auth middleware looks like:

// Traditional permission check
async function requirePermission(permissionName) {
  return async (req, res, next) => {
    const userId = req.user.id;

    // Hit the database
    const userPerms = await db.query(
      'SELECT permission FROM user_permissions WHERE user_id = ? AND permission = ?',
      [userId, permissionName]
    );

    if (userPerms.length === 0) {
      return res.status(403).json({ error: 'Forbidden' });
    }

    next();
  };
}

// Every protected route does this
app.delete('/posts/:id', requirePermission('delete_posts'), async (req, res) => {
  // Delete the post
});

What's wrong with this?

Every single request hits your database. If your API handles 10,000 requests per second, that's 10,000 database queries just for permission checks. Your database becomes a bottleneck.

You could cache the results, but then you've got cache invalidation problems. You could store permissions in Redis, but now you're adding network latency and another service to manage.

The Problem with JWTs

Alternative approach - store permissions in the JWT:

// Sign JWT with permissions
const token = jwt.sign({
  userId: user.id,
  permissions: ['create_posts', 'edit_posts', 'delete_posts']
}, SECRET);

// Check permissions from token
function requirePermission(permissionName) {
  return (req, res, next) => {
    if (!req.user.permissions.includes(permissionName)) {
      return res.status(403).json({ error: 'Forbidden' });
    }
    next();
  };
}

What's wrong with this?

JWTs can't be invalidated. If you revoke a user's permissions, they still have a valid token until it expires. You're trading database queries for stale data.

Also, .includes() on an array is O(n) - it checks each element until it finds a match. With 10+ permissions, that's 10+ comparisons per check.

The Bitmask Approach

Instead of storing permission strings or querying a database, store permissions as a single number.

Define your permissions:

// permissions.js
const PERMISSIONS = {
  CREATE_POSTS:     1 << 0,  // 1
  EDIT_OWN_POSTS:   1 << 1,  // 2
  EDIT_ALL_POSTS:   1 << 2,  // 4
  DELETE_OWN_POSTS: 1 << 3,  // 8
  DELETE_ALL_POSTS: 1 << 4,  // 16
  MANAGE_USERS:     1 << 5,  // 32
  VIEW_ANALYTICS:   1 << 6,  // 64
  EXPORT_DATA:      1 << 7,  // 128
};

// Helper to check permissions
function hasPermission(userPerms, requiredPerm) {
  return (userPerms & requiredPerm) !== 0;
}

// Helper to add permissions
function addPermission(userPerms, newPerm) {
  return userPerms | newPerm;
}

// Helper to remove permissions
function removePermission(userPerms, perm) {
  return userPerms & ~perm;
}

module.exports = { PERMISSIONS, hasPermission, addPermission, removePermission };

Why 1 << 0, 1 << 1, etc?

The << operator is a bit shift. 1 << 0 means "shift the number 1 left by 0 positions" which equals 1. 1 << 1 means "shift 1 left by 1 position" which equals 2. 1 << 2 equals 4, and so on.

It's just a cleaner way to write powers of 2. You could write 1, 2, 4, 8, 16... but 1 << 0, 1 << 1, 1 << 2... makes the pattern obvious and prevents typos.

Storing Permissions in Your Database

Instead of a junction table with rows for each permission:

-- Old way: Many rows per user
CREATE TABLE user_permissions (
  user_id INT,
  permission VARCHAR(50)
);

-- User with 5 permissions = 5 rows
-- 10M users with 5 permissions = 50M rows

Store one integer per user:

-- New way: One column
CREATE TABLE users (
  id INT PRIMARY KEY,
  email VARCHAR(255),
  password_hash VARCHAR(255),
  permissions INT DEFAULT 0
);

-- User with 5 permissions = still 1 row
-- 10M users = 10M rows (not 50M)

Creating a user with permissions:

const { PERMISSIONS, addPermission } = require('./permissions');

// Basic user: can create and edit own posts
let userPerms = 0;
userPerms = addPermission(userPerms, PERMISSIONS.CREATE_POSTS);
userPerms = addPermission(userPerms, PERMISSIONS.EDIT_OWN_POSTS);

// Or do it in one line
const userPerms = PERMISSIONS.CREATE_POSTS | PERMISSIONS.EDIT_OWN_POSTS;

await db.query(
  'INSERT INTO users (email, password_hash, permissions) VALUES (?, ?, ?)',
  [email, passwordHash, userPerms]
);

Updating permissions:

// Promote user to moderator
const currentPerms = user.permissions;
const newPerms = currentPerms | PERMISSIONS.DELETE_ALL_POSTS | PERMISSIONS.EDIT_ALL_POSTS;

await db.query('UPDATE users SET permissions = ? WHERE id = ?', [newPerms, userId]);

Middleware Implementation

Here's the auth middleware:

// middleware/auth.js
const { PERMISSIONS, hasPermission } = require('../permissions');

/**
 * Require specific permission
 * @param {number} requiredPermission - Permission bitmask
 */
function requirePermission(requiredPermission) {
  return (req, res, next) => {
    // Assume req.user was set by your auth middleware
    if (!req.user) {
      return res.status(401).json({ error: 'Unauthorized' });
    }

    if (!hasPermission(req.user.permissions, requiredPermission)) {
      return res.status(403).json({ error: 'Forbidden' });
    }

    next();
  };
}

/**
 * Require ALL specified permissions
 * @param {...number} requiredPermissions - Multiple permission bitmasks
 */
function requireAllPermissions(...requiredPermissions) {
  return (req, res, next) => {
    if (!req.user) {
      return res.status(401).json({ error: 'Unauthorized' });
    }

    // Combine all required permissions with OR
    const combined = requiredPermissions.reduce((acc, perm) => acc | perm, 0);

    // Check if user has ALL of them
    if ((req.user.permissions & combined) !== combined) {
      return res.status(403).json({ error: 'Forbidden' });
    }

    next();
  };
}

/**
 * Require ANY of the specified permissions
 * @param {...number} requiredPermissions - Multiple permission bitmasks
 */
function requireAnyPermission(...requiredPermissions) {
  return (req, res, next) => {
    if (!req.user) {
      return res.status(401).json({ error: 'Unauthorized' });
    }

    const hasAny = requiredPermissions.some(perm => 
      hasPermission(req.user.permissions, perm)
    );

    if (!hasAny) {
      return res.status(403).json({ error: 'Forbidden' });
    }

    next();
  };
}

module.exports = { requirePermission, requireAllPermissions, requireAnyPermission };

Using it in routes:

const { PERMISSIONS } = require('./permissions');
const { requirePermission, requireAllPermissions } = require('./middleware/auth');

// Simple permission check
app.delete('/posts/:id', 
  requirePermission(PERMISSIONS.DELETE_ALL_POSTS),
  async (req, res) => {
    // Delete the post
  }
);

// Require multiple permissions
app.post('/analytics/export',
  requireAllPermissions(PERMISSIONS.VIEW_ANALYTICS, PERMISSIONS.EXPORT_DATA),
  async (req, res) => {
    // Export analytics data
  }
);

Performance: Real Numbers

Right, so I keep saying "bitmasks are faster." Let me prove it.

I ran benchmarks comparing three approaches with 1 million operations each:

Array .includes(): permissions.includes('delete_posts')
Bitmask check: permissions & DELETE_POSTS

Results:

Approach	Ops/Second	Speedup
Array .includes()	2,093,325	baseline
Bitmask check	3,012,325	1.5x faster

The bitmask approach is 50% faster on average. In the best case, it was 2.28x faster.

Why? Because & is a single CPU instruction. Array .includes() has to loop through each element, comparing strings until it finds a match (or doesn't).

Memory: The Real Win

Here's where bitmasks really shine. I tested storing 100,000 user objects with permissions:

Memory usage:

Approach	Total Memory	Per Object	Savings
Multiple booleans	12.05 MB	126.34 bytes	baseline
Array of strings	11.58 MB	121.43 bytes	4%
Single bitmask	6.47 MB	67.79 bytes	46.3%

The bitmask approach uses 46.3% less memory than multiple boolean properties. That's 58.55 bytes saved per object.

Scale this:

1 million users: ~55.8 MB saved
10 million users: ~558 MB saved
100 million users: ~5.58 GB saved

Your database thanks you. Your cloud bill thanks you. And cloud providers now have us both on their hit list.

Full benchmark results and reproducible tests

Combining with Your Auth Strategy

You're probably thinking: "But I still need to fetch the user from somewhere."

You do. Bitmasks don't eliminate authentication - they just make authorization faster. Authentication is not authorization.

Combining with Your Auth Strategy

A quick note on storing permissions in JWTs: This is somewhat controversial in the auth community. Some argue JWTs should only carry identity, not authorization data. Others (including me) find it acceptable for high-level roles stored as bitmasks in short-lived tokens.

The compromise:

✅ Store user roles/permissions as a bitmask (keeps token small)
✅ Keep access tokens very short-lived (5-15 min max)
✅ Use refresh tokens to get updated permissions
❌ Don't store fine-grained resource permissions (which files can they access, etc.)
❌ Don't rely on this for highly dynamic permissions

For complex authorization (resource-level permissions, dynamic policies), look into policy engines like Ory or Zanzibar-style systems.

Right, so with that context...

Here's how I use them with the hybrid auth approach from my JWT vs Sessions article:

// 1. Short-lived access token (15 minutes)
const accessToken = jwt.sign({
  userId: user.id,
  permissions: user.permissions  // <- Single integer
}, ACCESS_SECRET, { expiresIn: '15m' });

// 2. Long-lived refresh token (30 days) in database
const refreshToken = generateSecureToken();
await db.query(
  'INSERT INTO refresh_tokens (token, user_id, expires_at) VALUES (?, ?, ?)',
  [refreshToken, user.id, Date.now() + 30 * 24 * 60 * 60 * 1000]
);

Permission check middleware:

function requirePermission(requiredPerm) {
  return async (req, res, next) => {
    // Verify JWT (fast - no database)
    const decoded = jwt.verify(req.headers.authorization, ACCESS_SECRET);

    // Check permission (fast - bitwise operation)
    if ((decoded.permissions & requiredPerm) === 0) {
      return res.status(403).json({ error: 'Forbidden' });
    }

    req.user = decoded;
    next();
  };
}

When permissions change:

// Revoke permission
const newPerms = user.permissions & ~PERMISSIONS.DELETE_ALL_POSTS;
await db.query('UPDATE users SET permissions = ? WHERE id = ?', [newPerms, user.id]);

// Invalidate their refresh token (forces new access token on next refresh)
await db.query('DELETE FROM refresh_tokens WHERE user_id = ?', [user.id]);

Next time they refresh, they get a new access token with updated permissions. Worst case: they have 15 minutes with old permissions. That's acceptable for most apps.

Why Bitmask in JWT?

Here's why storing permissions as a bitmask in your JWT makes sense:

Token size comparison:

// String array approach
{
  "userId": 123,
  "permissions": ["create_posts", "edit_own_posts", "edit_all_posts", "delete_own_posts"]
}
// ~180 bytes

// Bitmask approach  
{
  "userId": 123,
  "permissions": 15
}
// ~50 bytes - 72% smaller

This matters because HTTP headers have an 8KB limit. Every request carries your JWT. Smaller tokens = less bandwidth, faster sign/verify operations.

Role-Based Permissions

You can define roles as combinations of permissions:

// roles.js
const { PERMISSIONS } = require('./permissions');

const ROLES = {
  VIEWER: PERMISSIONS.CREATE_POSTS | 
          PERMISSIONS.EDIT_OWN_POSTS,

  EDITOR: PERMISSIONS.CREATE_POSTS | 
          PERMISSIONS.EDIT_OWN_POSTS | 
          PERMISSIONS.EDIT_ALL_POSTS,

  MODERATOR: PERMISSIONS.CREATE_POSTS | 
             PERMISSIONS.EDIT_OWN_POSTS | 
             PERMISSIONS.EDIT_ALL_POSTS | 
             PERMISSIONS.DELETE_OWN_POSTS | 
             PERMISSIONS.DELETE_ALL_POSTS,

  ADMIN: PERMISSIONS.CREATE_POSTS | 
         PERMISSIONS.EDIT_OWN_POSTS | 
         PERMISSIONS.EDIT_ALL_POSTS | 
         PERMISSIONS.DELETE_OWN_POSTS | 
         PERMISSIONS.DELETE_ALL_POSTS | 
         PERMISSIONS.MANAGE_USERS | 
         PERMISSIONS.VIEW_ANALYTICS | 
         PERMISSIONS.EXPORT_DATA,
};

module.exports = { ROLES };

Assigning roles:

const { ROLES } = require('./roles');

// Make someone a moderator
await db.query('UPDATE users SET permissions = ? WHERE id = ?', [ROLES.MODERATOR, userId]);

You can still add individual permissions on top:

// Moderator + ability to export data
const customPerms = ROLES.MODERATOR | PERMISSIONS.EXPORT_DATA;

Or remove specific permissions:

// Admin without ability to manage users
const customPerms = ROLES.ADMIN & ~PERMISSIONS.MANAGE_USERS;

Security Considerations (The Important Bit)

Bitmasks are fast, but speed doesn't matter if your auth system is insecure. Here's what you need to know:

Permission Staleness Window

When you store permissions in a JWT, they become stale the moment you change them server-side.

// User has admin privileges
const token = jwt.sign({ permissions: ROLES.ADMIN }, SECRET, { expiresIn: '15m' });

// 5 minutes later, you revoke their admin access in the database
await db.query('UPDATE users SET permissions = ? WHERE id = ?', [ROLES.VIEWER, userId]);

// But their token still says they're admin for another 10 minutes

Mitigation: Keep access tokens short-lived (5-15 minutes). Use refresh tokens to get updated permissions.

Token Revocation is Impossible

You cannot revoke a JWT before it expires. This is a fundamental limitation of stateless tokens.

If a user's account is compromised, the attacker has access until the token expires. Your options:

Short-lived tokens (5-15 min) - limits damage window
Refresh token invalidation - revoke the refresh token, force new login on next refresh
Token blacklist (defeats the "stateless" purpose, but sometimes necessary)

Bit Position Management

Once you assign a permission to a bit position, never reuse that position for a different permission.

// Version 1
const CAN_DELETE = 1 << 4;  // Bit 4

// Version 2 (WRONG - reusing bit 4)
const CAN_EXPORT = 1 << 4;  // Now bit 4 means something else

// Old tokens with bit 4 set now have wrong permission

Best practice: Document bit positions, version your permission schema, never reuse.

Principle of Least Privilege

Give users the minimum permissions they need. Don't create a "SUPER_ADMIN" role with all bits set unless absolutely necessary.

// Bad: Kitchen sink role
const POWER_USER = ROLES.ADMIN | PERMISSIONS.EXPORT_DATA | PERMISSIONS.DELETE_ALL | ...;

// Good: Specific role for specific job
const MODERATOR = PERMISSIONS.DELETE_OWN_POSTS | PERMISSIONS.EDIT_ALL_POSTS;

Audit Logging

Log permission checks, especially failures:

function requirePermission(requiredPerm) {
  return (req, res, next) => {
    if (!hasPermission(req.user.permissions, requiredPerm)) {
      // Log the denial
      logger.warn('Permission denied', {
        userId: req.user.id,
        required: debugPermissions(requiredPerm),
        actual: debugPermissions(req.user.permissions),
        endpoint: req.path
      });

      return res.status(403).json({ error: 'Forbidden' });
    }
    next();
  };
}

This helps you detect:

Privilege escalation attempts
Permission misconfigurations
Unusual access patterns

Debugging Helper Functions

Remember how I said debugging is harder because you see numbers instead of permission names? Here's the fix:

// permissions.js (add this)

/**
 * Convert permission bitmask to readable array
 * @param {number} perms - Permission bitmask
 * @returns {string[]} Array of permission names
 */
function debugPermissions(perms) {
  const enabled = [];
  for (const [name, value] of Object.entries(PERMISSIONS)) {
    if (perms & value) {
      enabled.push(name);
    }
  }
  return enabled;
}

/**
 * Convert permission bitmask to readable string
 * @param {number} perms - Permission bitmask
 * @returns {string} Comma-separated permission names
 */
function formatPermissions(perms) {
  const enabled = debugPermissions(perms);
  return enabled.length > 0 ? enabled.join(', ') : 'No permissions';
}

module.exports = { 
  PERMISSIONS, 
  hasPermission, 
  addPermission, 
  removePermission,
  debugPermissions,
  formatPermissions
};

Usage:

const user = await db.query('SELECT * FROM users WHERE id = ?', [userId]);

console.log('User permissions:', user.permissions); 
// Output: 87

console.log('Permissions:', debugPermissions(user.permissions));
// Output: ['CREATE_POSTS', 'EDIT_OWN_POSTS', 'DELETE_OWN_POSTS', 'MANAGE_USERS']

console.log(formatPermissions(user.permissions));
// Output: CREATE_POSTS, EDIT_OWN_POSTS, DELETE_OWN_POSTS, MANAGE_USERS

This makes development and debugging much easier whilst keeping production code fast.

The Limitations (The Honest Bit)

1. Maximum 32 permissions (or 53 safely)

JavaScript's bitwise operators work on 32-bit integers. If you use regular numbers (not bitwise ops), you can safely use up to 53 bits (JavaScript's safe integer limit).

Need more? Use BigInt:

const PERMISSIONS = {
  PERMISSION_1: 1n << 0n,
  PERMISSION_2: 1n << 1n,
  // ... up to 64 or more
  PERMISSION_65: 1n << 64n,
};

// Check permission (same syntax, just with BigInt)
if (userPerms & PERMISSIONS.PERMISSION_65) {
  // Has permission
}

Or use multiple permission integers:

const user = {
  permissions1: 0,  // Permissions 1-32
  permissions2: 0,  // Permissions 33-64
};

2. Less readable in database

SELECT id, email, permissions FROM users;
-- Returns: 1, "user@example.com", 87
-- What does 87 mean?

Use the helper functions during development. In production, you don't look at raw permission numbers anyway - you check them programmatically.

3. Can't add permissions dynamically

If users can create custom permissions at runtime, bitmasks won't work. You'd need a different approach (back to the junction table).

This is fine for most apps. Your permission set is usually fixed: read, write, delete, admin, etc.

4. Migration complexity

Migrating from strings to bitmasks requires:

Mapping old permission strings to bit positions
Converting existing data
Running both systems during transition

Not impossible, but it's effort. Plan accordingly.

When to Actually Use This

Use bitmasks when:

You have a fixed set of permissions (< 32, or < 53 if using regular numbers)
Permission checks happen frequently (thousands per request)
Memory efficiency matters (millions of users)
You want faster authorization without adding Redis/caching complexity

Don't use bitmasks when:

Permissions are dynamic or user-defined
You have > 53 permissions and don't want BigInt complexity
Your team values readability over performance
You're not hitting performance bottlenecks
Permissions change frequently (multiple times per day per user)
You need fine-grained resource-level access (which specific files/folders)
You need hierarchical permissions (managers inherit team member permissions)
You need complex conditional logic (can delete IF they created it AND it's < 24hrs old)

For these scenarios, consider:

Database-backed RBAC with good caching
Attribute-Based Access Control (ABAC) for complex conditions
Policy engines like Ory or Casbin
Zanzibar-style systems for Google-scale authorization

Measure first. If your current approach isn't slow, don't optimize it.

What You've Learned

You now know:

How to store permissions as a single integer
How to check permissions with bitwise operations (50% faster than arrays)
How to save 46% memory compared to multiple booleans
How to build auth middleware using bitmasks
How to combine this with JWT/session strategies
When this approach makes sense (and when it doesn't)

This is what Unix has been doing since the 1970s (chmod 755). This is what game engines use for entity states. This is what network protocols use for flags.

It's not new. It's just... uncommon.

Benchmarks and code: github.com/digitaldrreamer/stat-tests/tree/main/bitmask-benchmarks

Happy Hacking!

Originally published on https://drreamer.digital/blog/using-bitmasks-for-role-based-permissions

Bitmask Operations: The Math You Skipped (And Why It Matters)

Wale Bashir — Tue, 06 Jan 2026 23:13:34 +0000

Your computer can check a boolean flag in a single CPU instruction. You're probably doing three memory lookups and a comparison.

If you're here, some linux-torvalds-2.0-like engineer probably said "just use bitmasks" and you nodded along whilst screaming internally. I did that for years. Or maybe you just saw this post in your feed. Either way, lucky you 🙃.

This isn't magic. It's just a clever trick with numbers.

How Computers Actually Count

Right, so you know how we count with ten digits (0-9)?

0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12...

Computers only have two digits: 0 and 1. Because electricity is either OFF (0) or ON (1).

So they count like this:

0, 1, 10, 11, 100, 101, 110, 111, 1000...

This is called "binary" (base 2) instead of "decimal" (base 10).

What Those 1s and 0s Mean

In our decimal system, each position is worth 10x more than the one to its right:

3 2 5
↑ ↑ ↑
│ │ └─ 5 ones (5 × 1)
│ └─── 2 tens (2 × 10)
└───── 3 hundreds (3 × 100)

325 = 300 + 20 + 5

In binary, each position is worth 2x more:

Position:  3   2   1   0
Value:     8   4   2   1

Let's look at the number 5 in binary: 0101

See? Position 2 is ON (1), worth 4. Position 0 is ON (1), worth 1. That's 4 + 1 = 5.

The Lightbulb Moment

Think of those same four positions as lightbulbs:

[  ] [💡] [  ] [💡]
 OFF  ON  OFF  ON
 0    1    0    1  = 5

You could describe this as "Bulb 1 is OFF, Bulb 2 is ON, Bulb 3 is OFF, Bulb 4 is ON."

Or you could just write: 5

This is what bitmasks are. Each position (bit) represents a yes/no answer. The entire pattern is stored as a single number.

A Real Example: Feature Flags

You're building an app. Users can toggle features:

Dark Mode
Analytics
Notifications
Beta Access

Traditional way:

const userSettings = {
  darkMode: true,
  analytics: false,
  notifications: true,
  betaAccess: false
};

This works. But it takes ~100 bytes of memory (property names, object overhead, etc).

Bitmask way:

Assign each feature a position:

const DARK_MODE      = 1;  // 0001 - Position 0
const ANALYTICS      = 2;  // 0010 - Position 1
const NOTIFICATIONS  = 4;  // 0100 - Position 2
const BETA_ACCESS    = 8;  // 1000 - Position 3

Why those numbers? Because in binary:

1 is 0001 (only position 0 is ON)
2 is 0010 (only position 1 is ON)
4 is 0100 (only position 2 is ON)
8 is 1000 (only position 3 is ON)

A user with Dark Mode and Notifications enabled:

const userSettings = 5; // Binary: 0101

One number. Four settings. 1 byte instead of 100.

The Four Operations

Now let's learn how to actually manipulate these numbers. JavaScript (and most programming languages) has special operators for working with bits - they're called bitwise operators. You've probably seen them before: |, &, ~, ^.

They look weird, like those hieroglyphics plastered everywhere in Assassin's Creed, but each one does something specific to the binary digits. Let me show you.

1. Adding Features (OR: `|`)

Turn multiple features ON:

let settings = 0; // 0000

settings = DARK_MODE | NOTIFICATIONS;
// Result: 5 (Binary: 0101)

The | operator looks at each position. If EITHER number has a 1, the result has a 1.

2. Checking Features (AND: `&`)

Test if a feature is enabled:

const settings = 5; // 0101

if (settings & DARK_MODE) {
  console.log('Dark mode enabled');
}
// 0101 & 0001 = 0001 ✓

if (settings & ANALYTICS) {
  console.log('Analytics enabled');
}
// 0101 & 0010 = 0000 ✗

The & operator returns 1 only if BOTH positions have a 1. If the result is non-zero, the feature is ON.

3. Removing Features (AND + NOT: `& ~`)

Turn OFF a specific feature:

let settings = 5; // 0101

settings = settings & ~DARK_MODE;
// Result: 4 (0100)

The ~ operator flips all bits (0→1, 1→0). Then & keeps everything except the Dark Mode position.

4. Toggling Features (XOR: `^`)

Flip a feature (ON→OFF or OFF→ON):

let settings = 5; // Analytics OFF

settings = settings ^ ANALYTICS;
// Analytics now ON

settings = settings ^ ANALYTICS;
// Analytics now OFF

The ^ operator flips the bit. Perfect for toggle switches.

Why This Can Be Better

Memory: When storing many flags, one integer beats an object. My benchmarks show:

10 million users with 4 flags: ~64 MB (bitmask) vs ~1.2 GB (boolean properties)
46% less memory per object

Speed: Bitmask checks are 1.5x faster than array .includes() in benchmarks. Modern compilers optimize both approaches, but avoiding property lookups and reducing memory bandwidth can matter at scale - especially at thousands of operations per second.

Atomic: A single integer assignment is atomic. Multiple property updates aren't.

Important context: The performance difference depends on your architecture, compiler, and usage patterns. Always measure in your specific case before optimizing.

Full benchmarks and code

Real Problems This Solves

Network Protocols

TCP sends flags (SYN, ACK, FIN, RST) with every packet. Instead of { syn: true, ack: false, ... } (dozens of bytes), it sends one byte: 10010001.

When you're sending billions of packets, every byte counts.

Permission Systems

Checking user.perms & CAN_DELETE is faster than querying a database or doing multiple property lookups, especially at thousands of requests per second.

We'll build this properly in Part 2.

The Limitations

1. Limited by integer size

JavaScript bitwise ops: 32 bits max. Need more? Use multiple numbers or BigInt.

2. Less readable

if (flags & 0x04)           // ???
if (settings.notifications) // Clear

Always use named constants.

3. Can't add flags dynamically

settings[userDefinedFlag] = true;  // Works with objects
settings & userDefinedFlag;        // Doesn't work

Bitmasks need pre-defined positions.

4. Debugging is harder

console.log(settings); // 23
// What does 23 mean?

Write helper functions to decode during development.

When to Actually Use This

Use bitmasks when:

Checking flags in hot code paths (thousands of times/sec)
5+ related yes/no values
Memory genuinely matters (millions of records, embedded systems)
You need atomic flag updates

Don't use bitmasks when:

2-3 flags total (overhead isn't worth it)
Readability matters more than performance
Flags are dynamic/user-defined
You're not hitting actual performance bottlenecks

Remember: Modern compilers are smart. Measure before optimizing.

PS: I know these operators feel unnatural at first. So did || for default values, arrow functions, and destructuring. Once you're over the learning curve, they become second nature - unless your team's style guide bans them, in which case... well, that's a different conversation. 😅

What's Next

You now understand:

Binary (powers of 2)
Packing multiple yes/no values into one number
The four operations: OR, AND, AND+NOT, XOR
When it helps (and when it doesn't)

In Part 2, I'll show you how to build role-based permissions using bitmasks. We'll check user permissions with bitwise ops instead of database queries.

You'll see why Unix uses chmod 755, why game engines store player state this way, and when your auth system should too.

Happy Hacking!

Originally published on https://drreamer.digital/blog/bitmask-operations-the-math-you-skipped

Session Tokens vs JWTs: The False Dichotomy

Wale Bashir — Fri, 02 Jan 2026 10:56:38 +0000

I've been building auth systems for a while now, and there's this debate that keeps coming up: JWTs or sessions? Every tutorial forces you to pick one, then spends 2000 words explaining why the other one is terrible.

Here's the thing though: this entire debate is pointless. You don't have to choose. There's a third option that gives you the best of both, and honestly, it's simpler than either approach on its own.

Let me show you what I mean.

The JWT-Only Approach (and Why It's Dangerous)

Most tutorials will show you something like this:

// User logs in
const jwt = sign(
  { userId: user.id, role: user.role }, 
  SECRET, 
  { expiresIn: '7d' }
);
setCookie('token', jwt);

// Every request
const payload = verify(req.cookies.token, SECRET);
// Done. No database hit.

This looks clean. No database queries. Any server can verify the token. Your auth is "stateless" (whatever that means).

But here's what actually happens in practice:

A user gets fired. The admin deletes their account from the database. Their JWT? Still valid for the next 7 days. They still have full access to your system whilst everyone thinks they're locked out.

Or this: You change someone's role from Admin to User. The JWT still says role: 'admin' for the next 7 days. The database is updated, but the token doesn't care.

Or my personal favourite: A user's laptop gets stolen and they want to log out of all devices. With JWTs alone, you can't do it. The tokens are out there in the wild, and they're valid until they expire. There's no "logout all sessions" button that actually works.

What you get:

Fast (0.97ms average response time, no database lookups)
High throughput (5,527 requests/sec under load)
But you can't revoke tokens
And the data goes stale immediately

At small scale, maybe you don't care. But the moment you need to actually control who has access to your system? JWTs alone are a disaster.

The Session-Only Approach (and Why It Doesn't Scale)

Right, so JWTs are dangerous. Let's just use sessions:

// User logs in
const sessionId = randomBytes(32).toString('hex');
await db.session.create({
  id: sessionId,
  userId: user.id,
  expiresAt: new Date(Date.now() + 7 * 24 * 60 * 60 * 1000)
});
setCookie('sessionId', sessionId);

// Every request - database lookup
const session = await db.session.findUnique({
  where: { id: req.cookies.sessionId },
  include: { user: true }
});

if (!session || session.expiresAt < new Date()) {
  return res.status(401).json({ error: 'Invalid session' });
}

This fixes all the JWT problems. Delete the session? User is logged out immediately. Change their role? Next request sees it. Perfect.

Here's the cost: every single request hits your database. Not most requests. Not some requests. Every request.

Your app makes 50 API calls to load the dashboard? That's 50 database queries just for auth checks. Before you even get to your actual business logic, you've already hammered your database 50 times.

What you get:

Instant revocation (delete from DB, user is logged out)
Fresh data (always reflects current state)
But every request costs 1.52ms in database latency
And your database becomes the bottleneck for everything

I tested this. At 4,561 requests per second, the session-only approach was hitting the database with 4,561 queries per second just for auth checks. That's before your actual business logic runs. Your database will melt.

This approach works fine at small scale. But the moment you hit any real traffic, you've just made authentication the most expensive operation in your entire system.

Here's what's actually happening under the hood with each approach:

See the problem? JWT-only never touches the database (fast but dangerous). Session-only hits it every time (safe but slow). The hybrid approach only hits the database when the access token expires—about 1% of requests.

A Quick Note on Redis

If you're thinking "just use Redis instead of PostgreSQL for sessions," you're right—that's faster. Redis lookups are ~2-3ms instead of 5-20ms for PostgreSQL. But you're still hitting external infrastructure on every request, which is the core issue.

The hybrid approach below gives you JWT-speed (0.5ms, no network call) for 99% of requests, and only checks storage (Redis or PostgreSQL) when tokens expire. That's the key difference: frequency, not just speed.

Why "JWTs Are for Microservices" Is Bullshit

Before I show you the solution, let's address the argument I always hear:

"But microservices! They don't share a database! JWTs let each service validate tokens independently!"

Look at your microservices architecture. Actually look at it.

User Service     → PostgreSQL
Order Service    → PostgreSQL  
Payment Service  → PostgreSQL
Product Service  → PostgreSQL

Your services already share:

The database (or database cluster)
Redis for caching
Message queues
Logging infrastructure
Monitoring tools

So why exactly can't auth share Redis? If you've got Redis for caching (which you do), session validation takes 2-3ms. That's fast, sure. But the hybrid approach below gives you 0.5ms response times by skipping even that network call 99% of the time.

The real reason people use JWTs? They read one article that said "JWTs are stateless and scalable" and never questioned it. Bottom line is: if you have Redis, the "distributed systems need JWTs" argument falls apart.

The Solution: Short Access Tokens + Long Refresh Tokens

Here's what I actually use: short-lived access tokens (JWTs) backed by long-lived refresh tokens (sessions in the database).

It's not JWT vs Sessions. It's JWT and Sessions, each doing what they're good at.

Here's how it works:

// User logs in
async function login(email, password) {
  const user = await authenticateUser(email, password);

  // Refresh token - stored in database (lasts 30 days)
  const refreshToken = randomBytes(32).toString('hex');
  await db.session.create({
    userId: user.id,
    refreshToken: refreshToken,
    expiresAt: new Date(Date.now() + 30 * 24 * 60 * 60 * 1000)
  });

  // Access token - NOT stored, just a JWT (lasts 15 minutes)
  const accessToken = jwt.sign(
    { userId: user.id, role: user.role },
    SECRET,
    { expiresIn: '15m' }
  );

  res.cookie('accessToken', accessToken, { httpOnly: true });
  res.cookie('refreshToken', refreshToken, { httpOnly: true });
}

Let me show you how this flows in practice:

The key insight: most requests take the fast path (top). Only when the access token expires do you hit the database to validate the refresh token and issue a fresh access token with updated user data.

Now here's what the protect middleware looks like:

async function protect(req, res, next) {
  const { accessToken, refreshToken } = req.cookies;

  try {
    // Fast path - verify access token (no database)
    const payload = jwt.verify(accessToken, SECRET);
    req.userId = payload.userId;
    return next();

  } catch (err) {
    // Access token expired - check refresh token (database lookup)
    if (!refreshToken) {
      return res.status(401).json({ error: 'Not authenticated' });
    }

    const session = await db.session.findUnique({
      where: { refreshToken },
      include: { user: true }
    });

    if (!session || session.expiresAt < new Date()) {
      return res.status(401).json({ error: 'Session expired' });
    }

    // Issue new access token
    const newAccessToken = jwt.sign(
      { userId: session.userId, role: session.user.role },
      SECRET,
      { expiresIn: '15m' }
    );

    res.cookie('accessToken', newAccessToken, { httpOnly: true });
    req.userId = session.userId;
    return next();
  }
}

What this gives you:

99% of requests verify the access token and skip the database entirely. Fast.

1% of requests (when the 15-minute token expires) hit the database to validate the refresh token and issue a new access token. Controlled.

User gets fired? Delete their refresh token. Their current access token works for max 15 minutes, then they're locked out. That's not instant, but it's way better than 7 days.

Role changed? When the access token expires (15 minutes max), the new one includes fresh data from the database.

Want to log out all devices? Delete all refresh tokens for that user. Every device loses access within 15 minutes.

What About High-Security Scenarios?

For most applications, the 15-minute window is fine. But if you're building something where instant revocation is critical (banking, healthcare, admin panels), you have options:

Option 1: Shorter access tokens

Use 5-minute or even 1-minute access tokens. More frequent refresh checks, but still way better than hitting the DB on every request.

Option 2: Redis blacklist

Maintain a blacklist of revoked access tokens in Redis. Check it on every request:

async function protect(req, res, next) {
  const { accessToken } = req.cookies;

  try {
    const payload = jwt.verify(accessToken, SECRET);

    // Check blacklist (Redis is fast, ~1ms)
    const isBlacklisted = await redis.get(`blacklist:${payload.jti}`);
    if (isBlacklisted) {
      return res.status(401).json({ error: 'Token revoked' });
    }

    req.userId = payload.userId;
    return next();
  } catch (err) {
    // ... refresh token flow
  }
}

This trades some performance (1ms Redis check on every request) for instant revocation. You're still not hitting PostgreSQL, and Redis can handle way more load than your database.

Which to choose?

Most apps: 15-minute window is fine
Financial/Healthcare: 5-minute tokens or Redis blacklist
Admin panels: 1-minute tokens

Here's the comparison:

Approach	Response Time	Req/sec	DB Queries/sec	Revoke Access?	Fresh Data?
JWT-only	0.97ms	5,527	0	❌ No (7 days)	❌ Stale (7 days)
Session-only	1.52ms	4,561	4,561	✅ Instant	✅ Always
Hybrid	0.51ms	5,494	~0	✅ 15 min max	✅ 15 min max

Let's make this concrete. Say your app handles 5,000+ requests per second:

The hybrid approach gives you 99% of JWT's performance with session's security. That's not a compromise—it's getting the best of both.

I ran these benchmarks on PostgreSQL with 100 concurrent connections. Here's what actually happened:

Single request performance:

Hybrid: 0.51ms average
JWT-only: 0.97ms average
Session-only: 1.52ms average

The hybrid approach is actually faster than JWT-only because the access token verification is so lightweight. No database connection overhead. No query execution. Just JWT validation.

Under load (5,000+ requests/sec):

JWT-only: 5,527 req/sec, 0 database queries
Hybrid: 5,494 req/sec, ~0 database queries (99%+ fast path)
Session-only: 4,561 req/sec, 4,561 database queries/sec

See the problem? Session-only turns your auth system into a database bottleneck. Every single request waits on the database before it can do anything useful.

If you want to see the full benchmark results, I've published them here: stat-tests/RESULTS.md. The actual test code is also available if you want to run it yourself: stat-tests/test-three-auth-strategies.

When to Use What

Use the hybrid approach for pretty much everything. Seriously. Unless you have a specific reason not to, this is the pattern.

Use JWT-only if tokens are extremely short-lived (< 5 minutes) and you genuinely don't care about revocation. This is rare.

Use session-only if your app gets less than 10 requests per second total and you want to keep things simple.

That's it. You don't have to pick sides. Get the speed of JWTs with the control of sessions. It's not complicated, it just requires actually thinking about the trade-offs instead of cargo-culting whatever approach you read about first.

Happy Hacking!

Originally published on https://drreamer.digital/blog/session-tokens-vs-jwts-the-false-dichotomy

10 Hard-Earned Lessons (Plus One Bonus!) From Launching My First Startup

Wale Bashir — Tue, 28 Jan 2025 19:57:24 +0000

Looking Back: Building GoRemote Africa - The Maximum Viable Product Disaster

The Situation: Spent the last year building GoRemote Africa, a job board for remote work in Africa. What started as a simple "jobs go here" idea turned into a proper mess of features, four complete rewrites, and honestly, a masterclass in what not to do when you're building a product.

The Decisions: Let me be clear about this - I made some spectacularly bad choices. Here's the honest rundown so you don't have to repeat my mistakes.

The MVP That Wasn't Minimum At All

No beating around the bush - I restarted my codebase four times. Why? Because apparently I thought MVP stood for Maximum Viable Product. I crammed in AI-powered forms, three OAuth providers, magic links, two payment gateways, API keys, and granular role-based access—all before a single job got posted.

This thing was giving me serious wahala. By the fifth attempt, I was so demotivated I could barely open VS Code. Finally said enough and stripped everything down to the core: a job board that lets jobseekers find roles and lets employers post jobs. That's it. No drag-and-drop builder, no magic links. Just jobs.

Here's what I discovered: it worked better than all the over-engineered versions combined. The real issue here is that I was building for some imaginary user who needed every feature under the sun, instead of building for the actual user who just wanted to find a job.

Pretty UI Is Just Procrastination

Spent weeks browsing Behance, obsessing over hex codes and button padding whilst my core product sat there doing nothing. The site looks clean now, but those pixel-perfect gradients didn't validate my idea—shipping did.

Let me tell you what went wrong: I was using design as an excuse to avoid the scary part of building—actually putting something out there for people to use. Users don't care about your beautiful hover animations if they can't find what they're looking for.

The Development Environment Nightmare

Here's the thing though - I coded on Windows, deployed to Vercel's serverless environment, then tried to run it on a Linux VPS with Coolify. It was like watching a horror film at 2 AM. The sharp library threw proper tantrums, and suddenly I'm debugging OS-level dependencies instead of building features.

# This haunted my dreams for weeks
Error: sharp: Installation error, please try npm install --verbose sharp
# Windows said it was fine, Linux said absolutely not

The solution was simpler than I thought: Docker. Should have containerised everything from day one, but past me thought he was too clever for that. Now everything runs in containers, and I sleep better at night.

Multitasking Is Just Stress With Extra Steps

Tried to code, design, handle payments, and answer support emails simultaneously. Long story short: nothing got done properly. Now I finish one task before touching the next, even if it's small.

What I didn't expect was how much mental energy gets wasted just switching between contexts. Your brain isn't a computer - it can't actually multitask efficiently. Focus on one thing, finish it, then move on.

Finding Your People Makes All the Difference

Joining The Build Forge and MuslimBuilders changed everything. Suddenly I wasn't the only one dealing with these problems. Met founders who'd survived the same challenges and actually shipped products.

Bottom line is: half the "experts" giving advice online have never actually built anything. The builders in these communities? They've been through the fire and came out with working products. Their advice actually matters.

Your Workspace Actually Affects Your Work

2018: Coding in notebooks (the paper kind)

2021: A 4GB RAM Celeron laptop that struggled to run VS Code

2024: 27" monitor, ergonomic everything, and proper airflow

After too many debugging sessions hunched over that ancient laptop, I realised laggy tools and back pain were just making everything harder. The upgrade wasn't luxury—it was necessary for actually getting work done.

Git History Is Your Friend

Used to write commits like "fixed stuff lol" and bundle 10 changes into one. Then a bad deployment broke my dashboard, and I had to roll back weeks of work because I couldn't figure out what went wrong.

# Before (terrible)
git commit -m "fixed stuff lol"

# After (actually helpful)
git commit -m "fix: auth token expiry logic

- Updated JWT validation to handle edge case where tokens expire mid-request
- Added proper error handling for refresh token failures
- Refs: #issue-123"

Now I treat git history like a timeline. Future me needs to understand what past me was thinking and why.

Automation Saves Your Sanity

Scraping and filtering 100% remote jobs from the web manually? Checking for dead links by hand? Creating social posts one by one? This approach is simply not viable when you're trying to scale.

Built scrapers with Node.js, cron jobs for cleanup, and AI for content generation. Now the boring stuff happens automatically whilst I focus on the interesting problems.

// Weekly cleanup job that saved my sanity
const cleanupJobs = cron.schedule('0 0 * * 0', async () => {
  await removeExpiredJobs();
  await validateJobLinks();
  await updateRemoteStatus();
});

The Outcomes:

GoRemote Africa is live and actually helping people find jobs
Learned more about building products than any course could teach
Automated job scraping handles 90% of content updates
Built a tech stack that doesn't require 3 AM debugging sessions
Users are finding jobs, which was the whole point

The Lessons:

MVP means minimum, not maximum. Figure out the one thing your product must do, then build that.
Ship first, polish later. Perfect is the enemy of done.
Match your development environment to production. Or just containerise everything.
Focus on one task at a time. Your brain isn't a computer.
Find your community. Other builders understand your problems.
Invest in your workspace. Frustrating tools slow you down.
Write proper git commits. Future you will thank you.
Automate repetitive tasks. Your time is better spent elsewhere.
Mentorship is invaluable. Find people who've been where you're going.

The Changes:
Next time I'm building something, I'm starting with the absolute minimum viable version. No feature creep, no "just one more integration." Ship first, iterate based on actual user feedback.

Also sticking with the boring, reliable stack. SvelteKit + Node.js + Docker gets the job done without the fancy headaches.

What I'm doing differently: When I catch myself adding features before validating the core idea, I stop and ask: "Does this help users find jobs better?" If not, it goes in the "maybe later" list.

P.S. If you're hiring remotely, post a job on GoRemote. The AI forms are live now, and they actually work properly. 😉

Learn from my mistakes. Make new ones. What are you building BTW? 🛠️

Originally published on https://drreamer.digital/blog/10-hard-earned-lessons-from-launching-my-first-startup

From Svelte 4 to Svelte 5: Understanding Slots (default and named)

Wale Bashir — Thu, 26 Dec 2024 14:07:57 +0000

There are a lot of changes that might be confusing in Svelte 5, which is why I'm trying to document my learning process from Svelte 4 to Svelte 5.
One of them is using slots in Svelte 5. It was a much more straightforward process in <= Svelte 4:

Default Slots

Parent.svelte (default slots, svelte 4)

<Child>
<div>
// Your slot content
</div>
</Child>

Child.svelte (default slot, svelte 4)

<slot />

In Svelte 5, you need to use the @render syntax to render the slot, which you also take from the new $props():

Parent.svelte (default slots, svelte 5)

<!-- same as svelte 4 -->
<Child>
<div>
// Your slot content
</div>
</Child>

Child.svelte (default slot, svelte 5)

<script>
// destructure children from $props()
const { children } = $props()
</script>
<!-- render default slot here (with optional chaining just in case)-->
{@render children?.()}

Named Slots

Named slots have also changed, using both #snippet and @render syntaxes:

Parent.svelte (named slots, svelte 4)

<Child>
<div slot="mySlot">
// Your slot content
</div>
</Child>

Child.svelte (named slot, svelte 4)

<slot name="mySlot" />

In Svelte 5, you need to pass the slot with #snippet, then use the @render syntax to render the slot, which you also take from the new $props():

Parent.svelte (named slots, svelte 5)

<!-- same as svelte 4 -->
<Child>
{#snippet mySlot()}
<div>
// your slot content
</div>
{/snippet}
</Child>

Child.svelte (named slot, svelte 5)

<script>
// destructure children from $props()
const { mySlot } = $props()
</script>
<!-- render default slot here-->
{@render mySlot()}

Extras: You can also conditionally render content based on if a slot is passed with an if block:

Child.svelte (named slot, svelte 5, conditional render)

<script>
// destructure children from $props()
const { mySlot } = $props()
</script>
{#if mySlot}
<p>My Slot Section is rendered here</p>
<!-- render default slot here-->
{@render mySlot()}
{/if}

I'll keep documenting any changes as I come across them. By the way, what do you think of Svelte 5? Is the increase in compile time, the reduction in build size (for larger projects), and the extra features worth the added complexity?

Happy Hacking!

Originally published on https://drreamer.digital/blog/svelte-4-to-svelte-5-understanding-slots

Make EditorJS work in Svelte(kit) SSR

Wale Bashir — Wed, 25 Dec 2024 15:05:09 +0000

If you're here, you've probably been having issues using EditorJs in Sveltekit (like me). Since SSR isn't supported in EditorJs (see discussion), you might encounter errors like this:

[vite] Error when evaluating SSR module /src/routes/+page.svelte: failed to import "@editorjs/editorjs"
|- ReferenceError: Element is not defined

Here's how I solved it:

Load Editor Asynchronously: Ensure the editor loads only on the client side using onMount to avoid SSR complications.
Element Initialization: Bind elements properly and handle initialization using onMount to ensure the element is available after component setup.
Be Sure To Import EditorJs Correctly (since it's a default export):
- Default Import:
```
 const { default: EditorJs } = ...
```

Destructuring Import:

 const Editor = ...
const EditorJs = Editor.default

Here's the full solution:

Happy Hacking!

PS: If you're using Svelte 4, remember to change the Svelte-5-specific syntax. I'd advise you to switch as soon as possible tho.

Originally published on https://drreamer.digital/blog/make-editorjs-work-in-sveltekit-ssr

New Post here!🍻

Wale Bashir — Wed, 25 Dec 2024 11:44:05 +0000

A short guide to Async Components in Svelte 5

Wale Bashir ・ Dec 25 '24

#svelte #webcomponents #tutorial #javascript

A short guide to Async Components in Svelte 5

Wale Bashir — Wed, 25 Dec 2024 11:43:15 +0000

I couldn't find any working solution for this online, so I thought to share it when I got it to work.

The Problem: Asynchronous Components

I needed a maintenance page that would take over the entire site when enabled, but loading it on every page visit seemed wasteful. The component should only load when actually needed.

The Solution: Combining {#await} with Dynamic Imports

The {#await} block in Svelte lets you handle promises right in your template. Pair that with dynamic import() for lazy-loading, and you've got yourself a concise and clear way to handle async components.

Here's the code:

<script>
  // info.maintenance (boolean) && info.maintenance_ends (timestamp)
  let { info } = $props();
   const MaintenanceComponent = info?.maintenance 
    ? import("$lib/components/Maintenance.svelte")
    : null;
</script>

{#if MaintenanceComponent}
  {#await MaintenanceComponent then M}
    {@const Maintenance = M.default}
    <Maintenance time={info.maintenance_ends} />
  {:catch error}
    <p>Failed to load maintenance page: {error.message}</p>
  {/await}
{/if}

Dynamic Import: I used import() to load the Maintenance.svelte component asynchronously. This makes sure the component is only loaded when maintenance mode is turned on.
{#await} Block: This block allows me to await the import.
{@const}: The {@const}block allows you to extract the default export (M.default) into a local variable.

Happy Hacking!

Originally published on https://drreamer.digital/blog/a-short-guide-to-async-components-in-svelte-5

Running a Function When an #await Block resolves in Svelte(Kit)

Wale Bashir — Mon, 04 Nov 2024 20:20:15 +0000

Skip To Content:

About the #await block in svelte
Run (trigger) a function when the #await block resolves or rejects
Fix undefined or any returned text showing up in browser
- 1. Method 1 (Return empty strings):
- 2. Method 2 (Hide the returned text from the function in the UI with CSS.)
  - PS: Need to employ a SvelteKit Dev? Contact me

About the `#await` block in svelte

The #await block in svelte is very handy for handling asynchronous data:

<script>
import Loader from "$components/forms/Helpers/Loader.svelte";

export let data;
// let's say data.myPromise is a promise.
</script>

{#await data.myPromise}
<!-- This is what shows while the promise is pending -->
<Loader />

{:then results}
<!-- Shows this if/when the promise resolves successfully -->
{#each results as result}
<li>{result}</li>
{/each}

{:catch error}
<!-- Shows this if/when the promise rejects -->
<p class="text-red">{error?.message ?? "Something went wrong"}</p>
{/await}

This is basically how the #await block works in svelte. It displays different content based on the state of a promise: a loading indicator while pending, results when resolved, and an error message if rejected.

But let's say I want a certain function to run when the promise has been resolved or rejected (like a toast).

Run (trigger) a function when the `#await` block resolves or rejects

Here's how you can run specific functions when the promise resolves or rejects:

<script>
import { toast } from "svelte-sonner";

/**
* Displays a success toast
* @param {number | string} resultsLength - Number of results
*/
function showSuccess (resultsLength) {
toast.success(`${resultsLength} result${resultsLength > 1 ? "s" : ""} retrieved!`)
}

/**
* Displays an error toast
* @param {string} [errorMessage] - Error message to display
*/
function showError(errorMessage) {
toast.error(`An Error Occured`, {
message: errorMessage ?? "Unknown Error"
})
}

</script>

{#await data.myPromise}
<!-- Displays while the promise is pending -->
<Loader />

{:then results}
<!-- Run showSuccess when the promise resolves -->
{showSuccess(results.length)}

  <!-- Display results -->
{#each results as result}
<li>{result}</li>
{/each}

{:catch error}
<!-- Run (trigger) showError when the promise rejects -->
{showError(error.message)}

  <!-- Display error message -->
<p class="text-red">{error?.message ?? "Something went wrong"}</p>
{/await}

Now, our function will run whenever the code block is reached.

showSuccess is called when the promise resolves, with the number of results as an argument.
showError is triggered if the promise rejects, displaying a custom error message.

One more thing though...

Fix `undefined` or any returned text showing up in browser

When these functions run, whatever is returned text will show up in the browser, because it's kind of a workaround. The syntax we used is usually to meant to show returned strings/numbers in the browser. Even returning nothing will return the default undefined. And this string (which usually make no sense), will be displayed to the end user. Something like this:

Makes no sense to the end user 🤷‍♂️🤷‍♀️

So, make sure to return empty strings, or wrap the function in an hidden block:

1. Method 1 (Return empty strings):

In this method, we'll make sure to return empty strings from our functions.

<script>
import { toast } from "svelte-sonner";

/**
* @param {number | string} resultsLength
* @returns {string} - Empty string to avoid display issues
*/
function showSuccess (resultsLength) {
toast.success(`${resultsLength} result${resultsLength > 1 ? "s" : ""} retrieved!`)
return ""; // Return an empty string
}

/**
* @param {string} [errorMessage]
* @returns {string} - Empty string to avoid display issues
*/
function showError(errorMessage) {
toast.error(`An Error Occured`, {
message: errorMessage ?? "Unknown Error"
})
return ""; // Return an empty string
}

</script>

{#await data.myPromise}
  <!-- Display this while the promise is pending -->
<Loader />

{:then results}
<!-- Run showSuccess -->
{showSuccess(results.length)} <!-- Won't render any text in the UI -->

<!-- This shows if/when the promise is resolved -->
{#each results as result}
<li>{result}</li>
{/each}

{:catch error}
<!-- Run showError -->
{showError(error.message)} <!-- Won't render any text in the UI -->

<!-- This shows if/when the promise is rejected -->
<p class="text-red">{error?.message ?? "Something went wrong"}</p>
{/await}

This will make sure empty strings are returned.

--- Or ---

2. Method 2 (Hide the returned text from the function in the UI with CSS.)

In this method, we'll hide the function block in the UI instead, so the text returned is hidden from the user's sight.

<script>
import { toast } from "svelte-sonner";

/**
* @param {number | string} resultsLength
*/
function showSuccess (resultsLength) {
toast.success(`${resultsLength} result${resultsLength > 1 ? "s" : ""} retrieved!`)
// No explicit return necessary. Returns undefined by default
}

/**
* @param {string} [errorMessage]
* @returns {string}
*/
function showError(errorMessage) {
toast.error(`An Error Occured`, {
message: errorMessage ?? "Unknown Error"
})
// No explicit return necessary. Returns undefined by default
}

</script>

{#await data.myPromise}
  <!-- Display this while the promise is pending -->
<Loader />

{:then results}
<div class="hidden"> <!-- Hide the function block -->
  <!-- Display results -->

{showSuccess(results.length)}
</div>

<!-- This shows if/when the promise is resolved -->
{#each results as result}
<li>{result}</li>
{/each}

{:catch error}
<div class="hidden"><!-- Hide the function call -->
{showError(error.message)}
<div>

<!-- This shows if/when the promise is rejected -->
<p class="text-red">{error?.message ?? "Something went wrong"}</p>
{/await}

<style>
  .hidden {
    display: none;
  }
</style>

This CSS-based method will make sure that the returned text is hidden from sight.

HappyHacking

PS: Need to employ a SvelteKit Dev? Contact me

Originally published on https://drreamer.digital/blog/running-a-function-when-an-await-block-resolves-in-sveltekit

How to Compare (diff) two Objects

Wale Bashir — Wed, 23 Oct 2024 08:33:31 +0000

Object Comparison in JavaScript

Object comparison in JavaScript is deceptively complex. While comparing primitive values like numbers and strings is straightforward, comparing objects can lead to unexpected results. Let's explore different approaches to object comparison and build a robust solution for detecting changes between objects.

The Pitfalls of Direct Comparison

When developers first encounter object comparison in JavaScript, they often try something like this:

const user1 = { name: "John", age: 30 };
const user2 = { name: "John", age: 30 };

console.log(user1 === user2); // false

Surprisingly, this returns false even though both objects have identical content. This happens because JavaScript compares object references, not their values. Both objects point to different locations in memory.

Simple Comparison Approaches

1. JSON.stringify

A quick way to compare objects is using JSON.stringify:

const areEqual = (obj1, obj2) => 
  JSON.stringify(obj1) === JSON.stringify(obj2);

console.log(areEqual(user1, user2)); // true

While this works for simple cases, it has limitations:

Doesn't handle functions
Order of properties matters
Can't handle circular references
Doesn't provide information about what's different

2. Building a Better Object Diff

Let's create a more sophisticated solution that not only detects differences but also tells us what changed:

function getObjectDiff(original, current) {
  const changes = {};

  // Check current object's properties
  for (const [key, value] of Object.entries(current)) {
    if (!(key in original)) {
      changes[key] = {
        oldValue: undefined,
        newValue: value
      };
      continue;
    }

    const originalValue = original[key];
    const currentValue = value;

    // Handle different types of comparisons
    if (
      originalValue !== currentValue &&
      String(originalValue) !== String(currentValue) &&
      JSON.stringify(originalValue) !== JSON.stringify(currentValue)
    ) {
      changes[key] = {
        oldValue: originalValue,
        newValue: currentValue
      };
    }
  }

  // Check for removed properties
  for (const key of Object.keys(original)) {
    if (!(key in current)) {
      changes[key] = {
        oldValue: original[key],
        newValue: undefined
      };
    }
  }

  return Object.keys(changes).length === 0 ? null : changes;
}

This implementation:

Returns null when objects are identical
Handles type coercion (e.g., "30" vs 30)
Detects added and removed properties
Provides detailed change information

Real-World Applications

This type of object comparison is particularly useful for:

Form Change Tracking: Detect which fields changed in a form

const originalForm = { name: "John", email: "john@example.com" };
const currentForm = { name: "John", email: "john.doe@example.com" };
console.log(getObjectDiff(originalForm, currentForm));
// Output: { email: { oldValue: "john@example.com", newValue: "john.doe@example.com" } }

State Management: Track which parts of your application state changed
API Updates: Determine which fields to send in PATCH requests
Audit Logging: Record specific changes made to data

Edge Cases (where you might need to go the extra mile)

Nested Objects: Deep comparison vs shallow comparison
Arrays: Order sensitivity and reference comparison
Type Coercion: String vs Number comparisons
Special Values: undefined, null, NaN
Performance: Deep comparison can be expensive for large objects

PS: Here's a Github gist for a simple function to compare and get the difference between two objects:

Originally published on https://drreamer.digital/blog/how-to-compare-diff-two-objects

Calling a SvelteKit form action (or submitting a form) from a component

Wale Bashir — Thu, 05 Sep 2024 13:54:26 +0000

Handling Form Submissions from a SvelteKit Component

Submitting a form from a SvelteKit component to be handled by a server-side form action is simpler than you might think. You don’t need the form to be inside a page. It can live in any component and still interact with SvelteKit’s server-side functionality.

This post will walk you through submitting a form from a component, processing it using a default form action from a +page.server.js, and setting up a +page.svelte to bind the form.

Project Structure

my-sveltekit-project/
├── src/
│   ├── components/
│   │   └── FormTestComponent.svelte
│   ├── routes/
│   │   ├── +page.svelte
│   │   └── test/
│   │       └── +page.server.js
├── static/
├── package.json
├── svelte.config.js
├── vite.config.js
└── tsconfig.json

1. Create the `FormTestComponent` and Add a Form

First, let’s create a FormTestComponent that contains a simple form:

<!-- src/lib/components/FormTestComponent.svelte -->
<script>
  export let form;
</script>

<form>
  <input id="test" name="test" />
  <button type="submit"> Submit </button>
</form>

The FormInput component is a custom input field used here for the form.
{form} is shorthand for form={form}, which binds the form object passed from the page to this component.

At this point, we have a basic form ready to be used inside a component, but we haven't yet connected it to server-side form handling.

2. Set Up `+page.svelte` for Form Binding

Now, create a +page.svelte file to use the FormTestComponent and bind its form prop.

<!-- routes/+page.svelte -->
<script>
  import FormTestComponent from "$lib/components/FormTestComponent.svelte";
  export let form; // This comes from the page’s server-side form response
</script>

<FormTestComponent {form} />

Key Points:

export let form;: The form object comes from the form action response on the server and is passed down to FormTestComponent. This binds the form response data to the form prop in the component.
Reactivity: As the form is submitted and updated on the server, the form object will reflect these changes client-side, keeping everything in sync.

3. Enhancing the Form Submission in `FormTestComponent`

To handle form submissions efficiently, SvelteKit provides the use:enhance directive, which allows you to enhance the form with progressive enhancement features like handling submissions without a full page reload.

Here's how you enhance the form submission in FormTestComponent:

<!-- src/lib/components/FormTestComponent.svelte -->
<script>
  import { enhance } from "$app/forms";
  import FormInput from "$components/forms/FormInput.svelte";
  import { page } from "$app/stores";

  let loading = false;
  export let form;
  $: console.log(form); // Log form response for debugging
</script>

<form
  method="POST"
  on:submit|preventDefault
  action="/test"
  use:enhance
>
  <FormInput label="test" id="test" />
  <button type="submit"> Submit </button>
</form>

Key Points:

use:enhance: This directive enhances the form to handle submissions without a full reload. It also makes it easy to handle errors or partial form updates client-side.
on:submit|preventDefault: This prevents the browser’s default form submission behavior (a page reload), allowing SvelteKit to handle it.
action="/test": The form points to the /test route, which we’ll create soon. If we were using a named action (like signup), the URL would look like /test?/signup.

4. Creating the Server-side Action

To process the form on the server, create a directory at /test with a +page.server.js (or +page.server.ts if you prefer TypeScript).

Here’s an example of what the form action might look like in +page.server.js:

// - /routes/test/+page.server.js
/** @type {import('./$types').Actions} */
export const actions = {
    default: async ({ request }) => {
        const data = await request.formData();
        const formEntries = Object.fromEntries(data.entries()); // Convert form data to an object
        console.log(formEntries); // Log form data on the server
        return {
            success: true,
            message: "Yay!!"
        };
    }
};

Key Points:

request.formData(): This method retrieves the submitted form data from the request.
Object.fromEntries(data.entries()): This converts the form data into a more usable object format, where each form field name becomes a key, and its value is the corresponding value.

This is where the server processes the form. In this case, we’re logging the form data and returning a success message. In a real-world scenario, you’d likely perform validation and handle any errors.

5. Seeing the Form Response

Once the form is submitted, you'll see the form data logged both in the terminal (server-side) and in the browser’s console (client-side). This is thanks to the console.log(form) in the component and the console.log(formEntries) in the +page.server.js, which logs the form response and the form respectively.

Conclusion

Now you’ve successfully created a form inside a SvelteKit component that submits data to a server-side form action. You didn’t need to use a full page for the form, and you’ve utilized SvelteKit’s use:enhance to handle submissions seamlessly without a page reload.

You can extend this by adding custom validation, handling errors, or even performing more complex actions like file uploads.

Happy Hacking!

Originally published on https://drreamer.digital/blog/calling-a-sveltekit-form-action-or-submiting-a-form-from-a-component

Fix for EPERM: operation not permitted (...$types.d.ts)

Wale Bashir — Sat, 31 Aug 2024 22:37:48 +0000

I had an issue running my sveltekit dev server. I kept getting this issue:

EPERM: operation not permitted, stat 'C:\Users\user\Documents\Github\SvelteKit\Goremote Africa\main\.svelte-kit\types\src\routes\$types.d.ts'

Here's how to solve it:

This didn't solve anything, but you might want to clear your npm cache first:

npm cache clean --force

Run CMD as admin and enter this:

npm config edit

It will open a notepad window/tab.

Set prefix variable to C:\Users\user\AppData\Roaming\npm. Remember to change user to your username:

prefix=C:\Users\user\AppData\Roaming\npm

Save and close the notepad window and run your development server. It should work now:

Happy Hacking!

Originally published on https://drreamer.digital/blog/fix-for-eperm-operation-not-permitted-typesdts

DEV Community: Wale Bashir

Using Bitmasks for Role-Based Permissions: Stop Querying Your Database

The Problem with Database Queries

The Problem with JWTs

The Bitmask Approach

Storing Permissions in Your Database

Middleware Implementation

Performance: Real Numbers

Memory: The Real Win

Combining with Your Auth Strategy

Combining with Your Auth Strategy

Why Bitmask in JWT?

Role-Based Permissions

Security Considerations (The Important Bit)

Permission Staleness Window

Token Revocation is Impossible

Bit Position Management

Principle of Least Privilege

Audit Logging

Debugging Helper Functions

The Limitations (The Honest Bit)

When to Actually Use This

What You've Learned

Bitmask Operations: The Math You Skipped (And Why It Matters)

How Computers Actually Count

What Those 1s and 0s Mean

The Lightbulb Moment

A Real Example: Feature Flags

The Four Operations

1. Adding Features (OR: |)

2. Checking Features (AND: &)

3. Removing Features (AND + NOT: & ~)

4. Toggling Features (XOR: ^)

Why This Can Be Better

Real Problems This Solves

Network Protocols

Permission Systems

The Limitations

When to Actually Use This

What's Next

Session Tokens vs JWTs: The False Dichotomy

The JWT-Only Approach (and Why It's Dangerous)

The Session-Only Approach (and Why It Doesn't Scale)

Why "JWTs Are for Microservices" Is Bullshit

The Solution: Short Access Tokens + Long Refresh Tokens

What About High-Security Scenarios?

When to Use What

10 Hard-Earned Lessons (Plus One Bonus!) From Launching My First Startup

Looking Back: Building GoRemote Africa - The Maximum Viable Product Disaster

The MVP That Wasn't Minimum At All

Pretty UI Is Just Procrastination

The Development Environment Nightmare

Multitasking Is Just Stress With Extra Steps

Finding Your People Makes All the Difference

Your Workspace Actually Affects Your Work

Git History Is Your Friend

Automation Saves Your Sanity

From Svelte 4 to Svelte 5: Understanding Slots (default and named)

Default Slots

Named Slots

Make EditorJS work in Svelte(kit) SSR

New Post here!🍻

A short guide to Async Components in Svelte 5

Wale Bashir ・ Dec 25 '24

A short guide to Async Components in Svelte 5

The Problem: Asynchronous Components

The Solution: Combining {#await} with Dynamic Imports

Running a Function When an #await Block resolves in Svelte(Kit)

About the #await block in svelte

Run (trigger) a function when the #await block resolves or rejects

Fix undefined or any returned text showing up in browser

1. Method 1 (Return empty strings):

2. Method 2 (Hide the returned text from the function in the UI with CSS.)

HappyHacking

PS: Need to employ a SvelteKit Dev? Contact me

How to Compare (diff) two Objects

Object Comparison in JavaScript

The Pitfalls of Direct Comparison

Simple Comparison Approaches

1. JSON.stringify

1. Adding Features (OR: `|`)

2. Checking Features (AND: `&`)

3. Removing Features (AND + NOT: `& ~`)

4. Toggling Features (XOR: `^`)

About the `#await` block in svelte

Run (trigger) a function when the `#await` block resolves or rejects

Fix `undefined` or any returned text showing up in browser

1. Create the `FormTestComponent` and Add a Form

2. Set Up `+page.svelte` for Form Binding

3. Enhancing the Form Submission in `FormTestComponent`