DEV Community: Time Pass

Complete Guide: Building an Automated Blog Publishing System with n8n

Time Pass — Thu, 03 Sep 2026 16:19:00 +0000

Complete Guide: Building an Automated Blog Publishing System with n8n

If you're a developer who blogs, you know the struggle: you write the content, but formatting, tagging, and uploading it to multiple platforms is a tedious chore.

In this guide, we will set up a robust, end-to-end automation in n8n that converts a raw idea into a professional, formatted Markdown article ready for publication on platforms like Dev.to, Hashnode, or your personal Ghost site.

The Automation Workflow

Trigger: Receive a request from a Google Sheet, Notion page, or Webhook.
AI Drafting: Use OpenAI (GPT-4) to structure and write the content.
Formatting: Use a Code node to apply custom frontmatter and cleaning.
Publishing: Automatically push to your destination platform (Dev.to/GitHub).

Step-by-Step Setup

Step 1: The Trigger

Create a new workflow and add the Webhook node. This will be your input gateway.

Set it to POST.
This allows you to trigger your workflow from a Notion "Publish" button or a simple terminal curl command.

Step 2: Content Generation (OpenAI)

Drag an OpenAI node onto the canvas. Use the Chat resource.

System Prompt: "You are a technical editor. Write detailed articles in Markdown. Use H2 headers, include code blocks for technical examples, and summarize key concepts at the end."
User Prompt: Pass the data from your webhook as the input topic.

Step 3: Standardizing with a Code Node

Standardization is key. Add a Code node to wrap your generated content with metadata (Frontmatter) required by your site.

// Ensure every post has standard frontmatter
const frontmatter = `--- 
title: ${items[0].json.title}
date: ${new Date().toISOString()}
tags: ["development", "automation"]
---

`;

return {
  title: items[0].json.title,
  body: frontmatter + items[0].json.generated_content
};

Step 4: The Publishing Engine (Dev.to API)

Use the HTTP Request node to push the draft to Dev.to.

URL: https://dev.to/api/articles
Method: POST
Headers: api-key: YOUR_DEVTO_KEY
Send Body: true
Body Content:

{
  "article": {
    "title": "{{ $json.title }}",
    "body_markdown": "{{ $json.body }}",
    "published": false
  }
}

Why This Approach Wins

Platform Agnostic: You can duplicate the last step in your n8n workflow to push to both Dev.to and your personal site simultaneously.
Error Handling: Use n8n's "Error Trigger" to get a Slack or Discord alert if the AI fails or the API goes down.
Modularity: Want to change your publishing platform? You only need to swap the final HTTP Request node—the rest of your AI pipeline stays exactly the same.

Finalizing Your Setup

Test: Use the 'Execute Workflow' button in the n8n editor with sample JSON.
Activate: Toggle the Active switch in the top right to turn the webhook live.
Refine: As you use it, tweak your System Prompt in the OpenAI node. Adding specific examples of your own writing style to the prompt will make the AI output feel more human over time.

By treating your blog content as data flowing through an infrastructure pipeline, you move from manual effort to a scalable, professional content strategy.

Build Your Own AI Personal Assistant: Automating Calendars with n8n and MCP

Time Pass — Wed, 02 Sep 2026 18:03:21 +0000

Build Your Own AI Personal Assistant: Automating Calendars with n8n and MCP

Ever wish you had an AI that could check your schedule, find gaps, and book meetings without you clicking through endless UI menus? By combining n8n (for workflow orchestration) and the Model Context Protocol (MCP), you can create a private, self-hosted calendar agent that actually does the work for you.

The Architecture

n8n: The heavy lifter that handles API connectivity (Google Calendar, Outlook, Slack).
MCP Server: A bridge that exposes your calendar data as "tools" to any AI agent.
AI Agent (e.g., Goose or Claude): The brain that understands your natural language request and calls the tools provided by n8n.

