Forem: websilvercraft

Agentic patterns and architectural approaches in AI

websilvercraft — Sun, 07 Dec 2025 09:15:35 +0000

Below is a set of commonly discussed agentic patterns and architectural approaches in the field of AI. These patterns often appear in intelligent agent design, multi-agent systems, and autonomous decision-making frameworks. While some patterns originate from theoretical foundations, others stem from well-known implementations and best practices.

1. Reactive (Reflex) Agents

Simple Reflex Agents:
Agents that directly map percepts to actions without internal models. They respond immediately based on current input alone (e.g., a thermostat controlling temperature by simple rules).
Model-Based Reflex Agents:
Agents that maintain an internal model of the environment to handle partially observable states. They update their model based on incoming perceptions, enabling more nuanced immediate reactions.

2. Goal-Based Agents

Goal-Directed Reasoning:
Agents that select actions by considering their goals and how each potential action might help achieve them. Their patterns involve search, planning, and heuristic evaluation to determine which action leads them closer to their objectives.
Constraint-Solving Agents:
Agents that represent their environment and objectives as constraints and explore feasible solutions that satisfy these constraints. Their decision-making pattern focuses on reducing the search space to find valid goal states.

3. Utility-Based Agents

Decision-Theoretic Agents:
Agents that assign a utility value (or expected utility) to potential outcomes and choose actions that maximize long-term expected utility. This pattern commonly appears in economic modeling and complex decision-making tasks.
MDP/RL-Based Agents (Markov Decision Processes / Reinforcement Learning):
Agents that frame their interactions as sequential decision problems, using methods like Q-learning, policy gradients, or value iteration to maximize expected rewards over time.

4. Belief-Desire-Intention (BDI) Agents

Cognitive Architectures (BDI):
Agents that maintain explicit representations of their beliefs (information about the world), desires (long-term objectives), and intentions (committed plans of action). These patterns follow philosophical foundations of rational agency, enabling modular reasoning and more naturalistic decision-making.
Layered Reasoning in BDI Systems:
Hierarchical patterns that separate high-level abstract reasoning about goals and beliefs from low-level execution details. For example, the PRS (Procedural Reasoning System) framework.

5. Hybrid Architectures

Layered Architectures (e.g., Touring Machines, InteRRaP):
Agents that combine reactive and deliberative layers. A reactive layer handles immediate responses while a higher-level reasoning or planning layer manages longer-term strategic goals. This pattern ensures responsiveness while still accommodating complex planning.
Three-Layer Architectures (Reactive, Sequencing, Deliberative):
A commonly cited pattern in robotics and AI that has a bottom reactive layer (fast control loops), a middle sequencing or skill management layer, and a top deliberative or planning layer.

6. Multi-Agent Interaction Patterns

Contract Net Protocol:
A decentralized pattern where agents announce tasks, and other agents bid for them. The "manager" agent chooses the best bid, exemplifying a market-based mechanism for task allocation.
Coordinator/Facilitator Patterns:
A designated agent or set of agents coordinates the activities of others, handling negotiation, resource distribution, or conflict resolution.
Blackboard Architectures:
A pattern where multiple specialized agents read and write knowledge to a shared data structure (a "blackboard"). Agents trigger each other’s actions by posting partial solutions or data that others can build upon.

7. Adaptive and Self-Organizing Patterns

Stigmergic Coordination:
Agents coordinate indirectly via modifications to a shared environment (e.g., ants depositing pheromones). This pattern emerges in swarm intelligence and behavior-based robotics.
Evolutionary Agent Populations:
Patterns where agent behavior is optimized through evolutionary computation or genetic algorithms, ensuring a population of agents adapt over time.

8. Service-Oriented and Ontology-Based Agent Patterns

Agent-Oriented Software Engineering (AOSE) Frameworks:
Patterns that follow methodologies (e.g., Gaia, Tropos) to define roles, interactions, and organizational rules that shape agent behavior.
Ontology-Driven Agents:
Agents that rely on shared semantic vocabularies for communication and coordination, enabling interoperability and modular composition of knowledge bases.

These patterns offer a conceptual toolkit for designing, analyzing, and implementing intelligent agents and multi-agent systems. Designers often combine multiple patterns—for instance, layering a BDI reasoning process atop a reactive framework or incorporating utility-based decision-making into a multi-agent negotiation protocol—to address complex, dynamic environments.

How does Drizzle handle migrations - Part 1

websilvercraft — Thu, 09 Oct 2025 15:56:09 +0000

Drizzle keeps a local snapshot of the previous schema and diffs the current TS schema against that snapshot when generating migrations.

Here’s how it works:

The source of truth: the TypeScript schema files (e.g. src/db/schema.ts, schema.billing.ts).
Drizzle’s stored “old state”: a small meta snapshot that lives next to the migrations, typically under something like:

  migrations/
    0001_init.sql
    0002_billing.sql
    ...
    meta/
      _journal.json
      _meta.json

(Exact file names can vary by Drizzle version, but there’s always a meta folder with the snapshot/journal.)

When you run drizzle-kit generate: Drizzle reads:

your current TS schema
the previous meta snapshot …and produces a new 00xx_*.sql migration that transforms the old snapshot into the new schema. It also updates the meta files.

What the DB stores: In the database, Drizzle keeps a tiny migrations journal table (e.g. __drizzle_migrations / similar) that tracks which migration files were applied. It’s not used for schema diffing-only for apply-order / applied-state when you execute migrations.

If things get out of sync

Lost meta folder? You can introspect the DB to recreate a baseline schema (Drizzle has an introspect command) or generate a new “initial” migration matching the current DB, then continue forward.
Edited an old migration? Don’t. Migrations should be immutable once applied. If you must, expect to reconcile by fixing your meta and/or DB to match.
DB drifted from code? Either:
- Update your TS schema to match and generate the next migration, or
- Use introspection to realign the local snapshot with the live DB, then proceed.

TL;DR

Drizzle diffs TS schema vs. its local meta snapshot, not the live DB.
The DB only tracks which migrations ran, not the structure for diffing.
If the snapshot is missing/outdated, use introspection to rebuild a baseline or create a new initial migration that matches the current DB, then keep going.

What is Zod and what does it bring over typescript type definitions

websilvercraft — Wed, 27 Aug 2025 10:52:07 +0000

Zod is a framework that covers a gap that happens because typescript gets compiled into javascript. Typescript being strongly typed, but java not, you are covered are compile-time for type checks, but that is lost at run time. Zod is here to do perform type checks at runtime plus adding data validations and even transformation.

The Core Difference: Compile-Time vs Runtime

TypeScript Types = Compile-Time Only

// This type disappears after compilation
interface User {
  name: string;
  age: number;
}

// TypeScript thinks this is fine at compile time
const userData: User = await fetch('/api/user').then(r => r.json());
console.log(userData.name); // 💥 Runtime error if API returns { username: "John" }

Zod = Runtime Validation + Type Inference

import { z } from 'zod';

// This exists at runtime AND generates TypeScript types
const UserSchema = z.object({
  name: z.string(),
  age: z.number()
});

// This will throw at runtime if data doesn't match
const userData = UserSchema.parse(await fetch('/api/user').then(r => r.json()));
console.log(userData.name); // ✅ Guaranteed to exist and be a string

What Zod Adds: The Advantages

1. Runtime Safety for External Data

// ❌ TypeScript alone - false confidence
interface APIResponse {
  users: Array<{ id: number; email: string }>;
}

// TypeScript: "Looks good!" 
// Reality: API might return { users: null } or { data: [...] }
const response: APIResponse = await fetchAPI();
response.users.map(...); // 💥 Cannot read property 'map' of null

// ✅ With Zod - actual validation
const APIResponseSchema = z.object({
  users: z.array(z.object({
    id: z.number(),
    email: z.string().email() // Even validates email format!
  }))
});

try {
  const response = APIResponseSchema.parse(await fetchAPI());
  response.users.map(...); // ✅ Guaranteed safe
} catch (error) {
  // Handle malformed response
}

2. Single Source of Truth

// ❌ TypeScript - duplicate definitions
interface User {
  email: string;
  age: number;
}

function validateUser(data: any): data is User {
  return typeof data.email === 'string' && 
         typeof data.age === 'number' &&
         data.age >= 0; // Oops, forgot this in the type!
}

// ✅ Zod - one definition, both type and validation
const UserSchema = z.object({
  email: z.string().email(),
  age: z.number().min(0)
});

type User = z.infer<typeof UserSchema>; // Type derived from schema
const isValid = UserSchema.safeParse(data).success; // Validation from same source

3. Rich Validation Beyond Types

// ❌ TypeScript can't express these constraints
interface Password {
  value: string; // Can't say "min 8 chars, must have uppercase"
}

// ✅ Zod can validate complex rules
const PasswordSchema = z.string()
  .min(8, "Password must be at least 8 characters")
  .regex(/[A-Z]/, "Must contain uppercase letter")
  .regex(/[0-9]/, "Must contain number")
  .regex(/[^A-Za-z0-9]/, "Must contain special character");

4. Transformation and Coercion

// ✅ Zod can transform data while validating
const ConfigSchema = z.object({
  port: z.string().transform(Number), // "3000" → 3000
  enabled: z.string().transform(s => s === "true"), // "true" → true
  createdAt: z.string().pipe(z.coerce.date()), // "2024-01-01" → Date object
  email: z.string().toLowerCase().trim().email() // Clean and validate
});

// URL params, form data, environment variables - all strings!
const config = ConfigSchema.parse({
  port: "3000",
  enabled: "true", 
  createdAt: "2024-01-01",
  email: "  USER@EXAMPLE.COM  "
});
// Result: { port: 3000, enabled: true, createdAt: Date, email: "user@example.com" }

5. Better Error Messages

// ❌ TypeScript at runtime
JSON.parse(apiResponse); // Error: Unexpected token < in JSON at position 0

// ✅ Zod validation errors
UserSchema.parse(data);
/* ZodError: {
  "issues": [{
    "path": ["email"],
    "message": "Invalid email format"
  }, {
    "path": ["age"],
    "message": "Expected number, received string"
  }]
} */

6. Composability

// Build complex schemas from simple ones
const AddressSchema = z.object({
  street: z.string(),
  city: z.string(),
  zip: z.string().regex(/^\d{5}$/)
});

const PersonSchema = z.object({
  name: z.string(),
  addresses: z.array(AddressSchema), // Reuse schemas
  primaryAddress: AddressSchema.optional()
});

const CompanySchema = z.object({
  employees: z.array(PersonSchema), // Compose further
  headquarters: AddressSchema
});