Step-by-Step Setup

1. Build the n8n Workflow

Create an n8n workflow that performs specific actions, such as listEvents or createEvent.

Use the Webhook Node as the entry point.
Set the HTTP method to POST.
Configure it to return JSON data so your AI agent can parse the results easily.

2. Create the MCP Wrapper

Since n8n provides a webhook, you can create a simple MCP server that acts as a proxy, sending requests to your n8n webhook URL.

// A snippet of an MCP tool definition for your server
{
  name: "n8n_calendar_query",
  description: "Query the calendar via n8n",
  inputSchema: {
    type: "object",
    properties: {
      action: { type: "string", enum: ["list", "book"] },
      details: { type: "string" }
    }
  }
}

3. Connect the Agent

Configure your AI desktop client (like Goose or Claude Desktop) to point to your new MCP server.

{
  "mcpServers": {
    "calendar-agent": {
      "command": "node",
      "args": ["/path/to/mcp-n8n-proxy.js"]
    }
  }
}

Practical Automation Workflow

Once connected, your interaction loop looks like this:

You: "Check if I'm free on Friday and book a 1-hour focus session."
AI Agent: Calls your n8n_calendar_query tool with action: "list".
n8n: Executes the Google Calendar node, returns the free slots.
AI Agent: Sees the open slots, chooses one, and calls action: "book".
n8n: Updates the calendar via the Google Calendar API.

Why This Workflow Rocks

Security: Your calendar credentials live inside your self-hosted n8n instance, not in an AI vendor's cloud.
Extensibility: Want to add Slack notifications? Just add a Slack node to your n8n workflow. The AI agent doesn't even need to know the implementation changed.
Debuggability: Use n8n's visual execution history to see exactly why an agent failed to book a meeting.

Best Practices

Rate Limiting: Ensure your n8n webhook has basic authentication (Header Auth) to prevent unauthorized triggers.
Confirmations: For critical actions (like deleting events), configure your agent to always ask for human approval before triggering the n8n webhook.
Schema Precision: The more descriptive your inputSchema is, the better the LLM will be at filling in parameters like start_time or attendees.

Supercharge Your Local AI: A Guide to MCP and Goose

Time Pass — Wed, 02 Sep 2026 17:56:29 +0000

Supercharge Your Local AI: A Guide to MCP and Goose

If you've been following the AI space, you've likely heard of MCP (Model Context Protocol). But how do you actually put it to work in your daily development workflow? Enter Goose, an open-source AI agent by Block that turns your terminal into a powerful, tool-aware assistant.

What is Goose?

Goose is a desktop agent that acts as a command center for your local environment. It leverages MCP to connect to your local files, databases, and system tools, allowing the AI to actually perform work rather than just generating text.

The MCP Advantage

By using MCP, Goose is essentially "plug-and-play." You don't need to write custom integration scripts for every new tool you want your AI to use. You simply install an MCP server (e.g., for SQLite, GitHub, or Postgres), and Goose automatically discovers it.

Getting Started with Goose

1. Installation

Goose runs directly from your terminal. Ensure you have Go installed, then:

# Install the Goose CLI
brew install block/tap/goose

# Initialize Goose in your project
goose init

2. Adding MCP Servers to Goose

Goose uses a configuration file to know which MCP servers to run. You can add them to your ~/.config/goose/config.yaml:

mcpServers:
  sqlite:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-sqlite", "--dbPath", "/path/to/db.sqlite"]
  github:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-github"]

3. Workflow: Letting the Agent Work

Once configured, you can start a session and give the AI access to your tools:

goose session

Inside the session, you can ask natural language questions like:

"Search my GitHub issues for anything related to the authentication bug."
"Query the users table in my local sqlite DB and report on the last 5 signups."
"Fix the code formatting in main.go and run the tests."

Why This Combination Wins

Contextual Awareness: Because Goose talks to your local filesystem via MCP, it isn't guessing your file structure. It reads it.
Agentic Capability: Instead of just outputting a diff, Goose can execute shell commands (go test, git commit) to resolve tasks, providing a true "Agentic" experience.
Safety: Because the MCP servers run locally (usually via stdio), your data does not need to be uploaded to a third-party cloud service just to be "processed" by an AI.

Pro-Tips for Power Users

Environment Variables: You can pass API keys safely to your MCP servers via the env block in the goose config.yaml.
Tool Filtering: If you have many tools, explicitly list the ones you want Goose to have access to in the configuration to keep the AI's context clean.
Chain Commands: Use Goose to bridge tools—for example, fetching data from a database and piping it directly into a script that formats it for a GitHub pull request.

Conclusion

The marriage of MCP and local agents like Goose is the future of developer tooling. We are moving away from "chatting with code" to "collaborating with machines" that can actually execute the work. Set up your first MCP server today and watch how much faster your local iteration cycle becomes.

Stop Over-Engineering: A Pragmatic Approach to Microservices with Go

Time Pass — Wed, 02 Sep 2026 17:26:33 +0000

Stop Over-Engineering: A Pragmatic Approach to Microservices with Go

Microservices are often sold as the silver bullet for scaling. In reality, they are often a recipe for "distributed monolith" nightmares. If you are starting a new project, how do you build modular systems that don't crumble under the weight of their own complexity?

The Philosophy: Start with Modules, Not Services

Instead of splitting your code into separate repositories and network boundaries on day one, start with a modular monolith. This allows you to enforce boundaries while keeping the deployment lifecycle simple.

Structure Your Code for Future Growth

Use a clean architecture approach to ensure that your business logic is decoupled from your infrastructure. Here is a recommended directory structure:

/cmd           # Entry points for your application
/internal      # Private application code
  /user        # User domain logic
  /order       # Order domain logic
/pkg           # Public library code
/api           # API definitions (Protobuf/OpenAPI)

Implementation Example: Decoupled Domain Logic

In Go, you can use interfaces to ensure that your services don't depend on implementation details. This makes it trivial to split them into separate microservices later if necessary.

// internal/user/service.go
package user

type Repository interface {
    GetByID(id string) (*User, error)
}

type Service struct {
    repo Repository
}

func (s *Service) GetUser(id string) (*User, error) {
    return s.repo.GetByID(id)
}

Why this works

Low Friction: You can iterate fast without updating network contracts or handling partial failures.
Easy Refactoring: Because your domains are separated by Go packages (not network calls), refactoring is as simple as moving a folder.
Deployment Ready: When the time comes to scale, you can extract a package into a standalone binary in an afternoon because your dependencies are already explicitly defined via interfaces.

Final Thoughts

Don't build a microservice architecture before you have a service worth micro-sizing. Build for modularity first, and scale your infrastructure only when the business requirements demand it.

Mastering Background Jobs: A Developer's Guide to BullMQ

Time Pass — Tue, 25 Aug 2026 08:07:10 +0000

Mastering Background Jobs: A Developer's Guide to BullMQ

In modern web development, you should never make your user wait for a slow task. If a user uploads a video, sends an email, or triggers an AI analysis, your web server should say "got it" immediately and handle the work in the background.

To do this, you need a Message Queue. In the Node.js ecosystem, BullMQ is the gold standard for high-performance, distributed job queues.

What is BullMQ?

BullMQ is a Node.js library that implements a persistent job queue system based on Redis. It allows you to create producers (who add jobs) and workers (who process them) that can scale across multiple servers.

Why use it?

Persistence: If your server crashes, your jobs are still safely stored in Redis.
Scalability: You can run dozens of workers across different containers to process jobs in parallel.
Reliability: It supports retries, rate limiting, and delayed jobs out of the box.

The Core Architecture