Real-World Example: Your HeadingAnalyzer

// What could go wrong without runtime validation?

// 1. DOM parsing might produce unexpected results
const heading = {
  level: 7, // ❌ TypeScript won't catch this at runtime
  text: null, // ❌ Might be null instead of empty string
  position: -1, // ❌ Could be negative
  id: undefined // ❌ Might be undefined instead of null
};

// 2. Cloudflare Worker receives malformed data
const apiResponse = await fetch('/analyze');
const data: HeadingAnalysisResult = await apiResponse.json();
// TypeScript: "Looks good!"
// Reality: Could be { error: "Rate limited" } or literally anything

// 3. With Zod, you catch these issues immediately
const HeadingInfoSchema = z.object({
  level: z.number().min(1).max(6), // Must be 1-6
  text: z.string(), // Coerces null to empty string
  position: z.number().int().nonnegative(), // Must be positive integer
  id: z.string().nullable() // Explicitly nullable, not undefined
});

When You NEED Zod

API Boundaries: Validating external API responses
User Input: Form data, URL params, file uploads
Config Files: Environment variables, JSON configs
Database Results: Ensuring DB schema matches expectations
Webhooks: Third-party services sending data
localStorage/sessionStorage: Stored data might be corrupted

When TypeScript Types Are Enough

Internal Code: Functions calling other functions you control
Build-Time Known: Imported JSON, constants
Trusted Sources: Your own internal services with guaranteed contracts
Performance Critical: Hot paths where validation overhead matters

In conclusion, TypeScript protects you from yourself (typos, wrong types in your code). Zod protects you from the world (APIs, users, databases, external systems).

Same Fetch, Different Streams: duplex: 'half' in Node vs Cloudflare Workers

websilvercraft — Sat, 23 Aug 2025 10:25:09 +0000

In the last post What’s the Request object in the browser, Cloudflare, and Node?, I detailed the how the Request class is the same regardless the implementation. However, when handling streams, there are some practical differences, even though both runtimes expose the same Fetch API.

What differs with streams

Stream types available
- Cloudflare Workers: only Web Streams (ReadableStream, WritableStream, TransformStream).
- Node 18+: has both classic Node streams and Web Streams. fetch uses Web Streams, but Node lets you pass a Node Readable as a request body.
Streaming request bodies (uploads)
- Node: if the request body is a stream, you must set duplex: 'half' in the init/options. If you forget, you’ll get: “duplex option is required when sending a body that is a ReadableStream”.
- Workers: no duplex flag; just pass a Web ReadableStream.
Bridging between stream kinds (Node only)
- Convert Node → Web: Readable.toWeb(nodeWritable) / Readable.from(nodeReadable) (or Readable.fromWeb).
- You’ll use this when adapting http.IncomingMessage ↔︎ Fetch.
Response bodies (downloads)
- Both return a Web ReadableStream at response.body.
- In Node, to send it to http.ServerResponse, convert the Node writable to a Web Writable and pipeTo.

Tiny patterns

Node: adapt `IncomingMessage` → `Request` (streaming upload)

import { Readable } from 'node:stream'

const request = new Request(url, {
  method,
  headers,
  body: hasBody ? (req as unknown as Readable) : undefined, // Node stream ok
  // Node/undici requirement for streamed bodies:
  // @ts-expect-error undici extension
  duplex: hasBody ? 'half' : undefined,
})

Node: write a streamed `Response` back to `ServerResponse`

import { Readable } from 'node:stream'

const response = await fetchHandler(request)

res.statusCode = response.status
response.headers.forEach((v, k) => res.setHeader(k, v))

if (response.body) {
  // pipe Web ReadableStream → Node ServerResponse
  // @ts-ignore types can lag behind
  await response.body.pipeTo(Readable.toWeb(res))
} else {
  res.end()
}

Workers: streaming is Web-Streams-native

export default {
  async fetch(req: Request) {
    // req.body is a Web ReadableStream (or null)
    return new Response(req.body) // streams through unchanged
  }
}

Rules of thumb

Use Web Streams as your common denominator.
In Node, add duplex: 'half' only when the request body is a stream.
Convert between Node and Web streams only at the edges (the Node HTTP adapter). Your itty router can stay pure-Fetch/Web-Streams and run the same on Workers and Node.

What’s the `Request` object in the browser, Cloudflare, and Node?

websilvercraft — Sat, 23 Aug 2025 10:15:20 +0000

I’ve been building a tiny API with itty-router that I want to run unchanged on Cloudflare Workers and a plain Node server. itty is fetch-native—it speaks in terms of fetch(req), Request, and Response. That’s awesome for portability, but it also means the whole trick hinges on the Request object being consistent across runtimes.

Before I wired everything up, I needed to check if I can use on the same Request objects in cloudflare and node environments.

The Request to use with fetch is part of the WHATWG Fetch Standard—a web platform spec that defines fetch, Request, Response, Headers, etc. All three environments expose the same API surface (with minor runtime quirks), so code written against the spec tends to work everywhere.

Where it comes from

Browser Request is a built-in global provided by the browser. No imports.

  const req = new Request('/api', { method: 'POST' })
  const res = await fetch(req)

Cloudflare Workers Workers implement the same Fetch standard. Request is global here too.

  export default {
    async fetch(req) {
      // req is already a Request
      return new Response('ok')
    }
  }

Node.js (v18+) Node ships a Fetch implementation (via undici) and sets Request as a global alongside fetch, Response, and Headers. You don’t need to import anything.

  // Node 18+:
  const req = new Request('https://example.com')
  const res = await fetch(req)
  console.log(res.status)

Why you don’t import it in Node

Because Node 18+ defines Request on globalThis just like the browser/Workers. Older Node versions didn’t have it—you had to polyfill (e.g., node-fetch or undici). On current Node, it’s simply available.

TypeScript tip

For Node projects, add DOM libs so the Request type is known at compile time:

// tsconfig.json
{
  "compilerOptions": {
    "lib": ["ES2022", "DOM"]
  }
}

A tiny sanity check

console.log(typeof Request)           // "function" in all three
console.log(globalThis.Request === Request) // true

When streams are involved there are a few practical differences, even though both runtimes expose the same Fetch API. For example, in Node, if you construct a Request from a Node stream, you’ll include duplex: 'half' in the init. For ordinary JSON bodies/strings, you can ignore this. Details about the streams related fidderences, in the next post: Same Fetch, Different Streams: duplex: 'half' in Node vs Cloudflare Workers.

One router, two runtimes: itty-router on Cloudflare Workers and Node

websilvercraft — Sat, 23 Aug 2025 09:30:26 +0000

I wanted one tiny router that runs unchanged on Cloudflare Workers and a plain Node HTTP server. The secret sauce is itty-router + the Fetch standard (Request/Response). Here’s how I wired it up, plus a quick note on the “do Node and Cloudflare use the same Response?” question.

Do Node and Cloudflare use the same Response object?
Short answer: not literally the same object, but the same Fetch standard Response API, compatible classes with different under the hood implementations.
– Cloudflare Workers exposes a Response that follows the WHATWG Fetch spec.
– Modern Node (v18+) also exposes a Fetch-compatible Response (implemented by undici).

So they’re API-compatible (same props/methods: status, headers, text(), json(), arrayBuffer(), body as a Web ReadableStream, new Response(), etc.), but they’re different implementations under the hood—don’t rely on brand checks like mixing realms or instanceof across runtimes.

A few practical gotchas:
– Streaming: both use Web Streams; in Node you sometimes convert to/from Node streams (Readable.fromWeb, Readable.toWeb) when bridging to http.ServerResponse.
– Node-only quirks (Requests): when you construct a Request with a Node stream body, Node needs duplex: 'half'. This is not needed/used in Workers. (Doesn’t affect Response itself.)
– Helpers: Response.json() exists in Workers and in recent Node. If you need to support older Node, fallback to new Response(JSON.stringify(data), { headers: { 'content-type': 'application/json; charset=utf-8' } }).

If you stick to the spec surface (like in the router below), you can reuse the same code in both environments. For a more detailed explanation, check What’s the Request object in the browser, Cloudflare, and Node?.

The shared router (one codepath)

itty-router’s AutoRouter can produce a single fetch handler. Keep the routes and tiny HTTP helpers here.

// src/router.ts
import { AutoRouter } from 'itty-router'

// tiny helpers
const withCORS = (res: Response, status = res.status) =>
  new Response(res.body, {
    status,
    headers: {
      'content-type': res.headers.get('content-type') ?? 'application/json; charset=utf-8',
      'access-control-allow-origin': '*',
      'access-control-allow-methods': 'GET,POST,OPTIONS',
      'access-control-allow-headers': 'content-type',
    },
  })

const ok = (data: unknown) => withCORS(Response.json(data))
const badRequest = (msg: string) => withCORS(Response.json({ error: msg }), 400)
const noContent = () => withCORS(new Response(null, { status: 204 }), 204)

const router = AutoRouter({ base: '/' })

// CORS preflight
router.options('/*', () => noContent())

// sample routes (keep it simple)
router.get('/hello', () => ok({ hello: 'world' }))

router.post('/echo', async (req: Request) => {
  try {
    const body = await req.json()
    return ok({ youSent: body })
  } catch {
    return badRequest('Expected JSON body')
  }
})

// 404
router.all('*', () => withCORS(Response.json({ error: 'Not found' }), 404))

// export a single fetch (works on Workers; reusable in Node)
export default { fetch: router.fetch }

That’s it. This fetch function is our “universal” entry point.

Cloudflare Worker entry (zero glue)

Cloudflare Workers already speak fetch:

// src/worker.ts
import router from './router'

export default {
  fetch: router.fetch,
}

Deploy with your usual Wrangler config.

Node adapter (a tiny bridge)

For Node, we just translate IncomingMessage ⟶ Request, call the shared fetch, then write the Response back.

// src/node-server.ts
/// <reference types="node" />
import http from 'node:http'
import { Readable } from 'node:stream'
import router from './router'

const PORT = Number(process.env.PORT ?? 8787)