The Queue: The central hub where jobs are stored.
The Producer: The code that adds a job to the queue (e.g., inside a controller).
The Worker: A separate process that watches the queue and executes the task.

Code Example: Processing Emails in the Background

1. The Producer (in your Express controller)

const { Queue } = require('bullmq');

const emailQueue = new Queue('email-queue');

// Add a job to the queue
await emailQueue.add('sendWelcomeEmail', { 
  email: 'user@example.com', 
  name: 'John Doe' 
});

2. The Worker (a separate background process)

const { Worker } = require('bullmq');

const worker = new Worker('email-queue', async (job) => {
  console.log(`Sending email to: ${job.data.email}`);
  // Simulate slow operation (e.g., calling an API)
  await sendEmailAPI(job.data.email);
}, { connection: redisConnection });

Pro-Level Features

BullMQ isn't just for basic tasks. It excels at complex production requirements:

Delayed Jobs: Want to send a follow-up email in 24 hours? emailQueue.add('followUp', data, { delay: 86400000 });
Retries: If your email API is down, BullMQ can automatically retry the job with exponential backoff.
Concurrency: You can tell a worker to process 5, 10, or 50 jobs at the same time depending on your CPU power.
Rate Limiting: Protect your external APIs! Configure your queue to only send 10 requests per second to avoid getting banned.

When should you use BullMQ?

Heavy Computation: Video processing, image resizing, data transformation.
External API Integrations: Sending emails, posting to social media, or calling third-party services that might be slow or unstable.
AI Workflows: When using Agentic AI, use BullMQ to manage the "steps" the AI needs to take so your web server doesn't freeze up.

Summary

If your application is doing anything that takes more than 100ms, it belongs in a background queue. BullMQ provides the reliability of a professional-grade message broker with a developer-friendly API. It effectively separates your user's experience (which must be fast) from your application's heavy lifting (which can happen whenever).

By adding BullMQ to your stack, you move from building fragile, synchronous apps to building robust, distributed systems.

What is Redis? The Developer’s Secret Weapon for Lightning-Fast Apps

Time Pass — Tue, 25 Aug 2026 07:56:59 +0000

What is Redis? The Developer’s Secret Weapon for Lightning-Fast Apps

If your database is the library where you store all your books, Redis is the desk right in front of you where you keep the one book you are reading right now.

Redis (Remote Dictionary Server) is an in-memory data structure store. It is famously fast because, unlike traditional databases (SQL/NoSQL) that write to disk, Redis stores everything in your computer's RAM.

Why is Redis so fast?

Traditional databases store data on an SSD or HDD. Reading from a disk is fast, but reading from RAM is orders of magnitude faster. Redis delivers sub-millisecond response times, making it the perfect choice for high-performance applications.

Common Use Cases

Redis is rarely used as a "primary" storage for all your data (like user profiles or financial logs). Instead, it is used for high-velocity tasks:

1. Caching (The most common use)

When a user requests a popular page (e.g., the "Trending" feed), don't query your heavy SQL database every time. Cache the result in Redis for 5 minutes. The user gets their data instantly, and your database gets a much-needed break.

2. Session Management

Storing user session tokens (login states) in RAM allows your web server to verify a user's identity instantly on every single page request without looking up a heavy database table.

3. Real-Time Leaderboards

Redis has a special data type called a Sorted Set. This makes it incredibly easy to keep track of rankings in real-time (e.g., top scores in a game) without recalculating the entire table every time a point is scored.

4. Pub/Sub (Message Broker)

Redis acts as a high-speed communication channel. One service can "publish" a message (e.g., "User Uploaded Photo"), and other services can "subscribe" to that topic to trigger their own logic.

Simple Example: Caching in Node.js

Here is how you would use Redis to avoid hitting your main database:

const redis = require('redis');
const client = redis.createClient();