http.createServer(async (req, res) => {
  try {
    const url = new URL(req.url ?? '/', `http://${req.headers.host ?? 'localhost'}`)
    const method = req.method ?? 'GET'

    // build Headers
    const headers = new Headers()
    for (const [k, v] of Object.entries(req.headers)) {
      if (Array.isArray(v)) v.forEach(vv => headers.append(k, vv))
      else if (v != null) headers.set(k, String(v))
    }

    // only attach a body for non-GET/HEAD
    const hasBody = !['GET', 'HEAD'].includes(method.toUpperCase())
    const body = hasBody ? (req as unknown as Readable) : undefined

    const request = new Request(url.toString(), {
      method,
      headers,
      body,
      // Node (undici) quirk when passing a stream body:
      // @ts-expect-error undici extension
      duplex: hasBody ? 'half' : undefined,
    })

    const response = await router.fetch(request)

    res.statusCode = response.status
    response.headers.forEach((v, k) => res.setHeader(k, v))

    if (!response.body) return res.end()

    // stream to Node
    // @ts-ignore types for toWeb are a bit behind
    await (response.body as any).pipeTo(Readable.toWeb(res) as any)
  } catch (err: any) {
    res.statusCode = 500
    res.setHeader('content-type', 'application/json; charset=utf-8')
    res.end(JSON.stringify({ error: 'Internal error', detail: String(err?.message ?? err) }))
  }
}).listen(PORT, () => {
  console.log(`Node server: http://localhost:${PORT}`)
})

TypeScript tip

Make sure your tsconfig.json includes DOM types so Request/Response are available in Node:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "lib": ["ES2022", "DOM"],
    "strict": true
  }
}

Why this works so well

Single mental model: you write to the Fetch standard once. itty-router just plugs in.
No “environment if”s: the router and helpers are runtime-agnostic.
Portability: same handler can move to other Fetch runtimes (Bun, Deno Deploy, etc.) with little/no glue.

Quick curl test

# Node server
curl http://localhost:8787/hello
# => {"hello":"world"}

curl -X POST http://localhost:8787/echo -H 'content-type: application/json' -d '{"x":1}'
# => {"youSent":{"x":1}}

For Workers, hit your deployed URL with the same requests.

Gotchas & guardrails

Don’t do instanceof Response checks across runtimes—treat them as structurally compatible, not identical classes.
When constructing a Request from a Node stream, pass duplex: 'half'.
If you need cookies or advanced streaming, test both runtimes—semantics are compatible, but edge cases differ.

How to Protect Email Addresses from Spam Bots

websilvercraft — Wed, 09 Apr 2025 19:18:07 +0000

Email addresses on websites are prime targets for spam bots that crawl the web looking for this valuable data. If you have a contact page with email addresses displayed in plain text, you're practically inviting unwanted spam. Here are several effective methods to protect your email addresses while keeping them accessible to human visitors.

1. JavaScript Email Obfuscation

Replace plain text email addresses with JavaScript that dynamically constructs the email when needed:

document.addEventListener('DOMContentLoaded', function() {
  const emailElements = document.querySelectorAll('.email-protect');
  emailElements.forEach(element => {
    const username = element.getAttribute('data-user');
    const domain = element.getAttribute('data-domain');
    element.addEventListener('click', function(e) {
      e.preventDefault();
      window.location.href = `mailto:${username}@${domain}`;
    });
    element.innerHTML = `${username}@${domain}`;
  });
});

Then in your HTML:

<a href="#" class="email-protect" data-user="info" data-domain="example.com">Contact Us</a>

2. HTML Entity Encoding

Convert the email address characters to HTML entities to confuse bots:

<a href="&#109;&#97;&#105;&#108;&#116;&#111;&#58;&#105;&#110;&#102;&#111;&#64;&#101;&#120;&#97;&#109;&#112;&#108;&#101;&#46;&#99;&#111;&#109;">&#105;&#110;&#102;&#111;&#64;&#101;&#120;&#97;&#109;&#112;&#108;&#101;&#46;&#99;&#111;&#109;</a>

This renders as a normal "info@example.com" link to humans but is harder for bots to parse.

3. CSS Direction Reversal

Use CSS to display the email in reverse and then flip it with CSS:

<style>
  .email-reverse {
    unicode-bidi: bidi-override;
    direction: rtl;
    display: inline-block;
  }
</style>
<span class="email-reverse">moc.elpmaxe@ofni</span>

4. Image Replacement

Replace text emails with images containing the address:

<img src="/images/contact-email.png" alt="Contact our team" width="180" height="20">

Remember to provide alternative text for accessibility.

5. Contact Forms: The Best Solution

The most effective approach is to use a contact form instead of displaying email addresses directly. This provides several benefits:

No email addresses are exposed in the HTML

You can implement CAPTCHA or other bot prevention

Forms can include validation and required fields

You can direct inquiries to the right department automatically

6. Implementation Example

Here's a complete example you can adapt for your site:

document.addEventListener('DOMContentLoaded', function() {
  // Email protection function
  function setupEmailProtection() {
    const emailMap = {
      'info': ['info', 'example.com'],
      'support': ['support', 'example.com'],
      'sales': ['sales', 'example.com']
    };

    for (const [id, parts] of Object.entries(emailMap)) {
      const element = document.getElementById(`email-${id}`);
      if (element) {
        // Create a text node with the email address
        const emailText = document.createTextNode(`${parts[0]}@${parts[1]}`);
        element.appendChild(emailText);

        // Set up the click handler
        element.addEventListener('click', function(e) {
          e.preventDefault();
          window.location.href = `mailto:${parts[0]}@${parts[1]}`;
        });
      }
    }
  }

  // Call function when page loads
  setupEmailProtection();
});

Protecting your email addresses from spam bots is an essential part of maintaining a professional web presence. By implementing one or more of these techniques, you can significantly reduce unwanted spam while keeping your contact information accessible to legitimate users.

At the end of the day, no solution is 100% bot-proof, so consider using multiple layers of protection for sensitive contact information. For critical applications, contact forms with proper spam protection remain the gold standard.

Kendo React Component Playground: A simple app to test React Components, including Kendo Components

websilvercraft — Mon, 24 Mar 2025 01:07:10 +0000

What I Built

I created Kendo React Component Playground, a web application designed to allow developers to write, test, and preview React components in real-time, with a focus on showcasing KendoReact’s free components.

I created this web app both as a learning tool and a creative sandbox, to be able to

quickly test React components and see immediate results.

Key features include:

A list of example snippets (e.g., simple buttons, counters, and KendoReact-specific components) that users can load into the editor.
A code editor where users can write or modify React code.
A live preview pane that renders the code output, with loading states and error notifications.
Theme toggling between light and dark modes.
Responsive design and accessibility considerations.

Live Demo: Kendo React Playground

Kendo Components Usage

I used more than 10 Kendo React free components to build the React Component Playground. Here’s how I used each component:

Button: Used for the "Run" and "Reset" actions in the editor toolbar, providing clear calls-to-action with the themeColor prop for styling (e.g., primary for Run, base for Reset).
Switch: Implemented in the top toolbar to toggle between light and dark themes, enhancing user customization and accessibility.
DropDownList: Initially considered for example selection, but replaced with a custom list for styling flexibility; still explored in example snippets to demonstrate its utility.
TextArea: Serves as the code editor, allowing users to input and edit React code with a monospace font and flexible sizing.
Card and CardBody: Wraps the preview area, providing a clean container for rendered components with subtle shadows for depth.
Notification and NotificationGroup: Displays success, error, or info messages (e.g., "Component rendered successfully!" or error details) in a fixed bottom-right position, enhancing user feedback. Loader: Shown in the preview area during code execution, using the infinite-spinner type to indicate processing.
GridLayout and GridLayoutItem: Structures the entire UI into a responsive three-column layout (examples, editor, preview), with precise row and column definitions for consistency across screen sizes.
Toolbar and ToolbarItem: Creates a top navigation bar with the app title and theme switch, and an editor toolbar with action buttons, ensuring intuitive navigation.
ToolbarSpacer: Adds spacing in the toolbar to align items aesthetically.

Here is how i used the components:

Toolbar: Houses the Playground title, theme toggle, and primary actions.
GridLayout: Provides a responsive 3-column layout for examples, code editor, and preview.
Card: Contains the preview window, giving it a clean, modern look.
Nptification & Loader: Offers user feedback (i.e., success/error messages, loading spinner).

The KendoReact library simplified the development process by providing many components, allowing me to focus on functionality and design.

A small guide to get started with the favorite UI Library in Next JS

websilvercraft — Tue, 11 Mar 2025 13:20:38 +0000

Top 10 Next.js UI Libraries for Modern Web Apps

websilvercraft ・ Mar 11

#webdev #javascript #nextjs #tailwindcss

Top 10 Next.js UI Libraries for Modern Web Apps

websilvercraft — Tue, 11 Mar 2025 11:19:37 +0000

Hey everyone, ready to build a sleek Next.js app? In this post, I'll show you how to get started a Next.js with some of the most popular UI libraries for responsive, modern designs.

Here are the most popular Next.js UI libraries:

1. Tailwind CSS

Highly customizable utility-first CSS framework.
Rapid development and responsive design.
Tailwind CSS

2. shadcn/ui

A popular set of reusable UI components built with Tailwind CSS and Radix UI.
Modern, accessible, customizable, and designed specifically for Next.js.
shadcn/ui

3. Chakra UI

Simple, modular, and accessible component library.
Easy theming and supports both dark and light modes.
Chakra UI

4. Mantine

Rich, responsive, and accessible UI components.
Strong support for hooks and easy to customize.
Mantine

5. NextUI

Beautiful, modern, and highly customizable components optimized for Next.js.
Dark mode support, excellent developer experience.
NextUI

6. Material UI (MUI)

Robust, mature UI library implementing Google’s Material Design.
Wide array of components and excellent documentation.
Material UI

7. Radix UI

Low-level UI component library focused on accessibility and composability.
Frequently combined with other libraries (e.g., Tailwind or shadcn/ui).
Radix UI

8. Ant Design

Enterprise-level UI design system.
Rich set of components and clear design guidelines.
Ant Design

9. Headless UI

Completely unstyled, accessible UI components designed for integration with Tailwind CSS.
Allows maximum flexibility and customization.
Headless UI

10. Flowbite

Built upon Tailwind CSS, offers interactive and responsive components with good integration with Next.js.
Flowbite

Getting Started with Next.js and Tailwind CSS (Built-In)

Step 1: Create a New Next.js Project

Run the following command and follow the interactive prompts:

npx create-next-app@latest my-tailwind-app

During setup, you can choose options like TypeScript and ESLint. When prompted about styling, select Tailwind CSS. This option configures Tailwind automatically.

Step 2: Review the Pre-Configured Files

After the setup, your project will include:

tailwind.config.js – Your Tailwind configuration.
postcss.config.js – Configures PostCSS for processing Tailwind.
styles/globals.css – Already set up with the Tailwind directives:

  @tailwind base;
  @tailwind components;
  @tailwind utilities;