async function getProfile(userId) {
  // 1. Check Redis first
  const cachedProfile = await client.get(`user:${userId}`);
  if (cachedProfile) return JSON.parse(cachedProfile);

  // 2. If not in cache, fetch from SQL Database
  const profile = await db.query('SELECT * FROM users WHERE id = ?', [userId]);

  // 3. Save to Redis for next time (expire after 60 seconds)
  await client.setEx(`user:${userId}`, 60, JSON.stringify(profile));

  return profile;
}

Key Concepts to Remember

In-Memory: Because it lives in RAM, if you turn the server off, the data disappears. Redis does have features for "persistence" (writing to disk), but it's primarily designed for speed.
Key-Value Store: Redis is a giant dictionary. You store a value (string, list, set, or hash) under a unique key.
Atomic Operations: Redis handles operations very safely, ensuring that even under massive load, your data doesn't get corrupted.

Is Redis right for your project?

Use Redis if: You have a performance bottleneck, you need real-time data, or you need to manage fast-moving state (like session tokens).
Don't use Redis if: You need to store huge amounts of complex, relational data that must survive server reboots indefinitely (stick to PostgreSQL or MongoDB for that).

The Takeaway

Redis is the "turbos" for your application. By shifting the most frequent, smallest requests into RAM, you can make an application that feels snappy and responsive to thousands of users, regardless of how slow your main database might be. It’s an essential tool in every modern backend engineer’s toolkit.

System Design for Developers: How to Build Scalable, Real-World Architecture

Time Pass — Tue, 25 Aug 2026 07:34:56 +0000

System Design for Developers: How to Build Scalable, Real-World Architecture

Every junior developer knows how to write code that works on their laptop. But as a project grows from 10 users to 10,000,000, the "it works on my machine" mindset breaks. That is where System Design comes in.

System design is the process of defining the architecture, interfaces, and data for a system to satisfy specific requirements. It’s not just about code; it’s about trade-offs.

The Core Pillars of System Design

When designing a system, you are constantly balancing these three trade-offs:

1. Scalability: Horizontal vs. Vertical

Vertical Scaling: Upgrading your server (more RAM, better CPU). Easy to do, but has a hard ceiling.
Horizontal Scaling: Adding more servers. This is the industry standard (e.g., using an AWS Auto Scaling group).

2. Availability vs. Consistency (The CAP Theorem)

In a distributed system, you cannot have everything. You must choose:

Consistency: Every user sees the exact same data at the same time.
Availability: The system is always up and responsive, even if some data is slightly stale.

3. Latency vs. Throughput

Latency: How long does it take for one request to finish?
Throughput: How many requests can the system handle per second?

The Anatomy of a Scalable System

If you were building a service like Twitter or Instagram, your architecture would likely look like this:

Load Balancer: The traffic cop. It distributes incoming user requests across multiple web servers so no single server gets overwhelmed.
Database Sharding/Replication: You don't put all your data in one database. You split the data across multiple machines (sharding) or create read-only copies (replication) to handle heavy traffic.
Caching (Redis/Memcached): Don't go to the database if you don't have to. Store frequently accessed data (like a user’s profile) in memory for sub-millisecond retrieval.
Message Queues (Kafka/RabbitMQ): Decouple your services. If a user uploads a video, don't make them wait for the encoding process. Push the video to a queue and let a background worker handle it asynchronously.

Real-World Example: An AI-Powered Support System

Earlier, we talked about Agentic AI. How do we design a system for that?

The Problem: An AI agent performing complex research takes 30 seconds to run. If a user waits for that, the browser will timeout.
The System Design Solution:
- Step 1: User sends a request (Webhook).
- Step 2: The request is immediately acknowledged (HTTP 202 Accepted).
- Step 3: A Message Queue triggers an n8n workflow.
- Step 4: The Agent executes the task.
- Step 5: Once finished, the Agent sends a notification to the user via WebSockets or Push Notification.

This is System Design: You didn't just write a script; you designed a resilient, asynchronous pipeline that protects the user experience.