This means Tailwind CSS is fully integrated without extra manual steps.

Step 3: Run Your Development Server

Start your development server with:

npm run dev

Then open http://localhost:3000 in your browser to see your new Next.js app styled with Tailwind CSS.

Getting started with Next.js app and shadcn/ui:

Here's a clear, step-by-step guide to starting a new Next.js app with shadcn/ui:

Step 1: Set up Next.js project

Create a new Next.js application:

npx create-next-app@latest my-app

During setup, you’ll be asked a few questions. You can select:

App Router: Yes
TypeScript: Yes
ESLint: Yes
Tailwind CSS: Yes
src/ directory: Optional (recommended: Yes)

Step 2: Navigate into your project folder

cd my-app

Step 3: Install dependencies for shadcn/ui

npx shadcn-ui@latest init

This command will guide you through initializing shadcn/ui:

Choose your project path (default: ./ or src/)
Select your preferred style: Default
Choose a base color for your theme (default is fine)
Accept installing dependencies automatically.

This will install:

class-variance-authority
clsx
tailwind-merge
lucide-react

Step 4: Add components with shadcn/ui

Use the CLI to add UI components like buttons, cards, forms, and navigation elements.

For example, to add a Button component:

npx shadcn@latest add button

Other popular examples:

npx shadcn@latest add card
npx shadcn@latest add input
npx shadcn@latest add dropdown-menu
npx shadcn@latest add input button card alert skeleton scroll-area tabs button dialog tooltip

Step 5: Use components in your pages

Example usage of Button component in a Next.js page:

// app/page.tsx
import { Button } from "@/components/ui/button";

export default function Home() {
  return (
    <main className="flex min-h-screen items-center justify-center">
      <Button variant="default">Click me</Button>
    </main>
  );
}

Step 6: Run your app

Start your development server:

npm run dev

Visit your app at http://localhost:3000.

Optional but recommended tools:

Framer Motion for animations:

npm install framer-motion

Recharts for charting needs:

npm install recharts

Next.js with Chakra UI

Here's a step-by-step guide to integrating Chakra UI into a Next.js project:

Step 1: Create a New Next.js Project

If you haven’t already created a project, run:

npx create-next-app@latest my-chakra-app

Follow the prompts to set up your project (you can choose TypeScript, ESLint, etc., as needed).

Step 2: Install Chakra UI and Its Peer Dependencies

Navigate into your project directory:

cd my-chakra-app

Then install Chakra UI along with its required packages:

npm install @chakra-ui/react @emotion/react @emotion/styled framer-motion

Step 3: Set Up the Chakra Provider

To enable Chakra UI across your app, wrap your application with the ChakraProvider. If you're using the Pages Router, modify your pages/_app.js (or _app.tsx for TypeScript):

// pages/_app.js
import { ChakraProvider } from '@chakra-ui/react'

function MyApp({ Component, pageProps }) {
  return (
    <ChakraProvider>
      <Component {...pageProps} />
    </ChakraProvider>
  )
}

export default MyApp

If you're using the App Router (Next.js 13+), wrap your layout in the provider:

// app/layout.tsx (or .jsx)
import { ChakraProvider } from '@chakra-ui/react'

export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <body>
        <ChakraProvider>{children}</ChakraProvider>
      </body>
    </html>
  )
}

Step 4: Use Chakra UI Components

Now you can import and use Chakra UI components in your pages or components. For example, update your pages/index.js (or app/page.tsx) with a simple button:

// pages/index.js
import { Button, Box, Heading } from '@chakra-ui/react'

export default function Home() {
  return (
    <Box p={8} textAlign="center">
      <Heading mb={4}>Welcome to Chakra UI</Heading>
      <Button colorScheme="teal">Click Me</Button>
    </Box>
  )
}

Step 5: Run Your Application

Start your development server with:

npm run dev

Visit http://localhost:3000 to see your Chakra-powered Next.js app in action.

Additional Tips

Customization: Chakra UI allows you to customize themes easily. You can extend the default theme by creating a custom theme file and passing it to ChakraProvider.
Responsive Design: Leverage Chakra’s built-in responsive styles to design for various screen sizes effortlessly.
Accessibility: Chakra components are designed with accessibility in mind, making it easier to build inclusive web applications.

You can start with thia setup to have a robust foundation to build modern, accessible, and responsive user interfaces with Chakra UI in Next.js.

How to use traits in laravel

websilvercraft — Tue, 11 Feb 2025 13:21:34 +0000

How to Use Traits in Laravel

websilvercraft ・ Feb 11

#laravel #php #designpatterns #webdev

How to Use Traits in Laravel

websilvercraft — Tue, 11 Feb 2025 13:21:08 +0000

In Laravel, traits are a mechanism for reusing code across different classes, helping avoid duplication and making your code more modular. Traits is actually a PHP feature introduced in PHP 5.4 which allows to group functionality in a reusable unit and inject it into multiple classes, effectively sharing methods or properties among unrelated classes.

What is a Trait?

When you use a trait in a class, it effectively injects the methods and properties defined in that trait into the class. This way, the class gains the capability of those methods as if they were defined within the class itself.

The concept of reusing modular pieces of code across different classes, like PHP traits is similar to what C++ multiple inheritance represents, is often referred to as "mixin" in object-oriented programming (OOP). This term is generally agnostic of specific programming languages.