How to Level Up Your System Design Skills

Read "Designing Data-Intensive Applications": This is the "bible" of modern system design.
Practice on "Grokking the System Design Interview": Even if you aren't interviewing, these exercises teach you how to think about building complex features.
Analyze Real Failures: Look at "Post-mortems" from tech giants like AWS or Cloudflare. Learn why their systems failed and how they fixed them.

Summary

System design is the art of managing complexity. As you build your career, remember:

Start simple. Don't over-engineer a system before you have users.
Identify bottlenecks. Use logs and metrics to find where your system is slow.
Design for failure. Assume your database will crash, your network will lag, and your third-party APIs will time out. Build your system so it handles these gracefully.

Scalability isn't a feature you add at the end; it is a design philosophy you bake into every line of code.

AI Agents vs. Agentic AI: Moving from Task-Execution to Autonomous Reasoning

Time Pass — Tue, 25 Aug 2026 07:22:02 +0000

AI Agents vs. Agentic AI: Moving from Task-Execution to Autonomous Reasoning

As we move past the "Chatbot Era" of AI, we are entering the "Agentic Era." But what is the difference between an AI Agent and Agentic AI?

While they are often used interchangeably, the distinction lies in the level of autonomy and complexity.

1. AI Agents: The "Tool Users"

An AI Agent is a system that uses an LLM as its "brain" to perform a specific task by interacting with external tools.

How it works: It uses a technique called "Function Calling." You give it a set of tools (e.g., search_google(), calculate_math(), send_email()). The LLM decides which tool to call based on the user's prompt.
Characteristics:
- Task-focused: They are built to complete a specific job.
- Limited Autonomy: They usually operate in a loop triggered by human input.
Example: A Slack bot that fetches the weather. The user asks, the Agent calls an API, the Agent returns the result. Once the result is returned, the agent's job is done.

2. Agentic AI: The "Autonomous Workers"

Agentic AI is the paradigm of designing systems that can perform complex, multi-step workflows with minimal human oversight. This isn't just about calling a tool; it's about planning, reasoning, and self-correction.

How it works: Instead of just responding to a prompt, an Agentic system breaks a high-level goal into a roadmap. It evaluates its progress, realizes if it made a mistake, and pivots its strategy autonomously.
Characteristics:
- Goal-oriented: You provide the "What," and the AI figures out the "How."
- Self-Correction: If a tool fails, it retries, looks for a different approach, or asks for clarification.
Example: A "Research Agent." You tell it: "Find the top 5 competitors for my startup and summarize their pricing."
- It decides which search queries to use.
- It visits sites and finds the pricing pages.
- If a site is blocked, it switches to a different search strategy.
- It compiles the final report on its own.

The Key Differences

Feature	AI Agent	Agentic AI (Workflows)
Scope	Single task/step	Multi-step goal
Planning	Minimal (Reacts to input)	Proactive (Builds a plan)
Error Handling	Stops/Fails	Self-corrects/Adjusts path
Analogy	A calculator app	A junior employee

The Architecture: Why it matters for Developers

If you are building with n8n or LangGraph, you are likely moving from "AI Agents" to "Agentic AI."

Simple Agent: Prompt -> LLM -> Tool -> Response
Agentic System: Goal -> [Planner Agent -> Executor Agent -> Critic Agent] -> Result

In an Agentic system, you have different "roles" for your AI. One agent acts as the Manager (planning the steps), one acts as the Worker (executing the code), and one acts as the Critic (checking the output for errors). If the Critic finds an error, it sends the task back to the Worker to fix.

Summary

AI Agent: A bridge between an LLM and the outside world (APIs).
Agentic AI: The application of those bridges to complex, unpredictable workflows.

We are shifting from building chatbots that answer questions to building systems that solve problems. The future of development isn't just writing code; it's designing the "Agentic Loops" that allow AI to learn, plan, and execute reliably in the real world.