Unlike multiple inheritance, which allows a class to inherit directly from more than one base class, mixins often serve as a way to add discrete, shared functionality without creating potentially confusing inheritance structures.

Key Features of Traits:

Code Reusability: Traits help share common functionality, avoiding repetition.
Avoiding Inheritance Limitations: PHP only supports single inheritance, which means a class can extend only one other class. Traits help overcome this limitation by allowing a class to use multiple traits, effectively bringing in the benefits of multiple inheritance.

Defining and Using Traits:

To define a trait in Laravel, you use the trait keyword. Here is an example:

<?php

namespace App\Traits;

trait LoggerTrait
{
    public function logMessage($message)
    {
        \Log::info($message);
    }
}

You can then use the trait in a class by using the use keyword:

<?php

namespace App\Models;

use App\Traits\LoggerTrait;

class Order
{
    use LoggerTrait;

    public function processOrder()
    {
        // Log an informational message
        $this->logMessage('Processing the order');
    }
}

In the example above, LoggerTrait has a logMessage method, which is then included in the Order class via the use statement. This makes the logMessage() method available to the Order class without needing to inherit from a base class.

When to Use Traits in Laravel:

Shared Utility Functions: When you have utility functions like logging, handling dates, or other shared functionality.
DRY (Don't Repeat Yourself): If you find similar methods being used in multiple classes, it’s a good idea to extract those into a trait.
Multiple Class Usage: When functionality needs to be added to multiple, unrelated classes, traits are a good solution.

Example in Laravel:

Laravel itself uses traits extensively. For instance:

Notifiable Trait: Used for sending notifications in models.
SoftDeletes Trait: Allows models to perform soft deletes, meaning they aren’t permanently removed from the database.

Here’s an example of using the Notifiable trait in a User model:

<?php

namespace App\Models;

use Illuminate\Notifications\Notifiable;
use Illuminate\Foundation\Auth\User as Authenticatable;

class User extends Authenticatable
{
    use Notifiable;

    // Other model properties and methods
}

By using Notifiable, the User model can easily send notifications using email, SMS, or other channels.

Key Advantages:

Code Reuse: Easily share methods between different models or classes without copy-pasting.
Better Organization: Keeps your codebase clean by splitting functionality into reusable components.
Flexibility: Allows you to combine traits as per class requirements without dealing with inheritance restrictions.

Traits are powerful tools that enhance code reuse and help to write clean, organized, and DRY code, making them a significant feature in Laravel development.

Forem: websilvercraft

Agentic patterns and architectural approaches in AI

How does Drizzle handle migrations - Part 1

If things get out of sync

TL;DR

What is Zod and what does it bring over typescript type definitions

The Core Difference: Compile-Time vs Runtime

TypeScript Types = Compile-Time Only

Zod = Runtime Validation + Type Inference

What Zod Adds: The Advantages

1. Runtime Safety for External Data

2. Single Source of Truth

3. Rich Validation Beyond Types

4. Transformation and Coercion

5. Better Error Messages

6. Composability

Real-World Example: Your HeadingAnalyzer

When You NEED Zod

When TypeScript Types Are Enough

Same Fetch, Different Streams: duplex: 'half' in Node vs Cloudflare Workers

What differs with streams

Tiny patterns

Node: adapt IncomingMessage → Request (streaming upload)

Node: write a streamed Response back to ServerResponse

Workers: streaming is Web-Streams-native

Rules of thumb

What’s the `Request` object in the browser, Cloudflare, and Node?

Where it comes from

Why you don’t import it in Node

TypeScript tip

A tiny sanity check

One router, two runtimes: itty-router on Cloudflare Workers and Node

The shared router (one codepath)

Cloudflare Worker entry (zero glue)

Node adapter (a tiny bridge)

TypeScript tip

Why this works so well

Quick curl test

Gotchas & guardrails

How to Protect Email Addresses from Spam Bots

1. JavaScript Email Obfuscation

2. HTML Entity Encoding

3. CSS Direction Reversal

4. Image Replacement

5. Contact Forms: The Best Solution

6. Implementation Example

Kendo React Component Playground: A simple app to test React Components, including Kendo Components

What I Built

Key features include:

Live Demo: Kendo React Playground

Kendo Components Usage

A small guide to get started with the favorite UI Library in Next JS

Top 10 Next.js UI Libraries for Modern Web Apps

websilvercraft ・ Mar 11

Top 10 Next.js UI Libraries for Modern Web Apps

1. Tailwind CSS

2. shadcn/ui

3. Chakra UI

4. Mantine

5. NextUI

6. Material UI (MUI)

7. Radix UI

8. Ant Design

9. Headless UI

10. Flowbite

Getting Started with Next.js and Tailwind CSS (Built-In)

Step 1: Create a New Next.js Project

Step 2: Review the Pre-Configured Files

Step 3: Run Your Development Server

Getting started with Next.js app and shadcn/ui:

Step 1: Set up Next.js project

Step 2: Navigate into your project folder

Step 3: Install dependencies for shadcn/ui

Step 4: Add components with shadcn/ui

Step 5: Use components in your pages

Step 6: Run your app

Optional but recommended tools:

Next.js with Chakra UI

Step 1: Create a New Next.js Project

Step 2: Install Chakra UI and Its Peer Dependencies

Node: adapt `IncomingMessage` → `Request` (streaming upload)

Node: write a streamed `Response` back to `ServerResponse`