DEV Community: Oyedele Temitope

How to Scale AI Development Beyond Prototype Speed

Oyedele Temitope — Fri, 22 May 2026 10:20:11 +0000

One thing that isn't talked about enough in AI right now is how easy it has become to mistake a working demo for a production-ready system.

You can build a working prototype in a few days, whether it's a chatbot that understands internal documents, a recommendation engine plugged into your product data or a document processor that cleans up messy inputs. It runs smoothly in a controlled environment, the demo lands well and the CEO immediately asks, "When can we ship this?"

That's usually when the real challenges start.

Today, 82 percent of developers use AI coding tools daily, yet the leap from working demo to deployed product has not accelerated at the same pace. In fact, 42 percent of companies abandoned most of their AI initiatives in 2025, up from just 17 percent the year before, according to S&P Global. Research from RAND Corporation suggests that roughly 80 percent of AI projects fail to reach production, about twice the failure rate of traditional IT initiatives.

Most teams can now demonstrate that an idea is feasible, but the real difficulty begins after that milestone. Even when a prototype performs well, its architecture is rarely tested under production conditions such as sustained user load, enforced security controls and regulatory oversight. As deployment approaches, integration friction surfaces, security reviews introduce scrutiny and compliance requirements reshape design decisions, exposing the fact that what worked in a sandbox was never engineered for production accountability.

The gap between a working system and a deployable system is where most AI initiatives quietly slow down. This article examines why moving from a working prototype to a production-ready system is difficult and outlines the structural shifts required to make that move successfully.

Why the Last Mile Is Harder Than It Looks

The real difference between a prototype and a production system isn't about polish. It's about the environment. A prototype runs in a controlled sandbox with a limited scope and a narrow objective. Production requires the system to become part of the company's operating infrastructure, which changes both the expectations and the level of accountability attached to it.

Moving from a sandbox environment to production changes the nature of the work because what feels like rapid progress during feasibility is simply the result of operating within a tightly contained scope. But once you aim for deployment, the system has to handle real traffic, fit with existing systems and meet governance standards that didn't matter during the demo. The key question becomes, "Can this reliably support the business?"

When teams bring stalled prototypes to us, we see the same pattern. The demo works, but it wasn't built to last. Often, there's no real backend, or the system uses tools chosen for speed rather than for alignment with the company's production setup. These choices make early progress easy but create integration problems that show up as soon as deployment is discussed.

The contrast becomes clearer when you lay the two out side by side:

	Prototype	Production
Reliability	Tolerates instability and manual fixes	Requires consistent uptime and predictable performance
Integration	Isolated or loosely connected to convenient tools	Integrates with identity providers, CRM/ERP and internal data pipelines
Compliance	Rarely considered during early build	Must satisfy GDPR, SOC 2 and industry requirements
Operations	Minimal monitoring, no rollback discipline	Requires monitoring, version control, rollback strategy and clear ownership

The Five Failure Patterns Killing AI Deployments

High failure rates show the problem is common, but they don't explain how things go wrong inside engineering teams. In reality, stalled AI projects usually follow five common patterns that show up soon after the first demo.

1. Pilot Paralysis

Many organizations start with a proof of concept but never plan how to move it into production. The first goal is to show it works, but after that progress slows because no one has mapped out how it will integrate, scale or run in the real world. Nearly half of AI proofs of concept never get deployed, not because the idea was bad but because the project wasn't set up to go beyond the demo. What seemed like progress ends up as a dead end, wasting time and resources.

2. Model Fetishism

Teams often get too focused on improving model metrics like F1 scores or latency while the work needed to embed the product piles up in the background. A model that works well on its own doesn't add value until it's part of a stable application and connected to real systems. By the time the bigger engineering work becomes urgent, earlier shortcuts usually need to be fixed, which delays deployment and pushes results further away.

3. The Quality Gap

Research from CodeRabbit shows that AI-generated code can have much higher defect rates than traditional code, with some studies finding up to 1.7 times more issues. Fast code generation speeds up prototyping, but it also means more work is needed to validate, test and strengthen the code before deployment.

In controlled tests, many of these problems stay hidden. But in real use, they show up as fragile behavior, missed edge cases, security risks and production issues that hurt confidence and add technical debt.

4. Disconnected Tribes

Misalignment between business and technical teams is a common reason AI projects fail. Usually, it's not because people refuse to work together but because the line between product goals and technical work gets blurry.

As AI tools make rapid generation seem easy, product owners and executives often add technical language directly into prompts and specifications. This causes requirements to mix architectural terms with business goals, and teams start debating implementation details before clarifying what the system should actually deliver. In many cases, getting clear on intent solves more problems than extra development because once the goal is clear, engineering decisions make more sense. When that clarity is missing, integration and compliance gaps often show up late, leading to costly rework and delayed deployment.

5. The Missing Operational Layer

Many AI systems are built without a clear plan for monitoring, rollback procedures or version control. This often goes unnoticed during the demo phase. But once real users rely on the system, the lack of monitoring and update controls creates operational risks.

Without clear monitoring, issues surface late and are harder to diagnose. Without tested rollback plans, teams hesitate to deploy updates. Without version discipline for model changes, regressions become difficult to trace. Over time, this slows release velocity and weakens confidence in the system.

What the 33% Who Succeed Do Differently

While failure rates are high, a minority of organizations consistently navigate the transition from prototype to production. Research from MIT Sloan Management Review and BCG highlights a clear contrast: internal AI builds succeed roughly 33 percent of the time, while initiatives involving strategic partnerships succeed at nearly 67 percent. That is effectively a twofold difference in reported success and reflects more than access to talent. It reflects structure.

What sets that minority apart isn't model complexity but how they manage the move to deployment.

In practice, partnerships bring objectivity. External engineers and experts are less affected by sunk cost bias and more willing to question unclear requirements or weak architectural choices made during prototyping. Instead of rushing to improve the demo, successful teams take time to clarify what the system really needs to deliver.

Being willing to refine requirements, not just outputs, changes the project's direction. The conversation moves from "What can the model generate?" to "What does the business actually need this system to do?" This alignment reduces integration problems and reveals compliance and infrastructure needs before they become obstacles.

In theory, organizations with strong infrastructure and clear requirements might be able to bring a system into production on their own. In reality, those conditions are rare once the complexity of deployment becomes clear. Teams that reach production aren't always more skilled. They are more deliberate. They see deployment as an engineering transition that requires clarity, teamwork and disciplined iteration, not just more experimentation.

The Production Deployment Methodology

When a prototype stalls, adding features rarely fixes the real issue because most failures at this stage come from gaps that were invisible during the demo. A production transition requires structure rather than more velocity. In practice, it should follow a four-phase methodology designed to bridge the gap between a successful experiment and a stable product.

Phase 1: Production Audit and Requirement Deconstruction

The first step is not writing code but reviewing the original prompt alongside the current output and business expectations. What looks like a model limitation is often a requirement problem, because business goals and technical assumptions tend to blur during rapid prototyping. This phase focuses on separating intent from implementation where clarifying constraints usually resolves issues that teams previously attributed to model behavior. This is also where common blind spots appear, such as missing integration paths or architectural shortcuts that were acceptable in a sandbox but are fragile in production.

Phase 2: Constraint Rebuild and Stability Testing

Once requirements are clarified, the system is rebuilt under stricter constraints to shift the focus from feasibility to resilience. The system is tested against change and infrastructure pressure to determine if it can tolerate updates or if it depends on manual fixes. This phase surfaces operational risk early before deployment magnifies it, asking what fails when real authentication and data flow are introduced.

Phase 3: Architectural Hardening

Only after the logic is stable does structural reinforcement begin. Prototypes are often tied to convenient tools that make early iteration easy but leave the eventual deployment fragile. The system is reorganized into modular components so that changes in one area do not cascade into others. Hope AI enables this by generating composable elements that fit within a broader architecture rather than isolated fragments. This ensures that iteration becomes controlled instead of disruptive.

Phase 4: Deployment Readiness Validation

The final phase validates production conditions before launch by introducing monitoring and defining rollback paths. Integration points are stress-tested and ownership boundaries are clarified to ensure the end goal is operational confidence rather than another demo. Production readiness is not a final polish step but the result of introducing discipline early enough that scaling does not expose hidden fragility.

The Hidden Cost of DIY

Keeping an AI deployment fully in-house often seems efficient at first, especially if the prototype already exists and the team knows the system. But the real costs show up once the prototype faces real infrastructure, governance and operational checks. These costs appear in a few predictable ways:

Time cost: Enterprise AI deployments often take months to stabilize, even after proving they work. This is mostly because teams have to fix the architecture, address compliance gaps and add monitoring that wasn't part of the original build.
Team cost: When senior engineers are pulled into fixing integration, designing monitoring and preparing for audits, their focus shifts away from core product work. This slows progress and reduces competitive advantage.
Failure cost: High-profile AI projects affect reputation. When deployment takes too long or systems fail in real use, executive confidence drops, and the organization becomes less willing to try new things.
Rework tax: Architectural shortcuts that speed up a prototype rarely survive compliance checks, security reviews or infrastructure alignment. Fixing them late often requires more work than building things right from the start.

The Path to Production: A Case Study in Engineering Validation

The value of this approach is clear when you apply it to a stalled prototype. A financial services company built a document-processing agent that could accurately summarize complex loan applications. The internal demo impressed leadership, who expected a quick launch. The real problems appeared as deployment got closer.

The system was built quickly using scripts connected to a hosted database that didn't meet the company's security standards. While the model worked well on its own, integrating it with existing workflows raised compliance issues and revealed performance problems. The architecture was never designed for the company's production environment.

The project started with a two-week production audit. Instead of blaming inconsistent outputs on the model, the team first looked at the original prompts and business logic. Many issues thought to be hallucinations were actually caused by unclear requirements and overloaded instructions. Clarifying intent fixed the instability before any architectural changes were made.

Once the requirements were clear, the system was rebuilt as modular components and integrated with the company's existing infrastructure. Monitoring was added, access controls were formalized and compliance needs were built into the design. Deployment only continued after these changes were validated.

The result was not a marginal improvement but a transition in system posture. Security review cycles were shortened, integration failures dropped significantly and the agent moved from an isolated proof of concept to a production-ready service embedded within the firm's operational workflow.

The Forward Deployed Engineering Advantage

Forward Deployed Engineering places experienced engineers directly into the deployment phase of complex systems, where feasibility ends and infrastructure reality begins. It adds value not by piling on features but by bringing structured validation when informal iteration is no longer sufficient. The advantages are practical and show up in specific ways:

External objectivity: Internal teams are often too close to a system to see the architectural shortcuts or requirement drift that have accumulated during rapid development. An external engineering partner evaluates the system with a specific mandate to identify the subtle issues that quietly block deployment.
Requirement discipline: Many production failures originate in ambiguous product logic rather than model capability. By separating business intent from technical implementation, FDE reduces confusion before it spreads into integration and compliance decisions.
Structural realignment: Instead of extending a brittle prototype, the focus shifts toward reorganizing the system so that components align with existing infrastructure and governance constraints.
Pre-deployment risk reduction: By addressing integration gaps, monitoring exposure and architectural fragility early, FDE reduces the likelihood of high-visibility deployment failures.

At Bit Cloud, Forward Deployed Engineering defines how systems move from feasibility to stability, ensuring they are reliable enough to ship and resilient enough to scale.

What to Do Next

The high failure rate of AI projects doesn't mean the technology is flawed. It shows the gap between a successful experiment and a stable product. Organizations that reach production know AI is rarely just about modeling. It is an engineering transition. Moving beyond the sandbox mindset takes validation, structure and discipline before scaling is possible.

The path to production doesn't have to be a long cycle of rework. It starts with a clear look at what you have now: Are the requirements clear? Does the architecture fit real infrastructure? Are integration and compliance built into the design or left for later?

If you're unsure about those questions, the next step isn't to add more features. It is to do a structured production assessment. At Bit Cloud, Forward Deployed Engineering is built for this stage, focusing on validating the architecture, clarifying requirements and ensuring you're ready to deploy before moving forward.

A careful review can reveal the exact gaps that are preventing a prototype from shipping and outline a practical path to stable deployment.

Possibility shows an idea can work. Engineering shows it can last.

AI code review checklist that actually catches problems

Oyedele Temitope — Fri, 22 May 2026 10:18:24 +0000

The two a.m. pager call is a rite of passage for many engineers, but the nature of those incidents is starting to change.

Picture this. You just finished reviewing a pull request that looked almost perfect. The logic was clean, the variable names were descriptive and the code even included comments explaining what each section was doing. The CI pipeline passed without a single failure, so you merged it with confidence and moved on to the next task.

A few hours later the alerts begin.

The service starts timing out, and requests begin to pile up faster than the system can handle. When the team traces the issue back to the code that shipped earlier, the problem turns out to be surprisingly subtle. The AI-generated function that looked so polished during review assumed the database would always have connections available. In staging that assumption held. In production, where thousands of requests arrive at the same time, the same logic quickly exhausts the connection pool.

This is the new reality of AI-assisted development. Teams are moving faster than ever, generating large portions of working code in minutes rather than hours. At the same time, they are encountering a different class of bugs. These issues look perfectly reasonable in isolation but behave very differently once they interact with real production environments.

This article explores why AI-generated code requires a different approach to review and introduces a practical checklist that engineering teams can use to catch the patterns these systems consistently introduce before the code reaches production.

TL;DR: AI Code Review Cheat Sheet

If you only have a few minutes to review an AI-generated pull request, focus on these five areas.

Category	Common AI Trap	What to Check
Logic and correctness	The "happy path" obsession	Add guard clauses for null values, empty inputs and edge cases. Verify error handling and control flow.
Security	Common but insecure coding patterns	Replace string concatenation with parameterized queries and verify authentication and authorization checks.
Performance	Inefficient algorithms and N+1 queries	Look for nested loops, excessive database calls and opportunities for batching or caching.
Maintainability	Duplicate logic and generic naming	Search for existing utilities and remove unused helpers or unnecessary abstractions.
Production readiness	Missing observability and configuration	Add structured logging, monitoring hooks and environment-based configuration.

Why AI Code Needs a Different Review

Most teams have already integrated AI into their daily workflow. Tools like GitHub Copilot or Claude now act as high-speed pair programmers that never get tired. They can scaffold functions, generate tests and fill in repetitive implementation details in seconds. This speed is a real productivity boost, but it also introduces a trade-off that many teams are only beginning to see.

Recent analyses suggest that AI-generated code can have significantly higher defect rates compared to human-written code. Some studies report roughly 1.7 times more defects overall, including about 75 percent more logic issues and nearly twice the number of security vulnerabilities. The surprising part is that many of these problems are not obvious during code review because the implementation often looks correct at first glance.

The root of the issue is a gap in context. When human developers write code, they bring a mental model of the system they are working inside. They know which services behave unpredictably, which APIs struggle under load and which operational constraints shape how the system behaves in production.

AI models do not have that history. They generate code that follows common patterns but cannot account for the specific environment where the code will run. Because of this, the mistakes produced by AI tend to look different from the ones engineers usually introduce. Human errors often come from oversight or incomplete reasoning. AI errors tend to come from missing assumptions. The generated code handles the main path well, but quietly skips the conditions that only appear under real workloads or unusual inputs.

That difference means AI-generated pull requests require a slightly different review mindset. Instead of asking only whether the implementation works, reviewers need to consider where hidden assumptions might break once the code interacts with real data, real traffic and real infrastructure.

Category 1: Logic and Correctness

The most common logical trap in AI-generated code is what many reviewers describe as a "happy path" obsession. The model assumes the data exists, the API responds correctly and the user follows the expected flow. The result is code that looks clean and complete but becomes fragile once real-world conditions begin to deviate from those assumptions. During review, the goal is not only to understand what the code does, but also to identify what it fails to do when something goes wrong.

1. Missing Edge Case Handling

One of the first things to examine is how the code handles edge cases. If a function accepts an array, check for the condition where the array is empty. If the function expects a number, consider how it behaves when the value is zero or negative. Inputs such as null values, empty strings or unusually large datasets are often overlooked because the model focuses on the most common example it was prompted to generate. This creates code that works perfectly in controlled tests but fails in production when an input falls outside the expected range.

2. Weak or Ineffective Error Recovery

Error handling in AI-generated code often appears present but incomplete. Reviewers frequently encounter try-catch blocks where the catch section logs a generic message or performs no meaningful recovery. If a database query fails or a file operation returns an error, the program may simply continue running without resolving the underlying problem. By the time the problem surfaces elsewhere in the system, the original cause may be difficult to trace.

3. Approximate Business Logic

AI models can infer patterns from examples, but they rarely understand the exact business rules a system must enforce. As a result, the generated code may implement something that looks reasonable while quietly skipping an important constraint.

4. Unsafe Control Flow

Another pattern reviewers occasionally encounter involves unsafe control flow. AI-generated code can introduce loops that never terminate, recursion that lacks a clear stopping condition or conditional statements that always evaluate to true. Because the structure of the code looks correct, these issues are easy to overlook during review. In production, however, they can create runaway processes or stalled services.

Category 2: Security

Security is another area where AI-generated code can introduce subtle risks. Language models generate code by reproducing patterns they have seen during training. They do not evaluate whether those patterns represent secure practices or simply common ones. Because insecure examples appear frequently in public repositories, models can reproduce them with the same confidence as secure implementations.

1. Input Handling and Injection

AI-generated code often constructs database queries, file paths or command strings using direct string concatenation. This pattern is common in tutorials and examples, so models frequently reproduce it. During review, pay close attention to any place where user input interacts with a database query, a system command or a file path. If the implementation does not use parameterized queries, input validation or proper binding mechanisms, the code may expose the system to SQL injection, command injection or path traversal vulnerabilities.

2. Authentication and Authorization Gaps

Another recurring issue appears in access control logic. AI-generated code may verify that a user is authenticated but fail to check whether that user is authorized to perform a specific action. For example, an endpoint might confirm that a session is valid before allowing an operation such as deleting an account or modifying a resource. However, the implementation may omit the permission check that ensures the user is actually allowed to perform that action.

3. Sensitive Data Exposure

AI-generated code may also expose sensitive information through logs, configuration values or error messages. Passwords, API tokens, local file paths or personal data sometimes appear in logs because the model attempts to make debugging easier.

In production environments, these habits can create serious risks. During review, verify that secrets are stored in environment variables or secure configuration systems and confirm that sensitive information never appears in logs or error responses.

4. Dependency and Supply Chain Risks

Another pattern reviewers encounter involves external dependencies. AI-generated code may reference outdated libraries, insecure package versions or even hallucinated dependencies.

Because these suggestions often resemble legitimate packages, they can slip past quick reviews. In the worst case, a hallucinated dependency name could be registered by an attacker in a public package registry, creating a potential supply chain attack. Reviewers should always verify that suggested dependencies are necessary, up to date and sourced from trusted repositories.

Category 3: Performance

AI-generated code is typically optimized for correctness and readability rather than performance at scale. In a local development environment with a small dataset, the implementation may run perfectly. Once the same logic operates on millions of records or handles thousands of concurrent requests, the underlying inefficiencies become much more visible.

1. Algorithmic Inefficiency

AI-generated code often relies on simple patterns such as nested loops because they are easy to express and commonly appear in examples. However, when those loops operate on large datasets, the cost grows rapidly.

A nested loop over a large collection can quickly turn a basic operation into an O(n²) performance problem. During review, look for logic that iterates over a list inside another loop or repeatedly scans the same dataset. In many cases, these operations can be replaced with indexed lookups, hash maps or more efficient data structures.

2. Inefficient Database Access

Database interactions are another frequent source of performance problems. AI-generated code may retrieve a list of records and then perform a separate database query for each item in that list. This pattern is commonly known as the N+1 query problem. While the code functions correctly, it can produce hundreds or thousands of database calls in a single request. A better approach is often to use joins, batch queries or preloading strategies that retrieve the required data in fewer database operations.

3. Missing Caching

Another pattern reviewers frequently encounter is repeated computation. AI-generated code may perform the same expensive calculation or external API request every time a function runs, even when the result rarely changes.

Without a caching strategy, this behavior can significantly increase both latency and infrastructure costs. During review, look for opportunities to cache repeated results or memoize operations that produce identical outputs for the same inputs.

4. Resource Management Issues

AI-generated implementations sometimes open resources without properly managing their lifecycle. Database connections, file handles or network sockets may be created without ensuring they are released once the operation completes.

Under light workloads this may not cause immediate problems. Over time, however, these leaked resources accumulate until the service reaches connection limits or exhausts available memory. Reviewers should verify that the implementation uses appropriate cleanup patterns such as context managers, finally blocks or connection pooling.

Category 4: Maintainability

AI-generated code is often easy to read on a first pass. Functions are neatly structured, comments appear helpful and the implementation usually follows familiar patterns. The challenge appears later, when teams begin maintaining or extending that code.

Because language models generate solutions without awareness of the full repository, the resulting code can be duplicated, disconnected from existing utilities or unnecessarily complex. If these patterns are not caught during review, the initial speed gains from AI-generated code can gradually turn into long-term technical debt.

1. Logic Duplication

One of the most common problems is duplicated functionality. AI does not search your codebase for existing utilities before generating a solution. As a result, it may recreate functionality that already exists elsewhere in the system.

You might see a new date-formatting helper, validation function or currency conversion utility even though a standard implementation already exists in the project. Every duplicate function becomes another place where bugs can appear and another piece of logic that must be maintained.

2. Dead Code and Unused Abstractions

AI-generated implementations sometimes include extra components intended to make the solution appear complete. These may include unused helper functions, empty interfaces or abstractions that do not support any real requirement.

While these additions may seem harmless, they increase the complexity of the codebase and make pull requests harder to review. Reviewers should verify that every function, interface or abstraction introduced by the AI is actually used.

3. Generic Naming

Naming is another frequent issue. AI-generated code often relies on vague identifiers such as data, result, handler or obj. While these names are technically valid, they rarely convey meaningful context within a large application. Reviewers should ensure that variables and functions reflect the domain or operation they represent.

4. Redundant Commenting

AI-generated code often contains many comments, but they do not always add useful information. Models frequently produce comments that simply restate what the code already shows.

For example, a comment such as // increment the counter by one placed directly above counter++ adds little value. Useful comments explain why the code exists or what constraint it addresses, rather than describing obvious behavior.

Category 5: Production Readiness

Production readiness is where AI-generated code is most consistently incomplete. This is not because language models are incapable of generating logging or monitoring logic. The issue is that these operational requirements are rarely included in the original prompt. As a result, the model focuses on the feature itself while ignoring the infrastructure that allows engineers to observe and manage that feature in production.

1. Structured Logging

One of the most common gaps in AI-generated code is logging. The core logic may be implemented correctly, but important events such as validation failures, retries or state changes are never recorded.

Reviewers should ensure that critical operations include structured logs with enough metadata to make debugging possible. If a request reaches an important branch or fails validation, the system should record that event in the logging infrastructure so the on-call engineer can understand what happened.

2. Actionable Error Messages

Another frequent issue is vague error reporting. AI-generated code often returns messages such as "Something went wrong," which provide little insight into the underlying problem. Effective error handling should produce messages that help engineers diagnose failures internally while ensuring that user-facing responses remain safe and do not expose sensitive system details.

3. Monitoring and Trace Hooks

Observability is another area where AI-generated code often falls short. New services, background jobs or heavy processing loops should expose metrics and tracing hooks that allow engineers to monitor performance.

Without these signals, teams may not notice that a new feature is degrading system performance or violating service-level objectives until the issue becomes visible to users.

4. Configuration Management

Configuration handling is another frequent oversight. AI-generated code often hardcodes values such as API endpoints, database connections, file paths or timeout settings directly into the implementation.

While these placeholders may work during testing, they create problems during deployment. Reviewers should confirm that environment-specific values are loaded from configuration systems or environment variables rather than embedded directly in the code.

How to Actually Use This in Your Review Workflow

One useful way to approach AI-generated code reviews is to treat the process like a funnel. Each pass acts as a filter that the code must clear before it earns more of your time. This prevents reviewers from spending fifteen minutes debating naming conventions on a function that is fundamentally broken at the logic level.

The Four-Pass Framework

Logic Pass (5–10 minutes)

Start by verifying the core behavior of the code. Does the implementation actually solve the problem it was meant to address? This is where reviewers check edge cases, error handling and the "happy path" traps discussed earlier. If the code fails on null inputs or breaks with empty arrays, it should be returned for revision before any deeper review.

Security Pass (10–15 minutes)

Once the logic appears sound, shift attention to security. Look for injection risks, permission gaps and places where sensitive data might be exposed. Because automated tools often miss contextual security flaws, this stage is where manual review provides the most value.

Performance and Maintainability Pass (5–10 minutes)

After the code is functional and safe, reviewers can evaluate efficiency and long-term maintainability. Look for nested loops that may create scaling problems, N+1 database queries or repeated logic that already exists elsewhere in the codebase. This is also the right time to check naming clarity and overall architectural consistency.

Production Readiness Pass (5 minutes)

The final pass focuses on operational details. Confirm that logging is present, configuration values are not hardcoded and the code includes the telemetry needed to monitor its behavior in production. This quick scan ensures the system can actually be supported once the feature goes live.

Teams adopting AI-assisted development often discover that reviewing AI-generated code takes slightly longer than reviewing traditional pull requests. In practice, this usually adds 20 to 30 percent more time to the review process.

This happens because the effort shifts from writing code to validating it. When developers write code manually, they usually follow established patterns and can explain the reasoning behind their choices. AI-generated code requires reviewers to confirm that each part of the implementation aligns with the system's real constraints.

Even with this additional review time, the overall development cycle often becomes faster. The model handles the repetitive scaffolding work, while engineers concentrate on validating the correctness and safety of the final implementation.

Before and After: What a Good AI Code Review Looks Like

Imagine you are in the middle of a sprint and need a quick helper function to pull user profiles from an internal microservice. You prompt your AI assistant to write a Node.js function that fetches data from an API and formats the result. Seconds later, you receive a snippet that looks clean, uses modern syntax and appears ready for a pull request.

async function getUserData(userId) {
  const response = await fetch(`https://api.internal.service/users/${userId}`);
  const data = await response.json();

  const formatted = data.map(user => {
    return {
      id: user.id,
      name: user.name.toUpperCase(),
      email: user.email
    }
  });

  return formatted;
}

At first glance, the implementation looks correct. It performs the API call and maps the result into a clean data structure. If you are working under time pressure, it might be tempting to merge this quickly after a basic test.

However, applying the review checklist reveals several issues that could cause problems in production.

Issues Identified During Review

Logic and correctness: The function assumes that the API request always succeeds. If the service returns a 404 or 500 error, the code will attempt to parse an invalid response with .json(). It also assumes the returned data is always an array. If the API returns null or a single object, the map call will throw an exception.

Security: The userId value is injected directly into the URL string. Even in internal systems, this pattern can introduce risks such as path traversal or unintended API access.

Performance: The request has no timeout protection. If the internal service becomes slow or unresponsive, the function could wait indefinitely and eventually consume available connections. There is also no caching strategy, meaning every call triggers a network request.

Production readiness: The function includes no logging or telemetry. If the request fails or returns unexpected data, engineers will have little information to diagnose the problem.

The Revised Version

After applying the review framework, the function becomes more resilient.

async function getUserData(userId) {
  if (!userId || typeof userId !== 'string') {
    throw new Error('Invalid user ID provided');
  }

  try {
    const controller = new AbortController();
    const timeout = setTimeout(() => controller.abort(), 5000);

    const response = await fetch(
      `https://api.internal.service/users/${encodeURIComponent(userId)}`,
      { signal: controller.signal }
    );

    clearTimeout(timeout);

    if (!response.ok) {
      logger.error('Failed to fetch user data', { userId, status: response.status });
      return [];
    }

    const data = await response.json();

    if (!Array.isArray(data)) {
      logger.warn('Unexpected API response format', { userId });
      return [];
    }

    return data.map(user => ({
      id: user.id,
      name: (user.name || 'Unknown').toUpperCase(),
      email: user.email || 'N/A'
    }));

  } catch (error) {
    logger.error('User data fetch operation failed', { error: error.message, userId });
    return [];
  }
}

The revised implementation introduces input validation, safer URL handling, timeout protection, structured logging and defensive checks for unexpected API responses. None of these changes dramatically alter the logic of the function, but they significantly improve its resilience in real production environments.

Without these safeguards, the original version could easily trigger outages or difficult debugging sessions. A slow upstream service might cause the API to hang indefinitely, and the lack of logging would make the root cause difficult to trace.

This example illustrates the purpose of a structured AI code review. The generated code often looks correct and passes basic tests, but careful review reveals assumptions that only become visible under real operating conditions. A systematic checklist helps teams catch those issues before they reach production.

Wrapping Up

AI-assisted development is accelerating the pace of software engineering. Features that once required hours of manual coding can now be generated in minutes with the help of modern code assistants. That speed is valuable, but it shifts where the real engineering work happens. Instead of spending most of their time writing code, teams increasingly spend their effort validating whether generated implementations actually hold up under real system constraints.

The key insight is that AI-generated code rarely fails because of syntax or obvious mistakes. It fails because of hidden assumptions. A function may work perfectly in isolation while overlooking edge cases, security boundaries, performance limits or operational requirements.

That is why reviewing AI code requires a structured approach. A checklist that covers logic, security, performance, maintainability and production readiness helps reviewers systematically uncover the patterns these systems tend to introduce.

At Bit Cloud, this kind of structured validation is a core part of how forward-deployed engineering teams help organizations move from working prototypes to reliable production systems. When AI can generate code in seconds, disciplined review becomes the safeguard that keeps speed from turning into instability. Teams that combine rapid generation with careful validation are the ones that capture the productivity benefits of AI while maintaining the reliability their systems depend on.

What’s the best tech stack for AI app development?

Oyedele Temitope — Fri, 22 May 2026 10:17:48 +0000

When you begin building an AI application, you rarely pause to consider which stack you should use. The familiar tools come first to your mind. You reach for the frameworks you already know, add a managed database, wire in a model API, and you have something working. This pattern feels natural for a prototype, so it is easy to assume it will also support the rest of the journey.

The question of how to design your stack becomes unavoidable only when you move into environments that modern LLMs do not understand well. If you try to build an AI feature inside Flutter, Swift, Kotlin or other “non-AI-friendly stacks,” friction appears in places you did not expect. The model struggles to produce reliable code, workflow becomes harder to maintain and simple changes require more effort than they should.

These moments reveal that AI applications place demands on their stack that traditional apps never had to consider.

Your choice of stack shapes the cost of running the system, the latency of every request, the clarity of your debugging signals and the model’s ability to follow your instructions. Some ecosystems align naturally with the way LLMs were trained and give you smoother development paths. Others introduce overhead you only discover when the system grows.

This guide breaks down those differences and shows what a real AI stack includes. It walks through how popular stacks behave in practice and gives you a structure you can rely on when choosing the setup that matches your goals, rather than working against them.

TL;DR

AI stacks behave differently from traditional web stacks because LLMs produce non-deterministic outputs that require orchestration, retrieval and evaluation layers.
Python, JavaScript and TypeScript align best with the patterns models learned during training, which makes them more predictable for AI workflows.
Stacks built on less common ecosystems like Flutter, Swift or Kotlin introduce structural errors because models do not understand their project layouts or build systems.
If you must use a non-AI-friendly stack, contain the AI workflow. Keep orchestration, retrieval and model logic in a Python or TypeScript backend.
The simplest decision rule: Put AI logic where the model is strongest, and let the rest of the product follow from your requirements.

What exactly is an AI tech stack?

An AI stack is an orchestration system built to manage non-deterministic behavior. In a normal web stack, each layer solves a predictable problem. AI systems do not. When a user provides natural language input, whether a question, instruction or query, the model can return different results even when the input is identical. As a result, the system must coordinate intent, context and generation instead of relying on fixed, deterministic code paths.

This non-deterministic behavior changes what the stack needs to include. Traditional systems assume stable results. AI systems assume variability. This forces you to introduce layers that typical backends never required, including orchestration, retrieval and evaluation. These layers become structural the moment you move beyond a single model call.

1. Application layer (UI and UX)

This is where users interact with the system. It collects input, displays responses and manages streaming or incremental updates. Frameworks like Next.js, React, SwiftUI and Flutter fit here. The goal is to keep the interaction loop fast and simple.

2. Backend layer (APIs and logic)

The backend prepares requests for the AI workflow. It handles validation, authentication, routing and any logic that shapes the input before the model sees it. Python and TypeScript are common choices because they align well with AI tooling.

3. Orchestration layer

This is the core of an AI stack. It decides how a request should be processed, including planning, tool usage, retrieval, retries and guardrails. It provides the structure that keeps model behavior predictable. Tools like LangChain, LlamaIndex, DSPy and the Assistants API belong here.

4. Retrieval and memory layer

This layer supplies the model with external knowledge. It indexes documents, stores embeddings and retrieves the most relevant information for each query. Vector stores like Pinecone, Weaviate, Supabase Vector and pgvector are common options.

5. Model layer

The model generates text, embeddings or structured output. It is responsible for inference and reasoning. Hosted models like GPT and Claude offer strong performance, while local models such as those run through Ollama provide control at lower cost.

6. Data layer

The data layer stores user records, documents, logs and domain-specific content. It provides the source of truth for retrieval and application logic. Postgres, MongoDB, Redis, S3 and BigQuery are typical choices.

7. Evaluation and monitoring layer

This layer tracks output quality, drift, errors and latency. It helps teams understand how model behavior changes over time. Tools like HumanLoop, Phoenix and internal dashboards support this work.

8. Deployment and infrastructure layer

This layer runs the system in production. It manages hosting, compute, scaling and networking. Platforms like Kubernetes, AWS, GCP, Vercel, Docker, Modal and Fly.io are commonly used to deploy AI workloads.

How different stacks perform when building an AI-powered app

Different tech stacks handle retrieval, embeddings and model calls differently, and the patterns become clearer once you evaluate them against the layers described earlier. To make the comparison fair, the same small retrieval-based assistant was built in a few common stacks used for AI development.

Each stack was evaluated using the following criteria:

Time to reach a working prototype
Errors or fixes needed during development
Average response latency
Cost per one thousand queries
Ongoing maintenance complexity

Stack 1: Next.js + Supabase + Vercel AI SDK + Gemini

Time to prototype: Fast (3.5 to 6 hours)
Main friction point: Message formatting mismatches and streaming differences
Latency: Low, around 3 seconds end to end
Cost: Moderate, mostly from serverless usage
Maintenance: Medium, with occasional updates to RAG components

Stack 2: Python FastAPI + MongoDB Atlas + LangChain + Ollama

Time to prototype: Medium (5 to 8 hours)
Main friction point: Dependency and version mismatches
Latency: Moderate, about 3 to 5 seconds with local generation
Cost: Low, since model usage is free
Maintenance: High, due to fast-moving Python libraries and LangChain updates

Stack 3: React Router + PocketBase + Ollama

Time to prototype: Slowest of all stacks
Main friction point: Type generation issues, ACL quirks and configuration overhead
Latency: High, often 30 seconds or more on CPU
Cost: Very low, ideal for local-first workflows
Maintenance: High, with manual responsibility for storage, routing and model management

Stack 4: React Native + Python API + LangChain + Ollama

Time to prototype: Medium to slow (6 to 9 hours)
Main friction point: Bridging mobile request formats and handling CORS
Latency: Moderate to high, about 6 to 10 seconds
Cost: Low, similar to the FastAPI setup
Maintenance: High, because you maintain both mobile and backend layers

The table below gives a quick summary of how they compare at a glance.

Stack	Time to prototype	Main friction	Latency	Cost	Maintenance
Next.js + Supabase + Gemini	Fast	Streaming and message formatting	Low	Moderate	Medium
FastAPI + Atlas + Ollama	Medium	Dependency and version shifts	Moderate	Low	High
React Router + PocketBase	Slow	ACL and configuration issues	High	Very Low	High
React Native + Python API	Medium-Slow	Mobile request formatting and CORS	Moderate-High	Low	High

These differences show how closely each ecosystem matches the environments modern LLMs were trained in. Stacks based on Python, JavaScript and TypeScript tend to behave more predictably because they align with the tooling and patterns most models were exposed to during training.

Why some stacks perform better than others

Some stacks perform better because they align with how models were trained and how today’s AI ecosystems evolved. Modern LLMs were exposed to far more Python, JavaScript and TypeScript than other languages, and they learned these ecosystems through predictable module layouts, simple build rules and consistent project structures.

Several evaluations confirm this pattern:

HumanEval-X and MultiPL-E show higher correctness in Python and JavaScript, with accuracy dropping in languages such as Go, Java, Rust, Swift and Kotlin.
SWE-PolyBench links these drops to structural mistakes in ecosystems with strict directory rules, platform-specific build steps or deeply nested configuration files.

Developers often see these structural differences. In Python and TypeScript, the model often produces valid imports, correct file placement and workable function signatures because these conventions appear throughout its training data. In Dart, Swift or Kotlin, the model frequently guesses project structure, which leads to broken Xcode setups, invalid Gradle modules or misplaced Flutter widgets.

The takeaway is straightforward. Stacks that match the model’s training distribution, such as Python, JavaScript and TypeScript, tend to produce more stable AI workflows. Other languages can work, but they require more human oversight to keep the system predictable.

How to choose based on your goal

Choosing an AI stack becomes simpler once you anchor your decision to a single rule:

Put your AI logic in the environment the model understands best, and let everything else follow from the product’s requirements.

From this rule, four practical paths emerge:

If speed is the priority, choose a JS/TS-first workflow.
If reliability and control matter, put your backend in Python.
If cost must stay low, use local inference with a lightweight database.
If you are shipping mobile apps, keep AI logic in the backend, not the client.

The table below summarizes the most common goals and the stack that matches each one.

Goal	Recommended stack	Why it fits
Speed to MVP	Next.js + TypeScript + Vercel AI SDK + MongoDB Atlas	Minimal setup, fast iteration, built-in streaming and vector storage
Production-grade API	Python (FastAPI) + TS frontend + MongoDB or Postgres	Strong orchestration, clean routing, predictable scaling
Low-cost / self-hosted	Python + Ollama + SQLite or Postgres + simple frontend	Local models remove API cost, minimal infrastructure
Cross-platform apps	Flutter or React Native + Python/TS backend	Mobile handles UI, backend handles retrieval and inference
Enterprise integration	Python + TypeScript + cloud-managed services	Best fit for IAM, compliance, queues and monitored pipelines

Best practices when you cannot use “AI-friendly” stacks

Some teams must work inside Flutter, Swift, Kotlin or other environments that LLMs do not understand well. If you are forced into a non-AI-friendly ecosystem, the goal is containment. You want to limit how much of your AI workflow touches the parts of the stack where the model is most likely to make structural mistakes.

Below are some of the best practices you can follow:

Keep AI involvement limited to small, well-scoped pieces of implementation. Broader architectural or module-level code should remain developer-controlled.
Define architecture, project layout and build rules yourself. These ecosystems depend on strict structure, and LLMs cannot reliably create it.
Send all retrieval, embeddings and orchestration to a Python or TypeScript backend. Keep AI-heavy logic in environments the model understands.
Avoid mixing languages or layers in a single instruction. Handle one layer at a time to prevent structural guessing.
Validate everything with tests, type checks and linters. Strict toolchains require strict verification.

Bit Cloud focuses on JavaScript and TypeScript precisely because these environments produce the most stable AI-generated components. Modern models understand their patterns, module layouts and build systems far more reliably than less common languages.

Wrapping up

Choosing an AI tech stack comes down to how well your tools align with the environments modern models understand. Python, JavaScript and TypeScript consistently offer the most predictable behavior, which is why stacks built around them tend to support faster iteration, clearer debugging signals and more stable AI workflows.

As AI workloads grow, teams that succeed are the ones who treat their stack as an orchestration system rather than a collection of tools. Modular components, clean boundaries and dependable infrastructure make retrieval, routing and model behavior easier to manage at scale. Other ecosystems like Flutter, Swift or Kotlin can support AI features, but they work best when the heavier logic lives in a Python or TypeScript backend.

If you want to see how this modular, component-driven approach works in practice, you can explore how teams use Bit Cloud to structure JavaScript and TypeScript applications for production. It provides a practical example of how composability and clear boundaries help teams ship AI features that remain stable as models evolve.

Why “Ship First” Fails in AI and How High-Performing Teams Build Instead

Oyedele Temitope — Tue, 20 Jan 2026 14:50:33 +0000

Most software teams grew up in a world where systems behave in black and white. A feature either works or it breaks, and when something fails, you trace the exact line of code and fix it. This mindset shaped how developers build, test and deploy applications.

AI systems do not behave this way. They answer with probabilities, not certainties. A response can be mostly correct, partly wrong or completely unpredictable. Quality shifts with context, data and even slight prompt changes. If teams carry the old “ship first, refine later” habit into an AI workflow, they end up with features that look promising in isolation but collapse under real user behaviour.

High-performing teams avoid this pattern by defining expected behaviour early, writing the tests that capture it and only then building the pipelines behind it. Their confidence comes from structure, not guesswork. The discipline looks simple from the outside: test first, deploy later. In practice, it is the clearest path to building AI systems that meet real user expectations.

In this article, we will take a look at how high-performing teams avoid that outcome. We will examine the discipline behind test-first development in the AI era, why it matters and how teams use it to build systems that behave consistently.

Why Traditional Engineering Logic Breaks in AI Systems

Software engineers often rely on a simple rule: if something breaks, there is a clear reason behind it. Code behaves the same way every time, so debugging becomes a matter of tracing the exact condition that failed. This creates a sense of certainty. Once you fix the problem, it stays fixed unless someone changes the code again.

AI systems do not offer that level of predictability. The same prompt can produce different answers at different times. A response may be mostly correct in one context and completely off in another. Two users can ask similar questions and receive different outcomes. The behaviour depends on data, phrasing, input structure and subtle changes that are impossible to map one by one.

This is why the “it works on my machine” mindset collapses in AI development. You cannot rely on a single example or a quick manual test to confirm that a feature is ready. Correctness must be judged across a range of inputs, not a single scenario. The goal is no longer to make the system perfect. The goal is to understand how it behaves across variations and whether that behaviour meets the standard your users expect.

High-performing teams recognise this early. They build tests that capture the spectrum of questions, contexts and edge cases the system must support. They do not search for one prompt that works. They search for consistent behaviour across many prompts, inputs and situations. This shift is the foundation for everything that follows, because you cannot design a reliable AI workflow without first accepting that its behaviour will always exist on a gradient.

You Don’t Need More Prompts. You Need a System

A common reaction when an AI feature behaves unpredictably is to write another prompt. If the output looks wrong, adjust a phrase. If the tone feels off, add a new instruction. If the model misunderstands a question, expand the context. This cycle repeats until the team finds a version that “seems to work.”

The problem is that this success rarely holds when real users arrive. A prompt that works during development may fail once the range of inputs expands. The team ends up patching and tweaking the system long after deployment because they were never testing for consistency in the first place.

High-performing teams avoid this trap. They do not chase perfect prompts. They build a system that helps them discover what actually works across a wide set of scenarios. Instead of guessing, they evaluate prompts against structured tests that represent true user behaviour. They measure how often a specific approach holds up, where it breaks and what patterns lead to reliable responses.

This is the moment where discipline replaces intuition. A prompt is no longer “good” because it produced a single correct answer. It is good because it performs consistently when tested at scale. This shift unlocks predictability, and it gives teams a clear path forward without relying on trial and error.

Start With the User, Not the Model

A lot of AI projects begin with the question, “Which model should we use?” It feels like the natural place to start, especially with the rapid pace of new releases. But model choice is rarely the real issue. A system fails because it does not match what users expect, not because the model was one version behind.

High-performing teams flip this process around. They begin by asking what users actually need from the system. If the feature is a support assistant, what kinds of questions will it handle? If it is a search tool, what signals matter most when ranking results? If it generates content, what tone, length or structure should the output follow? These expectations become the foundation for testing long before any model or prompt enters the picture.

This approach clarifies the goal. Instead of trying to guess what might work, the team defines the behaviours the system must demonstrate. Each behaviour becomes a test case. The tests then guide prompt design, retrieval logic, and eventual model selection. The model becomes a part of the solution, not the starting point.

That alignment prevents a common mistake: building something that looks impressive in isolation but fails when actual users interact with it. When tests come from user expectations, the system grows around real needs, not assumptions. It also becomes easier to measure progress, because every improvement shows up as a test that now passes.

Defining the Test Space for AI Systems

Before teams can test an AI system effectively, they need to agree on what “good behaviour” actually means in practice. That requires understanding the kinds of questions the system will receive, the scenarios that matter most, and the risks that must be controlled. High-performing teams define this test space early because it shapes every decision that follows.

Below are the key dimensions they use to define that space.

Coverage Metrics

Coverage metrics describe the distribution of real user queries. They show which categories appear most often, which ones carry higher value, and how different user segments behave. This helps teams decide where deeper testing is required and where lighter coverage is acceptable

Failure Mode Categories

AI systems fail in recognizable ways. Some responses hallucinate, others drift off-topic, and some ignore constraints or formatting rules. For example, a support assistant may confidently offer legal or medical advice when it should refuse, or a search tool may expose sensitive information if guardrails are not enforced. Identifying these failure modes early allows teams to design tests that surface problems before they reach users.

Guardrail Rules

Certain behaviours must remain stable regardless of context. These include safety boundaries, restricted topics, tone expectations, and output structure. Turning these requirements into tests helps prevent regressions as prompts, models, or data sources change.

Business-Critical Paths

Not all queries carry the same risk. Interactions tied to revenue, compliance, or customer trust require stronger guarantees. High-performing teams invest more testing effort in these paths to ensure they remain reliable as the system evolves.

Evaluation Metrics

Teams also decide how results will be measured. Relevance, accuracy, consistency, and latency are common criteria. In practice, these metrics are measured using a mix of automated techniques such as model-graded evaluations, deterministic checks like schema or constraint validation, and semantic similarity scoring rather than strict pass or fail assertions. Together, these metrics define what acceptable performance looks like for the system.

Building and Validating the System After Writing Tests

Once the test suite is clear, teams begin shaping the system around it. This is where prompts, retrieval steps and business logic come together to form the full workflow. The goal is simple: build the system, then check how well it holds up against the expectations defined in the tests.

Below are the steps high-performing teams focus on during this stage.

Pipeline Construction

The first step is assembling the core components of the AI workflow. This includes retrieval logic, classification steps, prompt templates, routing rules and any business-specific operations the feature requires. Each part supports a behaviour captured in the test suite, so the pipeline grows in a direction that reflects real user needs.

Real Data Validation

With the pipeline in place, teams run the system against real or representative data. This is where weaknesses appear. A response might be correct but too slow. A prompt may break when phrasing changes slightly. Formatting issues, missing context and inconsistent reasoning show up long before deployment when validation uses the right test cases.

Closing the Gaps the Tests Expose

Some issues only appear when the full workflow is tested across a broad set of scenarios. The system may drift from user intent, misunderstand certain categories or place the wrong weight on low-value tasks. These gaps guide the next round of adjustments. By refining the system at this stage, teams prevent misaligned behaviours from reaching production.

Best Practices Teams Use to Keep Their Systems Dependable

As teams refine their workflows, certain habits help maintain consistent behaviour and reduce surprises. These practices keep the system aligned with user expectations and provide guardrails as the system evolves. Below are the practices teams use to keep their systems dependable as they grow.

Keep humans in the loop to catch subtle issues that automated tests may miss and provide early feedback that improves the system’s alignment.
Turn failures into new test cases so problems become clear specifications and the system grows stronger with each improvement. Automate evaluations in your CI pipeline to catch regressions early and ensure every update meets the expected standard before it ships.
Version prompts, templates, datasets and routing logic so changes remain traceable and accidental regressions are easier to identify.
Re-test with real user samples to keep the system aligned with shifting behaviour patterns and uncover new edge cases.

Wrapping Up

AI systems behave on a spectrum, not in absolutes, which makes traditional “ship first, fix later” habits unreliable. The teams that build dependable AI features take a different path. They define how the system should behave, outline the space they need to test and shape their pipelines around those expectations. Testing comes first because it is the only way to bring predictability into a workflow built on probabilistic outputs.

While this approach can feel slower and more expensive than shipping quickly and fixing issues later, teams consistently find that structured evaluations reduce rework, limit regressions, and save engineering time over the life of the system.

This discipline does not slow teams down. It gives them clarity, reduces rework and prevents the common failure pattern where an AI feature looks promising in development but breaks under real user behaviour. By grounding their workflow in structured tests and refining the system against those tests, teams create AI features that stay aligned with user needs as they evolve.

Test first, deploy later. In the AI era, it is not just a process. It is how reliable systems are built.

15 Go Packages Worth Your Time

Oyedele Temitope — Thu, 26 Jun 2025 12:09:50 +0000

I’ve worked with Go for years, building web apps, CLIs, microservices, daemons, and all the in-between stuff nobody talks about. If you’ve worked with Go long enough, you know the standard library is solid, but you also know it’s not always enough.

Most problems you’ll run into have already been solved—cleanly, efficiently, and without the nonsense—by libraries maintained by people who know what they’re doing.

So instead of throwing out a list of “cool” Go packages, here’s a hand-picked set of 15 libraries that are actually worth using, based on real-world experience. These are things I’ve reached for again and again, and they’ve never let me down.

Core Utilities

If you’re building anything that touches config, flags, or maps—or you just want cleaner, testable code,these are the packages that’ll help you get it done.

1. `spf13/cobra`

The Cobra package is designed for building modern CLI applications. It supports subcommands, nested flag sets, command aliases, and generates help text automatically. It’s especially useful for CLI tools with multiple commands and a deeper structure.

Cobra integrates well with spf13/viper for managing configuration and environment variables, which makes it ideal for full-featured command-line applications.

2. `urfave/cli`

This is a lighter-weight alternative to Cobra. It focuses on the fast development of command-line apps without requiring much setup. It supports flags, nested commands, and custom help messages, but does so with a smaller surface area.

urfave/cli is well-suited for internal tools or smaller utilities where you want fast iteration without a large framework.

3. `stretchr/testify`

testify is a testing toolkit that adds better assertions, mock capabilities, and test suite support on top of Go’s built-in testing package. It’s commonly used for simplifying test logic and improving test readability.

It doesn’t replace Go’s testing.T, but works alongside it, giving you utilities like assert.Equal, require.NoError, and mock.Call.

4. `mitchellh/mapstructure`

The mitchellh/mapstructure package helps decode map[string]interface{} values, such as those returned by json.Unmarshal or config files, into typed Go structs. It supports custom tags, weakly typed inputs, and embedded structs.

It’s especially helpful when working with dynamic inputs, such as user-defined configurations or external API data. You’ll often see it used in tools like Terraform or Consul.

Unlike encoding/json, this focuses purely on map decoding, not marshaling/unmarshaling structured JSON.

5. `olekukonko/tablewriter`

tablewriter helps you render formatted tables in the terminal. It takes slices or arrays and prints them as aligned, readable tables, with support for borders, color, and alignment.

This is a great fit for CLI tools that require displaying lists, metrics, or tabular data. The package doesn’t deal with interactive UIs (like tview does), but it handles static output well.

Web & APIs

If you're building APIs, HTTP services, or JSON endpoints, these libraries improve routing, performance, and readability without locking you into rigid frameworks.

6. `gin-gonic/gin`

Gin is a high-performance HTTP web framework. It wraps Go’s standard net/http package and adds routing, middleware support, JSON validation, and error handling.

It’s known for its speed and simplicity. If you’re building RESTful APIs and want something faster and more ergonomic than raw net/http, Gin is a strong option.

7. `labstack/echo`

Echo is a full-featured web framework for Go. Like Gin, it offers routing and middleware, but it also includes built-in support for CORS, GZIP, JWT middleware, request validation, and more.

Echo is best when you want more “batteries included” functionality and are building something that benefits from built-in helpers (e.g., API versioning, structured error handlers).

While Gin and Echo overlap in purpose, Echo includes more out-of-the-box capabilities for production APIs.

8. `go-chi/chi`

Chi is a lightweight router that focuses on composability and idiomatic Go. It’s built around net/http and designed to be modular and minimal.

Chi is ideal if you want full control over your stack without adopting a full framework. It integrates well with standard middleware patterns and is often used in microservice setups.

Unlike Gin and Echo, Chi avoids introducing new abstractions around handlers or context. If you like the standard library but want better routing, Chi is a great pick.

9. `tidwall/gjson`

GJSON allows you to extract values from JSON strings using a simple path syntax like user.name, items.#.id, etc., without unmarshalling into structs.

It’s incredibly fast and useful in cases where you’re inspecting or filtering raw JSON logs, responses, or configs. This is a read-only tool; if you want to modify JSON, check out sjson from the same author.

Dev & Ops Helpers

These packages aren't about features—they're about keeping your codebase sane, your logs readable, and your CI clean. They’re the ones that make maintenance easier over time.

10. `golangci/golangci-lint`

The golangci-lint tool aggregates dozens of popular Go linters (like govet, staticcheck, errcheck, etc.) into a single, fast binary. It’s configurable, fast, and widely used in continuous integration (CI) pipelines.

Instead of manually juggling multiple linters, golangci-lint provides a unified interface to catch real issues early.

11. `sirupsen/logrus`

Logrus is a structured logger for Go that outputs in JSON, text, or custom formats. It’s simple to use and integrates easily with most projects.

While it’s not the fastest logger around, it’s stable, well-documented, and good for most apps that aren’t logging at extreme scale.

12. `uber-go/zap`

Zap is a structured logger built for speed. It avoids reflection and allocates far less than most logging packages.

If you’re working on high-throughput systems, background workers, or want better performance under load, Zap is a better choice than Logrus. Its API is more verbose, but the tradeoff is worth it for larger systems.

Storage, Persistence, and Data

If you’re storing state, caching data, or working with local files, these packages help avoid unnecessary complexity or external dependencies.

13. `jmoiron/sqlx`

sqlx builds on Go’s database/sql and adds useful features like named queries, struct mapping, and scanning slices.

It doesn’t try to be an ORM—it just smooths out some of the rough edges. Perfect for apps that interact directly with SQL and want less boilerplate.

14. `etcd-io/bbolt`

Bolt, now maintained by etcd-io, is a low-level, embedded key-value store. It’s ACID-compliant, fast, and doesn’t require a server process.

It’s a solid choice for storing user preferences, cached data, or small records locally. If you need a lightweight persistence layer without a full DB engine, Bolt is a great fit.

15. `go-yaml/yaml`

The go-yaml/yaml is the most reliable YAML parser for Go. It supports the full YAML spec (including anchors and aliases) and handles real-world files used in infra tools.

You’ll often run into YAML if you work with Kubernetes, Docker Compose, or Terraform. This package helps you load and parse them properly without surprises.

Concusion

These 15 packages are ones I’ve used repeatedly across real projects, and I keep coming back to them for a reason. They’re maintained, documented, and solve problems without getting in your way.

If you’ve got a favorite package I didn’t list—especially niche tools—drop a comment. Always happy to find sharp tools.

How to Scrape Products from a Page with Infinite Scroll via 'Load More' Button

Oyedele Temitope — Mon, 24 Mar 2025 18:01:33 +0000

Have you ever wanted to scrape data but didn’t know where to start? Or have you struggled with websites that hide extra data behind interactions like a "Load More" button? Don’t worry; web scraping doesn’t have to be complicated, and you don’t need to be a pro to get started.

In this tutorial, you’ll learn how to scrape data in Node.js. We’ll use tools like Puppeteer and Cheerio to extract data from the website.

Prerequisites

To follow along with this tutorial, you’ll need to meet the following prerequisites:

Basic knowledge of JavaScript and Node.js
Node.js installed
A code editor
Basic knowledge of web scraping

Project Scope

For this project, we’ll scrape products along with the necessary information about the products from this demo website. You can check it out to get familiar with

Below are some of the libraries needed for scraping the data in this project:

Puppeteer: For the project, it will be used to scrape data and simulate browser interactions, such as the “Load More” button.
Cheerio: For this project, it will be used to parse and extract data.
Csv-writer: exporting data into a structured CSV file
Set Up the Project

Open your terminal and navigate to the folder where you want this project set up. Initialize a new Node.js project by running this command:

npm init -y

Next, install the required libraries:

npm install puppeteer cheerio csv-writer

Access the Content

First, check out the site from which you want to extract the data for this project. Below is an image of what the webpage you’ll extract data from looks like:

You’ll notice that 12 products are displayed on the webpage. We're focusing on extracting these 12 products. This will be achieved using CSS selectors.

Go back to the demo webpage. Right-click on an element and select Inspect to open the Developer Tools. Alternatively, you can open the Developer Tools by pressing Ctrl+Shift+I (or Cmd+Option+I on Mac).

Locate the container for all products. In this case, it's a div with the ID #product-grid. Copy the selector.

The selector you just copied will be used to access the content.

In order to extract the product grid's HTML structure, Puppeteer will be used to navigate to the demo webpage and extract the product grid’s HTML using the #product-grid selector.

In your project folder, create a file called scrape.js. Inside it, add the following code:

const puppeteer = require("puppeteer");

(async () => {
  const url = "https://www.scrapingcourse.com/button-click"; 
  const browser = await puppeteer.launch({ headless: true }); 
  const page = await browser.newPage();

  await page.goto(url, { waitUntil: "domcontentloaded" });

  await page.waitForSelector("#product-grid"); 
  const productGridHTML = await page.evaluate(() => {
    return document.querySelector("#product-grid").outerHTML;
  });

  console.log("Initial product grid HTML:", productGridHTML); 

  await browser.close();
})();

The await page.waitForSelector ensures the #product-grid element is loaded. This guarantees the content is available before scraping. It then uses page.evaluate to extract the HTML structure of the #product-grid and logs the result to the console.

Run your code using this command:

node scrape.js

You’ll see an output in your terminal printing the HTML structure of the #product-grid, which contains the first 12 products:

Load More Products

Each time you click the “Load More” button, it displays more products. This means there are still other products that have yet to be scraped. To achieve this, you need to simulate clicking the button multiple times to retrieve all the available products.

You first need to identify its selector, so go back to the demo webpage. Right-click on the "Load More" button and select Inspect. The HTML code for the button will then be highlighted:

In the Developer Tools, you’ll see the button's structure:

<button id="load-more-btn" data-offset="10">Load More</button>

This tells you two important things: First, you can uniquely identify the button using the id attribute, which is #load-more-btn.

Secondly, the data-offset attribute keeps track of the number of products loaded. After each click, the data-offset value changes to reflect the updated count.

Select Copy > Copy selector to use the selector in your code.

To ensure new products are fully loaded before scraping, we’ll use await page.waitForFunction. This waits for the data-offset value of the "Load More" button to update.

Update the logic in the async function as follows:

(async () => {
  const url = "https://www.scrapingcourse.com/button-click";
  const browser = await puppeteer.launch({ headless: true }); 

  const page = await browser.newPage();
  await page.goto(url, { waitUntil: "domcontentloaded" });
  await page.waitForSelector("#load-more-btn");
  for (let i = 0; i < 5; i++) {
    const currentOffset = await page.evaluate(() => {
      return document
        .querySelector("#load-more-btn")
        .getAttribute("data-offset");
    });
    await page.click("#load-more-btn"); 
    await page.waitForFunction(
      (prevOffset) => {
        const button = document.querySelector("#load-more-btn");
        return button && button.getAttribute("data-offset") !== prevOffset;
      },
      { timeout: 5000 },
      currentOffset,
    );
  }
  const productGridHTML = await page.evaluate(() => {
    return document.querySelector("#product-grid").outerHTML;
  });
  console.log("Updated product grid HTML:", productGridHTML); 
  await browser.close(); 
})();

The main logic introduced here is the ability to handle product dynamic loading. Each time the button is clicked, the data-offset attribute of the button is tracked to verify that new content has been loaded.

You'll also notice a for loop in the logic. it used to click the button multiple times. after each click the await page.waitForSelector waits for the data-offset value to update, until it disappears which indicates that there are no more products availble to be displayed.

For additional techniques on handling dynamic content, check out how to do web scraping with Puppeteer and NodeJS.

Your code should now look like this:

const puppeteer = require("puppeteer");

(async () => {
   const url = "https://www.scrapingcourse.com/button-click"; 
   const browser = await puppeteer.launch({ headless: true }); 
    const page = await browser.newPage();
   await page.goto(url, { waitUntil: "domcontentloaded" });
   await page.waitForSelector("#load-more-btn"); 

   for (let i = 0; i < 5; i++) {
     const currentOffset = await page.evaluate(() => {

         .querySelector("#load-more-btn")
         .getAttribute("data-offset");
     });
     await page.click("#load-more-btn"); 
     await page.waitForFunction(
       (prevOffset) => {
         const button = document.querySelector("#load-more-btn");
         return button && button.getAttribute("data-offset") !== prevOffset;
       },
       { timeout: 5000 }, 
       currentOffset,
     );
   }
   const productGridHTML = await page.evaluate(() => {
     return document.querySelector("#product-grid").outerHTML;
   });
   console.log("Updated product grid HTML:", productGridHTML); 
   await browser.close(); 
 })();

Re-run the code, and you’ll see all the products loaded and displayed in your terminal:

Parse Product Information

Now that the full HTML of the products has been captured, the next step is to parse the product details. This is where Cheerio comes in. It will be used to parse the HTML of the product grid and extract specific details for each product, such as name, price, and image URL, into a JSON file. The .product-item selector will be used to help locate individual products.

Import the Cheerio and fs library:

const cheerio = require("cheerio"); // Import Cheerio for parsing HTML
const fs = require("fs"); // Import the file system module for saving data

Update the logic in the async function to this:

(async () => {
  const url = "https://www.scrapingcourse.com/button-click";   const browser = await puppeteer.launch({ headless: true });

  const page = await browser.newPage();

  await page.goto(url, { waitUntil: "domcontentloaded" });
  await page.waitForSelector("#load-more-btn"); // Wait for the "Load More" button to be available

  for (let i = 0; i < 5; i++) {
    const currentOffset = await page.evaluate(() => {

      return document
        .querySelector("#load-more-btn")
        .getAttribute("data-offset");
    });

    await page.click("#load-more-btn");

    await page.waitForFunction(
      (prevOffset) => {
        const button = document.querySelector("#load-more-btn");
        return button && button.getAttribute("data-offset") !== prevOffset;
      },
      { timeout: 5000 }, 
      currentOffset,
    );
  }

  const productGridHTML = await page.evaluate(() => {
    return document.querySelector("#product-grid").outerHTML;
  });

  const $ = cheerio.load(productGridHTML); 
  const products = []; 


  $(".product-item").each((_, element) => {
    const name = $(element).find(".product-name").text().trim();
    const price = $(element).find(".product-price").text().trim();
    const image = $(element).find(".product-image").attr("src");
    const url = $(element).find("a").attr("href");

    const fullImageUrl = image.startsWith("http")
      ? image
      : `https://www.scrapingcourse.com${image}`;
    const fullUrl = url.startsWith("http")
      ? url
      : `https://www.scrapingcourse.com${url}`;

    products.push({
      name,
      price,
      image: fullImageUrl,
      url: fullUrl,
    });
  });

  // Save the product details to a JSON file
  fs.writeFileSync("products.json", JSON.stringify(products, null, 2));
  console.log("Product data saved to products.json");

  await browser.close(); 
})();

Since the full HTML of the product has already been scraped into productGridHTML all that Cheerio needs to do is process the productGridHTML by converting it into a DOM-like structure in memory. This enables queries and manipulations like how you would use CSS selectors in a browser. Cheerio uses .product-item to locate each product container and .product-name, .product-price, .product-image, and <a> elements to retrieve specific details.

Your code should now look like this:

const puppeteer = require("puppeteer");
const cheerio = require("cheerio"); 
const fs = require("fs"); 

(async () => {
   const url = "https://www.scrapingcourse.com/button-click"; 
   const browser = await puppeteer.launch({ headless: true }); 
    const page = await browser.newPage();
    await page.goto(url, { waitUntil: "domcontentloaded" });
   await page.waitForSelector("#load-more-btn"); // Wait for the "Load More" button to be available

   for (let i = 0; i < 5; i++) {
     const currentOffset = await page.evaluate(() => {

       return document
         .querySelector("#load-more-btn")
         .getAttribute("data-offset");
     });
      await page.click("#load-more-btn");
      await page.waitForFunction(
       (prevOffset) => {
         const button = document.querySelector("#load-more-btn");
         return button && button.getAttribute("data-offset") !== prevOffset;
       },
       { timeout: 5000 }, 
       currentOffset,
     );
   }

   const productGridHTML = await page.evaluate(() => {
     return document.querySelector("#product-grid").outerHTML;
   });
    const $ = cheerio.load(productGridHTML); 
   const products = []; 

   $(".product-item").each((_, element) => {
     const name = $(element).find(".product-name").text().trim();
     const price = $(element).find(".product-price").text().trim();
     const image = $(element).find(".product-image").attr("src");
     const url = $(element).find("a").attr("href");

     const fullImageUrl = image.startsWith("http")
       ? image
       : `https://www.scrapingcourse.com${image}`;
     const fullUrl = url.startsWith("http")
       ? url
       : `https://www.scrapingcourse.com${url}`;

     products.push({
       name,
       price,
       image: fullImageUrl,
       url: fullUrl,
     });
   });

   fs.writeFileSync("products.json", JSON.stringify(products, null, 2));
   console.log("Product data saved to products.json");
    await browser.close(); 
 })();

Re-run the code, and you’ll have a product.json displaying the details like this:

You’ve successfully scraped a dynamic website, Node.js, using Puppeteer and Cheerio. Now, you can decide to stop here or go further and convert the JSON file to CSV. If you decide to stop here, no problem, but if you decide to continue, then let’s get on with it!

Export Product Information to CSV

Import the csv-writer library:

const createCsvWriter = require("csv-writer").createObjectCsvWriter;

Import the csv-writer library:

Next, add this code inside the async function right before the await browser.close:

const csvWriter = createCsvWriter({
   path: "products.csv", 
   header: [
     { id: "name", title: "Name" },
     { id: "price", title: "Price" },
     { id: "image", title: "Image URL" },
     { id: "url", title: "Product URL" },
   ],
 });

 const jsonData = JSON.parse(fs.readFileSync("products.json", "utf-8"));
 await csvWriter.writeRecords(jsonData);
 console.log("Product data successfully written to products.csv");

Now your code looks like this:

const puppeteer = require("puppeteer"); 
const cheerio = require("cheerio"); 
const fs = require("fs"); 
const createCsvWriter = require("csv-writer").createObjectCsvWriter; 

(async () => {
 const url = "https://www.scrapingcourse.com/button-click"; 
 const browser = await puppeteer.launch({ headless: true }); 

 const page = await browser.newPage();

 await page.goto(url, { waitUntil: "domcontentloaded" });
 await page.waitForSelector("#load-more-btn"); 

 for (let i = 0; i < 5; i++) {
   const currentOffset = await page.evaluate(() => {
       .querySelector("#load-more-btn")
       .getAttribute("data-offset");
   });

   await page.click("#load-more-btn");

   await page.waitForFunction(
     (prevOffset) => {
       const button = document.querySelector("#load-more-btn");
       return button && button.getAttribute("data-offset") !== prevOffset;
     },
     { timeout: 5000 }, 
     currentOffset
   );
 }

 const productGridHTML = await page.evaluate(() => {
   return document.querySelector("#product-grid").outerHTML;
 });

 const $ = cheerio.load(productGridHTML); // Load the HTML into Cheerio for parsing
 const products = []; 

 $(".product-item").each((_, element) => {
   const name = $(element).find(".product-name").text().trim();
   const price = $(element).find(".product-price").text().trim();
   const image = $(element).find(".product-image").attr("src");
   const url = $(element).find("a").attr("href");

   const fullImageUrl = image.startsWith("http")
     ? image
     : `https://www.scrapingcourse.com${image}`;
   const fullUrl = url.startsWith("http")
     ? url
     : `https://www.scrapingcourse.com${url}`;
   products.push({
     name,
     price,
     image: fullImageUrl,
     url: fullUrl,
   });
 });

 fs.writeFileSync("products.json", JSON.stringify(products, null, 2));
 console.log("Product data saved to products.json");
 const csvWriter = createCsvWriter({
   path: "products.csv", 
   header: [
     { id: "name", title: "Name" },
     { id: "price", title: "Price" },
     { id: "image", title: "Image URL" },
     { id: "url", title: "Product URL" },
   ],
 });

 const jsonData = JSON.parse(fs.readFileSync("products.json", "utf-8"));
 await csvWriter.writeRecords(jsonData);
 console.log("Product data successfully written to products.csv");

 await browser.close();
})();

Re-run your code, and you’ll see that a products.csv has been created. It contains all the data that was scraped.

Now we’re finally done!

That’s How To Scrape Data in Node.js using Puppeteer and Cheerio

In this tutorial, we explored how to scrape data in Node.js using Puppeteer and Cheerio. With the right tools, web scraping can be effective and approachable, even for beginners.

Remember to always respect the ethical boundaries of web scraping and adhere to the terms of service of the websites you work with. To ensure you’re scraping responsibly, check out Web Scraping Best Practices and Tools 2024 for more information.

How to create an AI Avatar in Go using Simli

Oyedele Temitope — Thu, 16 Jan 2025 16:56:18 +0000

Creating a real-time video AI avatar for interaction is a great way to blend technology and human-like communication. The exciting part is that it can be used in various aspects, such as customer support, virtual assistants, education, and more.

Simli provides this. It is an AI video avatar-generating platform that allows you to create lip-synced AI avatars with lifelike, animated characters, realistic head movements, and synchronized speech. Now, you can utilize its product and build in Go!

In this tutorial, we’ll take a look at how to generate an AI avatar in Go using Simli.

Prerequisites

Before we proceed, ensure that you have the following:

Basic knowledge of Go and its concepts.
Go version 1.22 or higher.
A Simli account.
An audio file.

Set up your Environment

To get started, go to your dashboard and navigate to the API KEYS section. There, you’ll see your API key. Copy it and store it somewhere, as you’ll need it during the building process.

Next, you’ll need an AI avatar. You can choose to create your own avatar or choose from the list in your dashboard. For the project, we’ll choose an avatar from the one assigned to us. Navigate to your avatars. There, you’ll see the list of avatars you have:

Copy the ID of your desired avatar and store it somewhere.

Now you’re ready to start building!

Build the Project

Open up a terminal in your code editor and navigate to the folder for the project.

You need to initialize a new Go module. Run this command:

go mod init simli-avatar

Next, you need to install Simli sdk. While there isn't an official Simli sdk for Go yet, There’s a Go library you can use. Add this library to your project using this command:

go get github.com/oyedeletemitope/simli-go-sdk

This will install the library that you’ll need to use Simli.

Import Required Packages and Set Data Structure for Response

You need to import the necessary packages for file handling, HTTP communication, JSON encoding/decoding, environment variables, and working with Simli's SDK. Create a main.go file and add the following code:


import (
   "bytes"
   "encoding/base64"
   "encoding/json"
   "fmt"
   "log"
   "net/http"
   "os"
   "os/exec"
 "github.com/oyedeletemitope/simli-go-sdk/client"
 "github.com/oyedeletemitope/simli-go-sdk/models"
)

Below is the list of packages imported and what they do:

encoding/base64: To encode binary data into Base64 format.
encoding/json: To work with JSON data.
fmt: For formatted I/O operations.
log: For logging errors or information.
net/http: To handle HTTP server and client operations.
os: For file and environment operations.
simli-go-sdk: The library for interacting with Simli's API.

You also need to create the data structure for the response:


type GenerateAvatarResponse struct {
        HLSURL string `json:"hls_url"`
        MP4URL string `json:"mp4_url"`
}

Here, we created a struct that defines the structure of the HTTP response sent back to the client.

Generate the AI Avatar

You need to create a handler to generate the avatar. It will handle HTTP requests for avatar generation by processing a PCM file and sending it to the Simli API. Add this code:


func generateAvatarHandler(w http.ResponseWriter, r *http.Request) {
        apiKey := "your-simli-api-key"
        faceID := "6ebf0aa7-6fed-443d-a4c6-fd1e3080b215"
        // Path to the PCM file
        pcmFile := "./audio/audio.pcm"
        // Read the PCM file
        audioData, err := os.ReadFile(pcmFile)
        if err != nil {
                http.Error(w, fmt.Sprintf("Failed to read PCM audio file: %v", err), http.StatusInternalServerError)
                return
        }
        // Convert PCM audio to Base64
        audioBase64 := base64.StdEncoding.EncodeToString(audioData)
        // Initialize Simli client
        c := client.NewClient(apiKey)
        // Prepare audio-to-video request
        audioReq := models.AudioToVideoRequest{
                SimliAPIKey:       apiKey,
                FaceID:            faceID,
                AudioBase64:       audioBase64,
                AudioFormat:       "pcm16",
                AudioSampleRate:   16000,
                AudioChannelCount: 1,
        }
        // Generate avatar
        resp, err := c.AudioToVideo(audioReq)
        if err != nil {
                http.Error(w, fmt.Sprintf("Failed to generate avatar: %v", err), http.StatusInternalServerError)
                return
        }
        // Respond with video URLs
        json.NewEncoder(w).Encode(GenerateAvatarResponse{
                HLSURL: resp.HLSURL,
                MP4URL: resp.MP4URL,
        })
}

Add the Main Function

Lastly, on the main.go file, you need to create the main function that’ll take in the avatar generation function, set up the HTTP server, define routes, and start serving API requests and static frontend files. Add the code right after the avatar generation function:


func main() {
   // Serve the generate-avatar endpoint
   http.HandleFunc("/generate-avatar", generateAvatarHandler)

   // Serve static HTML for the frontend
   fs := http.FileServer(http.Dir("./static"))
   http.Handle("/", fs)

   // Start the server
   port := ":8080"
   fmt.Printf("Server is running at http://localhost%s\n", port)
   log.Fatal(http.ListenAndServe(port, nil))
}

The code above initializes and starts an HTTP server that handles requests for the application. It defines the /generate-avatar route, which links to the handler responsible for processing audio files and generating avatar videos via the Simli API.

It also serves static HTML files from the ./static directory (which we’ll create shortly) to provide a simple frontend interface for users. Finally, the server runs on port 8080, which logs its address for easy accessibility to test or deploy.

Create the Static File

Now, you need to create the static file to serve as the frontend interface. Create a folder called static, and inside it, create an index.html file. Add this:


<!DOCTYPE html>
<html lang="en">
 <head>
   <meta charset="UTF-8" />
   <meta name="viewport" content="width=device-width, initial-scale=1.0" />
   <title>Avatar Video</title>
   <script src="https://cdn.tailwindcss.com"></script>
 </head>
 <body
   class="bg-gray-100 min-h-screen flex flex-col items-center justify-center p-4"
 >
   <div class="max-w-lg w-full bg-white shadow-lg rounded-lg p-6 space-y-6">
     <h1 class="text-2xl font-bold text-gray-800 text-center">
       Generated Avatar Video
     </h1>
     <button
       id="generate"
       class="w-full bg-blue-500 hover:bg-blue-600 text-white font-semibold py-2 px-4 rounded-md focus:outline-none focus:ring-2 focus:ring-blue-400"
     >
       Generate Avatar
     </button>
     <div>
       <h2 class="text-lg font-semibold text-gray-700 text-center">
         Video Playback
       </h2>
       <video
         id="avatar-video"
         controls
         class="w-full mt-4 rounded-lg hidden"
       ></video>
     </div>
   </div>

   <script>
     document
       .getElementById("generate")
       .addEventListener("click", async () => {
         try {
           // Fetch the video URLs from the backend
           const response = await fetch("/generate-avatar", { method: "GET" });

           if (!response.ok) {
             alert("Failed to generate avatar");
             return;
           }

           const data = await response.json();

           // Display the video in the browser
           const videoElement = document.getElementById("avatar-video");
           videoElement.src = data.mp4_url; // Use MP4 URL for playback
           videoElement.classList.remove("hidden");
         } catch (error) {
           console.error("Error:", error);
           alert("An error occurred while generating the avatar");
         }
       });
   </script>
 </body>
</html>

Test the application

Now that we’re done, let’s test the application by starting it up. Run this command:

go run main. Go

Open http://localhost:8080/ in your local browser and test it out:

Wasn't so hard, was it?

That's how to create an AI avatar in Go using Simli

In this tutorial, we looked at how to create an AI avatar in Go through a library that uses Simli sdk for AI. It's important to note that the sdk is still in early development, and more Simli features are still being added.

Please share if you found this helpful.

Forward Proxy vs Reverse Proxy vs Load Balancers

Oyedele Temitope — Mon, 23 Dec 2024 16:20:18 +0000

Have you ever wondered how some of the world’s largest websites handle millions of users simultaneously without crashing or how they transfer your data securely when directing you to the right server?

That's because of some behind-the-scenes tools and components like forward proxies, reverse proxies, and load balancers. These components are considered part of the backbone of modern web infrastructure. It helps organizations scale, secure, and optimize their systems.

In this tutorial, we'll examine these three components and break down each of them in simple terms to show how they work and why they matter.

What Is a Forward Proxy?

A forward proxy is a server that acts as an intermediary between a client and the webserver holding the desired data.

Imagine you’re planning to dine at a popular restaurant but do not want to interact directly with the staff, probably because you're too busy, shy, or for reasons best known to you. Instead, you have a personal assistant who makes the reservation on your behalf. The restaurant staff never interacts directly with you; they only communicate with your assistant.

You can liken it to the way forward proxies work. In this case, you are acting like the laptop used to browse the internet, and your personal assistant is the forward proxy server. A forward proxy server acts as a middleman between your private network and the public internet, where your request goes out.

Why Forward Proxies Are So Important

Some of the reasons why forward proxies are so important include:

Protection and Filtering: A forward proxy can act as a means of protection by filtering traffic and also blocking any harmful website, scripts, or even code before the response gets forwarded back to you.
Logging and Monitoring: A forward proxy has the ability to log user activities. It can show which websites are being visited and by whom. This comes in handy if you're looking to identify any form of malicious activity.
Caching Responses: One of the cool thing about a forward proxy is that it caches responses. Let's say, for example, you want to access a resource from a website. Forward proxy will fetch the resource and cache it locally. If another user requests to access the same resource, the forward proxy delivers the cached copy without needing to fetch it from the web again. This way, it saves bandwidth and reduces any unnecessary traffic to the internet.

What Is a Reverse Proxy?

As the name suggests, a reverse proxy is a type of proxy server, but in reverse. Instead of managing outgoing requests from a client like the way a forward proxy does, a reverse proxy manages incoming requests on behalf of backend servers.

Let’s revisit the restaurant analogy. After your assistant makes the reservation and you arrive at the restaurant, you check in at the reception desk instead of searching for a free table by yourself. The receptionist takes you to the appropriate table to ensure that the restaurant's dining area is organized, efficient, and not overcrowded. In this analogy, the receptionist is acting as a reverse proxy.

A reverse proxy sits in front of the backend servers and handles incoming client requests. It then distributes these requests to the appropriate servers based on load, availability, or other criteria.

Why Use a Reverse Proxy?

Some of the reasons why you should use a reverse proxy include:

Load Balancing: You can use a reverse proxy to distribute incoming traffic across many backend servers to ensure that no single server is overworked. It also improves the performance and reliability of the application.
Improved Security: A reverse proxy conceals the backend servers' details from clients and acts as a single point of entry. It can also handle encryption, such as SSL/TLS, to ensure clients have a secure connection to the service.
Centralized Traffic Management: A reverse proxy gives you an overview of all incoming traffic; thus, you have better control, monitoring, and optimization.
Caching and Compression: Like forward proxies, reverse proxies can also cache responses coming from the backend servers to reduce the load and improve response times for frequently accessed resources.

What Is a Load Balancer?

A load balancer can be described as a tool or device that distributes incoming network or application traffic evenly across many servers. It ensures no single server is overwhelmed and helps maintain performance, availability, and reliability.

Still using the restaurant illustration, after the receptionist directs you to the dining area, you don’t approach a waiter randomly to place your order. Instead, there would be a floor manager who assigns you a waiter who is less busy to attend to you. This will allow every waiter to handle a fair number of guests and ensure that none of the waiters gets overworked, thus keeping the dining experience smooth.

In this scenario, you the customer, represent the incoming requests, the waiters are the backend servers handling those requests, while the floor manager is the load balancer, who makes sure that the distribution is even and the operation is smooth.

Why Use a Load Balancer?

You should use a load balancer for the following reasons:

Efficient Traffic Distribution: Just as the floor manager ensures that no single waiter is tasked with too much work, a load balancer does something similar by distributing traffic evenly across many servers, which ensures a smooth and efficient operation.
Failover and Redundancy: Load balancers help avoid situations where there is an interruption in service by redirecting traffic to an available server when a server goes down.
Improved Performance: A load balancer is used to improve performance as it balances traffic in order to maintain a consistent user experience even during peak hours.
Scalability: Load balancers support scaling by integrating new servers easily as demand increases, and this makes them ideal for applications.

Difference Between Forward Proxies, Backward Proxies, and Load Balancers

Forward proxies, reverse proxies, and load balancers all act as high-level intermediaries in network communication, but they serve different purposes and are positioned in different parts of the infrastructure.

When it comes to the direction of traffic, forward proxies manage outbound traffic from clients, reverse proxies, on the other hand, manage inbound traffic to servers, and load balancers distribute incoming traffic among multiple servers.

Also, forward proxies focus on client anonymity and filtering, reverse proxies optimize and secure server traffic, and load balancers prioritize traffic distribution and server efficiency.

Regarding security, forward proxies protect users, reverse proxies protect servers, and load balancers ensure reliability without a primary focus on security.

The table below shows detailed information about their differences:

Feature	Forward Proxy	Reverse Proxy	Load Balancer
Primary Purpose	Intermediary for client requests to external servers.	Intermediary for external client requests to backend servers.	Distributes traffic across multiple servers to balance load.
Client Interaction	Represents the client to the web server.	Represents the server to the client.	Does not directly represent either but focuses more on balancing.
Traffic Direction	Handles outgoing requests from clients to servers.	Handles incoming requests to servers.	Manages incoming requests and balances load evenly across servers.
Security Focus	Protects clients by hiding their identities while simultaneously filtering traffic.	Protects backend servers by hiding their details and also helps manage encryption.	Offers less in terms of security but can be integrated with firewalls and SSL termination.
Caching	Caches frequently accessed content locally to save bandwidth.	Caches server responses to improve performance.	Rarely caches but focuses on routing and distribution.

Conclusion

In this article, we examined three behind-the-scenes components of modern web infrastructure. We examined what they each do, why they are important, and their differences.

While each performs a different function, when all put together, they can optimize traffic flow, enhance security, and make web applications scalable and reliable. Knowing how they work and how to use them would help build efficient and high-performing systems.

How to Set Up Authorization in a Bookstore Management System with Go, HTMX, and Permit.io

Oyedele Temitope — Fri, 29 Nov 2024 09:41:57 +0000

Authorization is important when building applications, as it determines what actions and resources a user is allowed to access after they authenticate.

In this article, we'll take a look at how to implement authorization using permit.io. To demonstrate it, we'll be building a simple bookstore app using Golang and HTMX (I'm a huge fan).

Table of Content

Prerequisites
Project Scope
Project Setup
- Setup the Database
- Install Dependencies
- Setup your PDP (Policy Decision Point) Container
Build the Application
- Configure Database Connection
- Create the Handlers
- Create Authorization Middleware
- Create the Models
- Create the HTML Templates
Test the Application
Conclusion

Prerequisites

To follow through this tutorial, the following prerequisites should be met:

Golang installed along with a basic understanding of it.
A Permit.io account.
Docker installed.
Basic understanding of HTML, HTTP, and REST APIs.
PostgreSQL (database).
Familiarity with SQL.

Project Scope

For this demonstration, we'll keep things simple. We'll have two user types, an admin and a standard user. Both will be registered on Permit.io. Upon login, the database will consult Permit.io to determine the user's role and authorize their actions.

All users (admins included) can read books. Admins can also add, delete, and update books. Standard users are limited to reading books.

This tutorial will guide you through setting up a bookstore application with basic authorization. We’ll implement:

Authorization Logic: Define roles (Admin and Standard User) using Permit.io to restrict or grant access to different resources.
Database: Set up a PostgreSQL database to store book and user data.
Handlers: Implement routes for viewing, adding, updating, and deleting books with access control checks.
Frontend: Use HTMX to load book data dynamically.

Project Setup

In setting up the project, we’ll start by setting up permit.io. Navigate to your dashboard workspace and create a new project. I’ll give mine the name of bookstore.

This will create two environments: a development environment and a production environment.

Since we’re working locally, we’ll use the development environment. Click on Open dashboard in the Development environment and then on Create Policy. You’ll be asked to create a new resource first. Click create resource. Give it a name and state the actions. For this project, I’ll name mine books, and the action will be create, update, delete, and view.

Next, navigate to the policy editor section. By default, you should see an admin role already created. You just need to tick the view action we added, as it is not recognized by default. You need another role. This will be for users with only permission to read.

Click Create then Role and give it the name of user. Once created, you should see it in the policy editor and tick view in the user role you just created like so:

The next thing is to register the users who would be authorized by permit.io. Navigate back to your home menu through the sidebar menu you should still have something like this:

Click on Add users and then add, then add user. Fill in the details that will correspond to your users in the database.

Once that is done, navigate back to your project. In the Development For the environment for the bookstore project, click on the 3 dotted icon. You’ll see an option to copy the API key. Copy and save it somewhere, as you’ll be needing it for the project.

Setup the Database

Create a PostgreSQL database called bookstore. You’ll need to set up two tables:

users table: Stores user credentials and roles:


CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  username VARCHAR(255) NOT NULL,
  password_hash VARCHAR(255) NOT NULL,
  role VARCHAR(50) NOT NULL
);

Go ahead and populate this, but make each user have a role of admin and user, respectively, and make sure they match the users added on Permit.io.

books table: Stores book details:


CREATE TABLE books (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  title VARCHAR(255) NOT NULL,
  author VARCHAR(255) NOT NULL,
  published_at DATE,
  created_at TIMESTAMPTZ DEFAULT now()
);

You don’t need to populate this we’ll be doing that in the code.

Install Dependencies

You’ll need to install the following dependencies:

github.com/permitio/permit-golang: Provides tools for handling role-based access control (RBAC) and permission management with Permit.io in Go applications.
github.com/google/uuid: This provides functions to generate and work with universally unique identifiers (UUIDs).
github.com/gorilla/mux: Helps to Implement an HTTP request router and dispatcher for handling routes in a web application.
github.com/joho/godotenv: This loads environment variables from a .env. file into the application, making it easier to manage configuration settings.
github.com/lib/pq: This is Go’s Postgres driver for communicating with PostgreSQL databases.
golang.org/x/crypto: Implements supplementary cryptographic algorithms and libraries that are not included in Go's standard library.

To install these dependencies, you need to initialize initializes a new Go module. This is the starting point for dependency management in Go.

Run this command:

go mod init bookstore

Next, run this command:


go get github.com/google/uuid \
       github.com/gorilla/mux \
       github.com/joho/godotenv \
       github.com/lib/pq \
       github.com/permitio/permit-golang \
       golang.org/x/crypto

This will install all the dependencies listed above.

Setup your PDP (Policy Decision Point) Container

To set up the PDP, you’ll need to start up docker. Once you do, open up your terminal and run this command:

docker pull permitio/pdp-v2:latest

After which you need to run the container with this command:

 docker run -it -p 7766:7000 --env PDP_DEBUG=True --env PDP_API_KEY=<YOUR_API_KEY> permitio/pdp-v2:latest

Replace the part that says <YOUR_API_KEY> with your actual API key. Now, let’s start building.

Build the Application

To build the application, this is how our project structure will be:


Bookstore                
├── config               
│   └── config.go        
│
├── handlers             
│   └── handlers.go      
│
├── middleware           
│   └── middleware.go    
│
├── models               
│   └── models.go        
│
├── templates            
│   ├── add.html         
│   ├── books.html       
│   ├── index.html       
│   ├── layout.html      
│   ├── login.html       
│   └── update.html      
│
├── main.go              
└── .env

Let's first add our API Key inside a .env file. Create one, and then your permit API key like so:

export PERMIT_API_KEY=”your_api_key”

Configure Database Connection

Create a folder called config. Inside it, create a file called config.go. Add the following code:


package config

import (
  "database/sql"
  "fmt"

  _ "github.com/lib/pq"
)

type Config struct {
  DB       *sql.DB
  Port     string
  DBConfig PostgresConfig
}

type PostgresConfig struct {
  Host     string
  Port     string
  User     string
  Password string
  DBName   string
}

func NewConfig() *Config {
  return &Config{
    Port: "8080",
    DBConfig: PostgresConfig{
      Host:     "localhost",
      Port:     "5432",
      User:     "bookstore_user",
      Password: "your_password",
      DBName:   "bookstore_db",
    },
  }
}

func (c *Config) ConnectDB() error {
  connStr := fmt.Sprintf("host=%s port=%s user=%s password=%s dbname=%s sslmode=disable",
    c.DBConfig.Host,
    c.DBConfig.Port,
    c.DBConfig.User,
    c.DBConfig.Password,
    c.DBConfig.DBName,
  )

  db, err := sql.Open("postgres", connStr)
  if err != nil {
    return fmt.Errorf("error opening database: %v", err)
  }

  if err := db.Ping(); err != nil {
    return fmt.Errorf("error connecting to database: %v", err)
  }

  c.DB = db
  return nil
}

This is just us setting up a configuration to connect to a PostgreSQL database.

Create the Handlers

Next, create a folder called handlers, and inside it, create a file called handlers.go. Inside it, add the following code:


package handlers

import (
  "bookstore/middleware"
  "bookstore/models" 
  "context"
  "database/sql"
  "fmt"
  "html/template"
  "net/http"
  "strings"
  "time"

  "github.com/google/uuid"
  "github.com/permitio/permit-golang/pkg/config"
  "github.com/permitio/permit-golang/pkg/enforcement"
  permitModels "github.com/permitio/permit-golang/pkg/models"
  "github.com/permitio/permit-golang/pkg/permit"
)

var tmpl = template.Must(template.ParseGlob("templates/*.html"))

func StringPtr(s string) *string {
  return &s
}

type Handlers struct {
  db           *sql.DB
  permitClient *permit.Client
}

func NewHandlers(db *sql.DB, apiKey string) *Handlers {
  permitConfig := config.NewConfigBuilder(apiKey).
    WithPdpUrl("http://localhost:7766").
    Build()
  permitClient := permit.NewPermit(permitConfig)
  if permitClient == nil {
    panic("Failed to initialize Permit.io client")
  }

  return &Handlers{
    db:           db,
    permitClient: permitClient,
  }
}

Aside from importing the packages, what we’re trying to do here is create a structure that holds the database connection and permit.io. We are also providing an initialization function that sets up Permit.io with local PDP.

Right after the NewHandlers add this in:


func (h *Handlers) LoginHandler() http.HandlerFunc {
        return func(w http.ResponseWriter, r *http.Request) {
                if r.Method == http.MethodGet {
                        if err := tmpl.ExecuteTemplate(w, "login.html", nil); err != nil {
                                http.Error(w, "Error rendering template", http.StatusInternalServerError)
                                return
                        }
                        return
                }

                username := r.FormValue("username")
                password := r.FormValue("password")

                user, err := middleware.LoginUser(h.db, username, password)
                if err != nil {
                        http.Error(w, "Invalid login credentials", http.StatusUnauthorized)
                        return
                }
                role := user.Role

                http.SetCookie(w, &http.Cookie{
                        Name:     "username",
                        Value:    username,
                        Path:     "/",
                        Expires:  time.Now().Add(24 * time.Hour),
                        HttpOnly: true,
                        Secure:   r.TLS != nil,
                })

                ctx, cancel := context.WithTimeout(context.Background(), 15*time.Second)
                defer cancel()

                permitUser := permitModels.NewUserCreate(username)
                permitUser.SetAttributes(map[string]interface{}{
                        "role": role,
                })

                _, _ = h.permitClient.SyncUser(ctx, *permitUser)

                data := struct {
                        Username string
                        Role     string
                }{
                        Username: username,
                        Role:     role,
                }

                if err := tmpl.ExecuteTemplate(w, "index.html", data); err != nil {
                        http.Error(w, "Error displaying page", http.StatusInternalServerError)
                }
        }
}

The LoginHandler does the following:

Handles both GET (show login form) and POST (process login).
Authenticates users against the database.
Sets session cookies for authenticated users.
Syncs user data with Permit.io for authorization.
Renders appropriate templates based on login success/failure.

The next step is to add a book handler to access the books. It will also utilize permit.io to verify the user's role. Add the following code right after the LoginHandler:


func (h *Handlers) BooksHandler() http.HandlerFunc {
        return func(w http.ResponseWriter, r *http.Request) {
                cookie, err := r.Cookie("username")
                if err != nil {
                        http.Error(w, "Unauthorized access: no username found", http.StatusUnauthorized)
                        return
                }
                username := cookie.Value

                role, err := middleware.GetUserRole(h.db, username)
                if err != nil {
                        http.Error(w, "Error retrieving user role", http.StatusInternalServerError)
                        return
                }

                user := enforcement.UserBuilder(username).
                        WithAttributes(map[string]interface{}{
                                "role": role,
                        }).
                        Build()

                resource := enforcement.ResourceBuilder("books").
                        WithTenant("default").
                        Build()

                permitted, err := h.permitClient.Check(user, "view", resource)
                if err != nil {
                        http.Error(w, "Error checking permissions", http.StatusInternalServerError)
                        return
                }

                if !permitted {
                        http.Error(w, "Access denied", http.StatusForbidden)
                        return
                }

                rows, err := h.db.Query("SELECT id, title, author, published_at, created_at FROM books")
                if err != nil {
                        http.Error(w, "Error fetching books", http.StatusInternalServerError)
                        return
                }
                defer rows.Close()

                var books []models.Book
                for rows.Next() {
                        var book models.Book
                        var publishedAt sql.NullTime

                        err := rows.Scan(&book.ID, &book.Title, &book.Author, &publishedAt, &book.CreatedAt)
                        if err != nil {
                                http.Error(w, "Error reading book data", http.StatusInternalServerError)
                                return
                        }

                        if publishedAt.Valid {
                                book.PublishedAt = &publishedAt.Time
                        }

                        books = append(books, book)
                }

                if err = rows.Err(); err != nil {
                        http.Error(w, "Error reading book data", http.StatusInternalServerError)
                        return
                }

                if err := tmpl.ExecuteTemplate(w, "books.html", books); err != nil {
                        http.Error(w, "Error displaying books", http.StatusInternalServerError)
                }
        }
}

The BookHandler does the following:

Checks user authentication via cookies.
Verifies user role and permissions using Permit.io.
Fetches books from the database if authorized.
Renders books template with fetched data.
Handles authorization failures appropriately.

Next, you need a handler to add books. It will also verify the user's role through Permit.io to ensure only authorized users can add books:


func (h *Handlers) AddBookHandler() http.HandlerFunc {
        return func(w http.ResponseWriter, r *http.Request) {
                cookie, err := r.Cookie("username")
                if err != nil {
                        http.Error(w, "Unauthorized access: no username found", http.StatusUnauthorized)
                        return
                }
                username := cookie.Value

                role, err := middleware.GetUserRole(h.db, username)
                if err != nil {
        func (h *Handlers) AddBookHandler() http.HandlerFunc {
        return func(w http.ResponseWriter, r *http.Request) {
                cookie, err := r.Cookie("username")
                if err != nil {
                        http.Error(w, "Unauthorized access: no username found", http.StatusUnauthorized)
                        return
                }
                username := cookie.Value

                role, err := middleware.GetUserRole(h.db, username)
                if err != nil {
                        http.Error(w, "Error retrieving user role", http.StatusInternalServerError)
                        return
                }

                user := enforcement.UserBuilder(username).
                        WithAttributes(map[string]interface{}{
                                "role": role,
                        }).
                        Build()

                resource := enforcement.ResourceBuilder("books").
                        WithTenant("default").
                        Build()

                permitted, err := h.permitClient.Check(user, "create", resource)
                if err != nil {
                        http.Error(w, "Error checking permissions", http.StatusInternalServerError)
                        return
                }

                if !permitted {
                        w.Header().Set("Content-Type", "text/html")
                        fmt.Fprint(w, `
                                <!DOCTYPE html>
                                <html lang="en">
                                <head>
                                        <meta charset="UTF-8">
                                        <meta name="viewport" content="width=device-width, initial-scale=1.0">
                                        <title>Access Denied</title>
                                        <script>alert('You cannot add a book as you are an admin.')</script>
                                </head>
                                <body>
                                        <p>You do not have permission to add books.</p>
                                        <a href="/books">Back to Books</a>
                                </body>
                                </html>
                        `)
                        return
                }

                if r.Method == http.MethodGet {
                        if err := tmpl.ExecuteTemplate(w, "add.html", nil); err != nil {
                                http.Error(w, "Error displaying page", http.StatusInternalServerError)
                        }
                        return
                }

                if r.Method == http.MethodPost {
                        title := strings.TrimSpace(r.FormValue("title"))
                        author := strings.TrimSpace(r.FormValue("author"))
                        publishedAt := strings.TrimSpace(r.FormValue("published_at"))

                        var pubDate sql.NullTime
                        if publishedAt != "" {
                                parsedDate, err := time.Parse("2006-01-02", publishedAt)
                                if err == nil {
                                        pubDate = sql.NullTime{Time: parsedDate, Valid: true}
                                }
                        }

                        _, err := h.db.Exec("INSERT INTO books (id, title, author, published_at, created_at) VALUES ($1, $2, $3, $4, NOW())",
                                uuid.New(), title, author, pubDate)
                        if err != nil {
                                http.Error(w, "Error adding book", http.StatusInternalServerError)
                                return
                        }

                        http.Redirect(w, r, "/books", http.StatusSeeOther)
                }
        }
}

The AddBookHandler does the following:

Checks user permissions for book creation.
Handles both GET (show form) and POST (add book).
Validates input data.
Generates UUID for new books.
Handles date parsing for publication dates.
Redirects to books list after successful addition.

You need two more handlers, one for deleting and the other for updating. Add this code right after the AddBookHandler function:


func (h *Handlers) DeleteBookHandler() http.HandlerFunc {
        return func(w http.ResponseWriter, r *http.Request) {
                cookie, err := r.Cookie("username")
                if err != nil {
                        http.Error(w, "Unauthorized access: no username found", http.StatusUnauthorized)
                        return
                }
                username := cookie.Value

                role, err := middleware.GetUserRole(h.db, username)
                if err != nil {
                        http.Error(w, "Error retrieving user role", http.StatusInternalServerError)
                        return
                }

                user := enforcement.UserBuilder(username).
                        WithAttributes(map[string]interface{}{
                                "role": role,
                        }).
                        Build()

                resource := enforcement.ResourceBuilder("books").
                        WithTenant("default").
                        Build()

                permitted, err := h.permitClient.Check(user, "delete", resource)
                if err != nil {
                        http.Error(w, "Error checking permissions", http.StatusInternalServerError)
                        return
                }

                if !permitted {
                        http.Error(w, "Access denied", http.StatusForbidden)
                        return
                }

                bookIDStr := r.FormValue("id")
                bookID, err := uuid.Parse(bookIDStr)
                if err != nil {
                        http.Error(w, "Invalid book ID", http.StatusBadRequest)
                        return
                }

                _, err = h.db.Exec("DELETE FROM books WHERE id = $1", bookID)
                if err != nil {
                        http.Error(w, "Error deleting book", http.StatusInternalServerError)
                        return
                }

                http.Redirect(w, r, "/books", http.StatusSeeOther)
        }
}

The DeleteBookHandler does the following:

Verifies user permissions for deletion.
Validates book ID.
Performs database deletion.
Handles errors and redirects appropriately.

Right after the DeleteBookHandler function, add the following:


func (h *Handlers) UpdateBookHandler() http.HandlerFunc {
        return func(w http.ResponseWriter, r *http.Request) {
                cookie, err := r.Cookie("username")
                if err != nil {
                        http.Error(w, "Unauthorized access: no username found", http.StatusUnauthorized)
                        return
                }
                username := cookie.Value

                role, err := middleware.GetUserRole(h.db, username)
                if err != nil {
                        http.Error(w, "Error retrieving user role", http.StatusInternalServerError)
                        return
                }

                user := enforcement.UserBuilder(username).
                        WithAttributes(map[string]interface{}{
                                "role": role,
                        }).
                        Build()

                resource := enforcement.ResourceBuilder("books").
                        WithTenant("default").
                        Build()

                permitted, err := h.permitClient.Check(user, "update", resource)
                if err != nil {
                        http.Error(w, "Error checking permissions", http.StatusInternalServerError)
                        return
                }

                if !permitted {
                        w.Header().Set("Content-Type", "text/html")
                        fmt.Fprint(w, `
                                <!DOCTYPE html>
                                <html lang="en">
                                <head>
                                        <meta charset="UTF-8">
                                        <meta name="viewport" content="width=device-width, initial-scale=1.0">
                                        <title>Access Denied</title>
                                        <script>alert('You are not authorized to update books.')</script>
                                </head>
                                <body>
                                        <p>Access Denied. You do not have permission to update books.</p>
                                        <a href="/books">Back to Books</a>
                                </body>
                                </html>
                        `)
                        return
                }

                if r.Method == http.MethodGet {
                        bookID := r.FormValue("id")
                        var book models.Book
                        err := h.db.QueryRow("SELECT id, title, author, published_at FROM books WHERE id = $1", bookID).
                                Scan(&book.ID, &book.Title, &book.Author, &book.PublishedAt)
                        if err != nil {
                                http.Error(w, "Error fetching book", http.StatusInternalServerError)
                                return
                        }

                        if err := tmpl.ExecuteTemplate(w, "update.html", book); err != nil {
                                http.Error(w, "Error displaying update page", http.StatusInternalServerError)
                        }
                        return
                }

                if r.Method == http.MethodPost {
                        bookID := r.FormValue("id")
                        title := r.FormValue("title")
                        author := r.FormValue("author")
                        publishedAt := r.FormValue("published_at")

                        var pubDate sql.NullTime
                        if publishedAt != "" {
                                parsedDate, err := time.Parse("2006-01-02", publishedAt)
                                if err == nil {
                                        pubDate = sql.NullTime{Time: parsedDate, Valid: true}
                                }
                        }

                        _, err := h.db.Exec("UPDATE books SET title = $1, author = $2, published_at = $3 WHERE id = $4",
                                title, author, pubDate, bookID)
                        if err != nil {
                                http.Error(w, "Error updating book", http.StatusInternalServerError)
                                return
                        }

                        http.Redirect(w, r, "/books", http.StatusSeeOther)
                }
        }
}

The UpdateHandler does the following:

Checks update permissions.
Handles both GET (show edit form) and POST (update book).
Fetches existing book data for editing.
Validates and processes updates.
Handles date formatting and database updates.

Throughout the code, you’ll notice that the authorization system is built around Permit.io's role-based access control framework, which provides sophisticated permission management.

This system also enables fine-grained control over user actions and allows different levels of access for viewing, creating, updating, and deleting resources. Each operation in the application undergoes detailed permission checking and ensures that users can only perform actions for which they're authorized.

Create Authorization Middleware

Now we’re done with the handlers. Create a folder called middleware, and inside it, create a file called middleware.go. Add the following code:


package middleware

import (
        "bookstore/models"
        "database/sql"
        "fmt"
        "github.com/google/uuid"
        "golang.org/x/crypto/bcrypt"
        "time"
)

func HashPassword(password string) (string, error) {
        bytes, err := bcrypt.GenerateFromPassword([]byte(password), bcrypt.DefaultCost)
        return string(bytes), err
}

func CheckPasswordHash(password, hash string) bool {
        err := bcrypt.CompareHashAndPassword([]byte(hash), []byte(password))
        return err == nil
}

func LoginUser(db *sql.DB, username, password string) (*models.User, error) {
        fmt.Printf("Attempting login for username: %s\n", username)

        var user models.User
        var passwordHash string

        err := db.QueryRow(`
       SELECT id, username, password_hash, role, email, first_name, last_name, created_at
       FROM users
       WHERE username = $1
   `, username).Scan(
                &user.ID,
                &user.Username,
                &passwordHash,
                &user.Role,
                &user.Email,
                &user.FirstName,
                &user.LastName,
                &user.CreatedAt,
        )

        if err != nil {
                if err == sql.ErrNoRows {
                        fmt.Printf("No user found with username: %s\n", username)
                        return nil, fmt.Errorf("invalid credentials")
                }
                fmt.Printf("Database error: %v\n", err)
                return nil, err
        }

        if err := bcrypt.CompareHashAndPassword([]byte(passwordHash), []byte(password)); err != nil {
                fmt.Printf("Password comparison failed: %v\n", err)
                return nil, fmt.Errorf("invalid credentials")
        }

        user.PasswordHash = ""
        return &user, nil
}

func GetBooks(db *sql.DB) ([]models.Book, error) {
        rows, err := db.Query(`
       SELECT id, title, author, published_at, created_by, created_at
       FROM books
       ORDER BY created_at DESC
   `)
        if err != nil {
                return nil, err
        }
        defer rows.Close()

        var books []models.Book
        for rows.Next() {
                var book models.Book
                err := rows.Scan(
                        &book.ID,
                        &book.Title,
                        &book.Author,
                        &book.PublishedAt,
                        &book.CreatedAt,
                )
                if err != nil {
                        return nil, err
                }
                books = append(books, book)
        }

        return books, nil
}

func CreateBook(db *sql.DB, book *models.Book) error {
        book.ID = uuid.New()
        book.CreatedAt = time.Now()

        _, err := db.Exec(`
       INSERT INTO books (id, title, author, published_at, created_by, created_at)
       VALUES ($1, $2, $3, $4, $5, $6)
   `,
                book.ID,
                book.Title,
                book.Author,
                book.PublishedAt,
                book.CreatedAt,
        )

        return err
}

func UpdateBook(db *sql.DB, book *models.Book) error {
        result, err := db.Exec(`
       UPDATE books
       SET title = $1, author = $2, published_at = $3
       WHERE id = $4 AND created_by = $5
   `,
                book.Title,
                book.Author,
                book.PublishedAt,
                book.ID,
        )
        if err != nil {
                return err
        }

        rowsAffected, err := result.RowsAffected()
        if err != nil {
                return err
        }

        if rowsAffected == 0 {
                return fmt.Errorf("book not found or user not authorized")
        }

        return nil
}

func DeleteBook(db *sql.DB, bookID uuid.UUID, userID uuid.UUID) error {
        result, err := db.Exec(`
       DELETE FROM books
       WHERE id = $1 AND created_by = $2
   `, bookID, userID)
        if err != nil {
                return err
        }

        rowsAffected, err := result.RowsAffected()
        if err != nil {
                return err
        }

        if rowsAffected == 0 {
                return fmt.Errorf("book not found or user not authorized")
        }

        return nil
}

func GetUserRole(db *sql.DB, username string) (string, error) {
        var role string
        err := db.QueryRow("SELECT role FROM users WHERE username = $1", username).Scan(&role)
        if err != nil {
                if err == sql.ErrNoRows {
                        return "", fmt.Errorf("no user found with username %s", username)
                }
                return "", err
        }
        return role, nil
}

This middleware package helps provide secure password hashing and authentication, along with CRUD operations for managing books in a bookstore application. It uses bcrypt to hash passwords for secure storage and verifies password hashes during login. It also prevents the exposure of sensitive data.

The LoginUser function authenticates users by comparing their input with stored password hashes and retrieves the full user profile on successful login, excluding the password hash for added security.

Also, CRUD operations allow you to create, update, retrieve, and delete book records in the database, with access control to ensure only authorized users can modify or delete entries they created. The package also includes a GetUserRole function to retrieve user roles, facilitating role-based access control.

Create the Models

Create another folder called models, and inside it, create a file called models.go. And add the following:


package models

import (
        "time"

        "database/sql/driver"

        "github.com/google/uuid"
)

type NullUUID struct {
        UUID  uuid.UUID
        Valid bool
}

func (n *NullUUID) Scan(value interface{}) error {
        if value == nil {
                n.UUID, n.Valid = uuid.UUID{}, false
                return nil
        }
        n.Valid = true
        return n.UUID.Scan(value)
}

func (n NullUUID) Value() (driver.Value, error) {
        if !n.Valid {
                return nil, nil
        }
        return n.UUID[:], nil
}

type User struct {
        ID           uuid.UUID `json:"id"`
        Username     string    `json:"username"`
        PasswordHash string    `json:"-"`
        Role         string    `json:"role"`
        Email        string    `json:"email"`
        FirstName    string    `json:"first_name"`
        LastName     string    `json:"last_name"`
        CreatedAt    time.Time `json:"created_at"`
}

type Book struct {
        ID          uuid.UUID  `json:"id"`
        Title       string     `json:"title"`
        Author      string     `json:"author"`
        PublishedAt *time.Time `json:"published_at,omitempty"`

        CreatedAt time.Time `json:"created_at"`
}

type LoginRequest struct {
        Username string `json:"username"`
        Password string `json:"password"`
}

This package defines several data models for a bookstore application, including User, Book, and LoginRequest structures, along with a custom NullUUID type for handling nullable UUIDs in the database.

Almost done. The next thing you need to do is create the templates for your project. You’ll need to create templates for login and index, to add books, view books, delete books, and update books.

Create the HTML Templates

Create a folder called templates. This is where your html templates will be.
For login, create a file called login.html, and inside it, paste this:


    <!doctype html>
    <html lang="en">
      <head>
        <meta charset="UTF-8" />
        <title>Login</title>
      </head>
      <body>
        <h2>Login</h2>
        <form method="POST" action="/login">
          <label for="username">Username:</label>
          <input type="text" id="username" name="username" required /><br />
          <label for="password">Password:</label>
          <input type="password" id="password" name="password" required /><br />
          <button type="submit">Login</button>
        </form>
      </body>
    </html>

For index, create a file called `index.html`. Add this:


    <!doctype html>
    <html>
      <head>
        <title>Welcome</title>
      </head>
      <body>
        <h1>Welcome {{.Username}}!</h1>
        <p>You are logged in successfully.</p>
        <p>Your role is: {{.Role}}</p>
        <a href="/books">Go to Books</a>
        <br />
        <a href="/add">Add Book</a>
      </body>
    </html>

For viewing books, create a file called books.html. Add this:


<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Books</title>
    <link
      rel="stylesheet"
      href="https://cdn.jsdelivr.net/npm/tailwindcss@2.2.19/dist/tailwind.min.css"
    />
  </head>
  <body class="bg-gray-100">
    <div class="container mx-auto px-4">
      <h1 class="text-3xl font-bold text-center my-8">Books</h1>
      <div class="text-center mb-4">
        <a
          href="/add"
          class="bg-blue-500 text-white px-4 py-2 rounded hover:bg-blue-600"
          >Add Book</a
        >
      </div>

      {{if eq (len .) 0}}
      <p class="text-center text-gray-600">No books to fetch</p>
      {{else}}
      <div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">
        {{range .}}
        <div class="bg-white shadow-md rounded-lg p-6 relative">
          <h2 class="text-xl font-bold mb-2">{{.Title}}</h2>
          <p><strong>Author:</strong> {{.Author}}</p>
          {{if .PublishedAt}}
          <p>
            <strong>Published Date:</strong> {{.PublishedAt.Format
            "2006-01-02"}}
          </p>
          {{else}}
          <p><strong>Published Date:</strong> Unknown</p>
          {{end}}
          <p><strong>Created At:</strong> {{.CreatedAt.Format "2006-01-02"}}</p>

          <!-- Update and Delete Buttons -->
          <div class="mt-4 flex space-x-2">
            <form action="/update" method="GET">
              <input type="hidden" name="id" value="{{.ID}}" />
              <button
                type="submit"
                class="bg-yellow-500 text-white px-4 py-2 rounded hover:bg-yellow-600 focus:outline-none"
              >
                Update
              </button>
            </form>
            <form action="/delete" method="POST">
              <input type="hidden" name="id" value="{{.ID}}" />
              <button
                type="submit"
                class="bg-red-500 text-white px-4 py-2 rounded hover:bg-red-600 focus:outline-none"
              >
                Delete
              </button>
            </form>
          </div>
        </div>
        {{end}}
      </div>
      {{end}}
    </div>
  </body>
</html>

To add books, create a file called add.html. Add this:


<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Add a New Book</title>
    <link
      rel="stylesheet"
      href="https://cdn.jsdelivr.net/npm/tailwindcss@2.2.19/dist/tailwind.min.css"
    />
  </head>
  <body class="bg-gray-100">
    <div class="max-w-md mx-auto bg-white rounded-lg shadow-md p-6 mt-10">
      <h2 class="text-2xl font-bold mb-6">Add a New Book</h2>

      <!-- Form to add a new book -->
      <form action="/add" method="POST">
        <div class="mb-4">
          <label class="block text-gray-700 text-sm font-bold mb-2" for="title"
            >Title</label
          >
          <input
            type="text"
            id="title"
            name="title"
            class="shadow appearance-none border rounded w-full py-2 px-3 text-gray-700 leading-tight focus:outline-none focus:shadow-outline"
            required
          />
        </div>

        <div class="mb-4">
          <label class="block text-gray-700 text-sm font-bold mb-2" for="author"
            >Author</label
          >
          <input
            type="text"
            id="author"
            name="author"
            class="shadow appearance-none border rounded w-full py-2 px-3 text-gray-700 leading-tight focus:outline-none focus:shadow-outline"
            required
          />
        </div>

        <div class="mb-6">
          <label
            class="block text-gray-700 text-sm font-bold mb-2"
            for="published_at"
            >Published Date</label
          >
          <input
            type="date"
            id="published_at"
            name="published_at"
            class="shadow appearance-none border rounded w-full py-2 px-3 text-gray-700 leading-tight focus:outline-none focus:shadow-outline"
          />
        </div>

        <div class="flex items-center justify-between">
          <button
            type="submit"
            class="bg-indigo-600 text-white px-4 py-2 rounded-md hover:bg-indigo-700 focus:outline-none focus:shadow-outline"
          >
            Add Book
          </button>
        </div>
      </form>

      <!-- Link back to books page -->
      <div class="mt-4">
        <a href="/books" class="text-indigo-600 hover:underline"
          >Back to Books</a
        >
      </div>
    </div>
  </body>
</html>

Lastly, you need to create the main file, which is the main.go. This will be in the root folder. Create it and add the following code:


package main

import (
        "bookstore/handlers"
        "database/sql"
        "fmt"
        "log"
        "net/http"
        "os"

        "github.com/gorilla/mux"
        "github.com/joho/godotenv"
        _ "github.com/lib/pq"
)

func connectDB() *sql.DB {

        connStr := "user=bookstore_user password=1111 dbname=bookstore_db sslmode=disable"
        db, err := sql.Open("postgres", connStr)
        if err != nil {
                log.Fatal("Error connecting to the database:", err)
        }
        if err := db.Ping(); err != nil {
                log.Fatal("Cannot ping the database:", err)
        }
        fmt.Println("Successfully connected to the database!")
        return db
}

func main() {

        err := godotenv.Load()
        if err != nil {
                log.Print("Error loading .env file")
        }

        permitApiKey := os.Getenv("PERMIT_API_KEY")
        if permitApiKey == "" {
                log.Fatal("PERMIT_API_KEY environment variable is not set")
        }

        db := connectDB()
        defer db.Close()

        r := mux.NewRouter()

        h := handlers.NewHandlers(db, permitApiKey)

        r.HandleFunc("/login", h.LoginHandler()).Methods("GET", "POST")
        r.HandleFunc("/books", h.BooksHandler()).Methods("GET")
        r.HandleFunc("/add", h.AddBookHandler()).Methods("GET", "POST")
        r.HandleFunc("/delete", h.DeleteBookHandler()).Methods("POST")
        r.HandleFunc("/update", h.UpdateBookHandler()).Methods("GET", "POST")

        fmt.Println("Server starting on :8080")
        if err := http.ListenAndServe(":8080", r); err != nil {
                log. Fatal(err)
        }
}

This main package serves as the entry point for a bookstore application. It sets up database connectivity, environment configuration, and HTTP routes for handling user login and book management.

In the main function, routes are registered using the Gorilla Mux router. The handlers.NewHandlers function initializes handlers with the database and Permit.io API key. It enables functionality such as user authentication (/login) and book management (/books, /add, /delete, /update). Each route is mapped to specific HTTP methods, organizing the endpoints for different actions.

Finally, the server starts on port 8080, listening for incoming requests and logging any errors that occur. This setup ensures a structured API endpoint configuration and secure handling of environment variables.

Test the Application

Now that's about everything! Let's start up our app to see the result. To start the server, run this command:

go run main.go

Visit http://localhost:8080/login in your browser.

Let's start by testing just the permissions of the standard_user:

You'll see that the standard_user is restricted to viewing books only and cannot add, delete, or update a book.

Let's now log in using the admin_user to see what happens:

You'll see that the admin has permission to do just about anything! That's how solid and easy to use Permit is!

You can check out these resources to learn more about Permit’s authorization:

Conclusion

In this tutorial, we built a simple bookstore management app to implement role-based access control using Go, HTMX, and Permit.io. Authorization is a fundamental aspect of application security, as it ensures that users can only access what they’re allowed to.

Implementing an effective access control model like RBAC or ABAC into your application would not only secure your application but also enhance its scalability and compliance.

Understanding the React Cache function

Oyedele Temitope — Thu, 12 Sep 2024 10:06:04 +0000

With React's ecosystem expanding, one of the more powerful tools for optimizing data fetching is the cache function. This built-in feature allows you to do a lot of things like manage and store server data effectively, reduce redundant network requests and also improve overall app performance.

In this article, we'll look at the cache function in React, its benefits, and how to use it.

What is React `cache` Function

The cache function released by React is designed to optimize performance. It does so by avoiding unnecessary computations when the same arguments are passed to a function. This is possible through a mechanism known as memoization, where the results of function calls are stored and reused if the same inputs occur again.

React's cache function helps prevent a function from being executed repeatedly with the same arguments, thus saving computational resources and improving the overall efficiency of the application.

To use the cache function, you wrap the target function with cache, and React takes care of storing the results of the function calls. When the wrapped function is called again with the same arguments, React checks the cache first. If the result for those arguments exists in the cache, it returns the cached result instead of executing the function again.

This behavior ensures that the function only runs when necessary, i.e., when the arguments are different from those previously seen.

Here's a simple example demonstrating how you can use React's cache function to skip duplicate work when fetching data from a weather application:

import { cache } from 'react';
import { Suspense } from 'react';

const fetchWeatherData = async (city) => {
  console.log(`Fetching weather data for ${city}...`);
  // Simulate API call
  await new Promise(resolve => setTimeout(resolve, 2000));
  return { 
    temperature: Math.round(Math.random() * 30),
    conditions: ['Sunny', 'Cloudy', 'Rainy'][Math.floor(Math.random() * 3)]
  };
};

const getCachedWeatherData = cache(fetchWeatherData);

async function WeatherWidget({ city }) {
  const weatherData = await getCachedWeatherData(city);
  return (
    <div>
      <h2>Weather in {city}</h2>
      <p>Temperature: {weatherData.temperature}°C</p>
      <p>Conditions: {weatherData.conditions}</p>
    </div>
  );
}

function WeatherDashboard() {
  return (
    <div>
      <Suspense fallback={<div>Loading New York weather...</div>}>
        <WeatherWidget city="New York" />
      </Suspense>
      <Suspense fallback={<div>Loading London weather...</div>}>
        <WeatherWidget city="London" />
      </Suspense>
      <Suspense fallback={<div>Loading New York weather...</div>}>
        <WeatherWidget city="New York" /> {/* Duplicate */}
      </Suspense>
      <Suspense fallback={<div>Loading Tokyo weather...</div>}>
        <WeatherWidget city="Tokyo" />
      </Suspense>
    </div>
  );
}

export default WeatherDashboard;

In the code above, the cache function is applied to fetchWeatherData, creating a new function getCachedWeatherData that memorizes the results of weather data fetches. This cached function is then used within the WeatherWidget component to retrieve weather information for different cities.

The WeatherDashboard component renders multiple instances of WeatherWidget and includes a duplicate for New York, which is deliberate. This serves as a crucial proof of concept for the caching mechanism, as it prevents redundant, expensive operations when the same data is requested multiple times within a render cycle by reusing the cached result from the first call, avoiding an unnecessary network request.

This caching mechanism has several advantages, one of which is that it reduces the number of API calls you make to the server and this can greatly improve the performance and lower server load. It also ensures data consistency across components requesting the same information, and it simplifies component code by automatically handling potential duplicate requests.

It's important to note that React's cache function is intended for use in Server Components only. Each call to cache creates a new memoized function, meaning that calling cache multiple times with the same function will result in separate memoized versions that do not share the same cache.

Another thing to note is that the cache function caches both successful results and errors. So, if a function throws an error for certain arguments, that error will be cached and re-thrown upon subsequent calls with those same arguments.

Benefits of the `cache` Function

The benefits of the cache function are numerous. Below are some of its benefits:

Improved Application Performance: Reusing cached data across components reduces server requests and leads to faster response times and a smoother user experience.
Efficient Data Fetching: It minimizes redundant data-fetching operations, especially in server-side rendering or static generation. This can help save time and resources when frequently requested or costly data is involved.
Reduced Server Load:It helps reduce the load on servers, thereby improving scalability and backend reliability.
Enhanced User Experience: Faster loading times and reduced latency allow users to interact with the application easily.
Integration with Caching Strategies: The cache function complements tools like useMemo and useCallback, offering a robust approach to optimizing performance.

When to Use the Cache Function

You can use the cache function when you want to:

Prevent Redundant API Calls: If you’re fetching data from an API or database and the same function with the same arguments is called multiple times, cache ensures the request is made only once.
Optimize Expensive Computations: it can be used for resource-intensive operations that take significant time or server resources, cache can store the results, so you don’t need to recompute them for the same inputs.
Share Data Across Components: When different components in your application require the same data, the cache ensures that the data-fetching logic is reused, and this helps you avoid doing repeated work, thus, improving server efficiency.
Preload Data: You can leverage cache to preload data before a component renders. This is particularly useful for critical data that needs to be available immediately on the initial render.

Conclusion

The cache function in Next.js, combined with React's built-in caching capabilities, offers a powerful toolkit for optimizing data fetching and component rendering in your application. Caching data can help improve performance, reduce unnecessary API calls, and enhance the user experience.

Remember, React's cache function is an experimental feature and subject to change. Always refer to the latest React documentation for the most current information and usage guidelines.

Understanding the React Cache function

Oyedele Temitope — Thu, 12 Sep 2024 10:06:03 +0000

With React's ecosystem expanding, one of the more powerful tools for optimizing data fetching is the cache function. This built-in feature allows you to do a lot of things like manage and store server data effectively, reduce redundant network requests and also improve overall app performance.

In this article, we'll look at the cache function in React, its benefits, and how to use it.

What is React `cache` Function

React's cache function helps prevent a function from being executed repeatedly with the same arguments, thus saving computational resources and improving the overall efficiency of the application.

This behavior ensures that the function only runs when necessary, i.e., when the arguments are different from those previously seen.

Here's a simple example demonstrating how to use React's cache function to skip duplicate work when fetching data from a weather application:

import { cache } from 'react';
import { Suspense } from 'react';

const fetchWeatherData = async (city) => {
  console.log(`Fetching weather data for ${city}...`);
  // Simulate API call
  await new Promise(resolve => setTimeout(resolve, 2000));
  return { 
    temperature: Math.round(Math.random() * 30),
    conditions: ['Sunny', 'Cloudy', 'Rainy'][Math.floor(Math.random() * 3)]
  };
};

const getCachedWeatherData = cache(fetchWeatherData);

async function WeatherWidget({ city }) {
  const weatherData = await getCachedWeatherData(city);
  return (
    <div>
      <h2>Weather in {city}</h2>
      <p>Temperature: {weatherData.temperature}°C</p>
      <p>Conditions: {weatherData.conditions}</p>
    </div>
  );
}

function WeatherDashboard() {
  return (
    <div>
      <Suspense fallback={<div>Loading New York weather...</div>}>
        <WeatherWidget city="New York" />
      </Suspense>
      <Suspense fallback={<div>Loading London weather...</div>}>
        <WeatherWidget city="London" />
      </Suspense>
      <Suspense fallback={<div>Loading New York weather...</div>}>
        <WeatherWidget city="New York" /> {/* Duplicate */}
      </Suspense>
      <Suspense fallback={<div>Loading Tokyo weather...</div>}>
        <WeatherWidget city="Tokyo" />
      </Suspense>
    </div>
  );
}

export default WeatherDashboard;

In the code above, the cache function is applied to fetchWeatherData, creating a new function getCachedWeatherData that memorizes the results of weather data fetches. This cached function is then used within the WeatherWidget component to retrieve weather information for different cities.

The WeatherDashboard component renders multiple instances of WeatherWidget, including a duplicate for New York, which is deliberate. This serves as a crucial proof of concept for the caching mechanism, as it prevents redundant expensive operations when the same data is requested multiple times within a render cycle by reusing the cached result from the first call, avoiding an unnecessary network request.

This caching mechanism has several advantages: it reduces the number of API calls, resulting in improved performance and lower server load; it ensures data consistency across components requesting the same information; and it simplifies component code by automatically handling potential duplicate requests.

This feature is part of React's broader strategy to enhance performance and efficiency, complementing existing mechanisms like the virtual DOM and the useMemo and useCallback hooks, which also employ memoization techniques to optimize component rendering and function references.

Benefit of the `cache` Function

The benefits of using React's cache function primarily revolve around performance optimization, specifically in terms of reducing unnecessary computations and data fetching operations. Below are some key benefits of the cache function:

Improved Application Performance: Caching helps in reducing the number of server requests needed by reusing cached data across multiple components. This leads to faster response times and a smoother user experience, as the application spends less time waiting for data to be fetched or computed.
Efficient Data Fetching: In scenarios involving data fetching, especially in server-side rendering or static generation contexts, caching can significantly reduce the amount of data that needs to be fetched from the server. This is particularly beneficial in applications where the same data is requested frequently or where data fetching is costly in terms of performance.
Reduced Load on Servers: By serving data from the cache instead of making new requests to the server, caching helps in distributing the load more evenly. This can lead to better scalability and reliability of backend services, as they are not overwhelmed by frequent identical requests.
Enhanced User Experience: Faster loading times and reduced latency contribute to a better user experience. Users can interact with the application more quickly, as the application spends less time fetching or computing data.
Support for Advanced Caching Strategies: React's cache function complements other caching mechanisms and strategies, such as memoization (useMemo) and callback memoization (useCallback). These tools together offer a comprehensive approach to optimizing React applications, allowing developers to fine-tune performance based on specific needs.

When to Use the Cache Function

You can use the cache function when you want to :

Memoize Expensive Data Fetches: If your Server Component relies on fetching data from an API or performing complex calculations, wrapping the data fetching function with cache can significantly improve performance. The function will only be executed once for the same arguments, and subsequent renders will use the cached result.
Preload Data: You can leverage cache to preload data before a component even renders. This is particularly useful for critical data that needs to be available immediately on the initial render.
Share Results Across Components: When multiple Server Components require the same data fetched from the server, using cache ensures a single request is made, and the result is shared across all components, reducing redundant server calls.

Conclusion

The cache function in Next.js, combined with React's built-in caching capabilities, offers a powerful toolkit for optimizing data fetching and component rendering in your application. By strategically caching data and computations, you can significantly improve performance, reduce unnecessary API calls, and enhance the user experience.

Remember, React's cache function is an experimental feature and subject to change. Always refer to the latest React documentation for the most current information and usage guidelines.

Understanding the Child Process Module in Node.js

Oyedele Temitope — Mon, 09 Sep 2024 11:21:11 +0000

The child process module is significant in Node.js applications as it helps facilitate parallel processing and allows you to offload resource-intensive tasks to separate processes.

In this article, we'll take a look at the child process module, explaining its purpose, use cases, and how to create it.

What is the child process module

The child process is a core module that allows users to create and control subprocesses. These processes can execute system commands, run scripts in various languages, or even fork new instances of Node.js.

The primary purpose of the child process module is to allow the execution of multiple processes simultaneously without blocking the main event loop.

Using a child process is important for applications that need to handle CPU-intensive operations or execute external commands and scripts. With it, your applications can maintain high performance and responsiveness.

Use cases for child processes

The child processes can be used for tasks including the following:

Parallel processing: Child processing enables parallel processing by allowing your applications to distribute workloads across multiple CPU cores, considerably improving performance for CPU-intensive activities such as image processing and data analysis.
Running shell scripts: Child processes can be used to execute shell scripts. You can use the exec technique to run shell commands and capture their output, and also the spawn method which offers greater control when directly running scripts.
Communication with other services: The child processes play a vital role when it comes to communication. It communicates with external services such as databases, APIs, or microservices. They can be used to make calls to external APIs, do database queries, and communicate with other microservices.

Creating a child process

To create a child process, Node.js provides us with four primary methods for creating a child process which are the exec(),execFile(),spawn(),fork()

The `exec()` method

The exec() method runs a command in a shell and buffers the output. It is handy for running shell commands and recording the output. However, due to buffering, it has a memory limit.

Below is an example of using exec() method to execute a command that fetches and processes some system information.



const { exec } = require("child_process");

exec("df -h", (error, stdout, stderr) => {
  if (error) {
    console.error(`exec error: ${error.message}`);
    return;
  }
  if (stderr) {
    console.error(`stderr: ${stderr}`);
    return;
  }

  const lines = stdout.trim().split("\n");
  const diskInfo = lines[1].split(/\s+/);

  const totalSpace = diskInfo[1];
  const usedSpace = diskInfo[2];
  const availableSpace = diskInfo[3];
  const usagePercent = diskInfo[4];

  console.log(`Total Space: ${totalSpace}`);
  console.log(`Used Space: ${usedSpace}`);
  console.log(`Available Space: ${availableSpace}`);
  console.log(`Usage: ${usagePercent}`);
});

This will execute the df -h command, parse its output, and display the total, used, and available disk space along with the usage percentage.

When you run the code, you should see something like this:

The `execFile()` method

The execFile() method runs an executable file without a shell. It’s more efficient than exec() for running binaries and scripts directly since it avoids the overhead of a shell.

Below is an example of how to use the execFile() method:



const { execFile } = require('child_process');
execFile("node", ["--version"], (error, stdout, stderr) => {
  if (error) {
    console.error(`execFile error: ${error.message}`);
    return;
  }
  if (stderr) {
    console.error(`stderr: ${stderr}`);
    return;
  }
  console.log(`stdout: ${stdout}`);
});

This example demonstrates running the Node.js executable to get its version. execFile() is preferred when the command does not require shell features.

The `spawn()` method

Unlike the exec methods, which are primarily used for executing shell commands or executables and capturing their output, the spawn() method offers more control over child processes through stream-based output handling, direct interaction with executables, event-driven communication.

The spawn() method can be used in complex scenarios where direct interaction is necessary. spawn() launches a new process with a given command and provides streams i.e stdout, stderr for directly handling the process's output and errors.

Below is an example of how to use the spawn() method



const { spawn } = require("child_process");

const ls = spawn("ls", ["-lh", "/usr"]);

ls.stdout.on("data", (data) => {
  console.log(`stdout: ${data}`);
});

ls.stderr.on("data", (data) => {
  console.error(`stderr: ${data}`);
});

ls.on("close", (code) => {
  console.log(`child process exited with code ${code}`);
});

In this example, spawn() runs the ls command with specific arguments and attaches event listeners to handle the process’s output and exit status.

Running the code, you should see something like this:

The `fork()` method

The fork() method can be said to be a variation of spawn() designed for creating new Node.js processes. Unlike spawn(), which can launch any type of process, the fork() method is optimized for creating child processes that are themselves Node.js applications.

It provides an additional communication channel into the child process, allowing for simple message transmission between the parent and child processes.

Below is an example of how to use the fork() method.

The parent.js file:



const { fork } = require("child_process");

const child = fork("child.js");

child.on("message", (message) => {
  console.log(`Message from child: ${message}`);
});

child.send("Hello, child process!");

The child.js file:



process.on("message", (message) => {
  console.log(`Message from parent: ${message}`);
  process.send("Hello from child process!");
});

Here, the fork() creates a new Node.js process running the child.js script. It allows message passing between the parent and child process using send() and message events.

When you run the code, you should see something like this:

Differences between `fork()` and `spawn()`

Some of the differences between fork and spawn include:

Built-in communication channel: The fork() automatically sets up an IPC (inter-process communication) channel between the parent and child processes. In contrast, spawn() does not establish this channel by default; developers must manually configure IPC if needed.
Isolation and independence: Each child process generated by fork() is a separate Node.js process with its own V8 instance. The spawn() method, on the other hand, can launch any process, including Node.js apps, and does not provide the same level of isolation.
Use case specificity: The fork() technique is specifically intended for situations in which you need to generate worker processes that are part of the same application but operate concurrently. In contrast, spawn() is more general-purpose and is used when you need to launch arbitrary commands or scripts outside of the Node.js ecosystem.

Handling child process output

When a child process is created, it produces output in two main streams:stdout and stderr. These streams hold the results of the command or script run by the child process. To collect this output, add event listeners to the child process object for the data event on stdout and stderr.

Node.js provides you with several event listeners that are particularly useful for handling child process output and errors. Some of these include:

Data: Data event is emitted by the streams that represent the child process's stdout and stderr.
Error:The error event is triggered when an error occurs during the execution of the child process. This could be due to issues with the command itself or problems reading from stdout or stderr.
Close:The close event is emitted when the child process ends, indicating whether it terminated successfully or was killed.

Let's take a look at an example that shows how to spawn a child process, capture its output, and handle any errors that may occur.

We'll use the spawn() method to launch a simple command (echo) and listen for output and errors.



const { spawn } = require("child_process");

const child = spawn("echo", ["Hello, world"]);

child.stdout.on("data", (data) => {
  console.log(`stdout: ${data}`);
});

child.stderr.on("data", (data) => {
  console.error(`stderr: ${data}`);
});

child.on("error", (error) => {
  console.error(`Error occurred: ${error.message}`);
});

child.on("close", (code) => {
  console.log(`Child process exited with code ${code}`);
});

In this example, the parent process spawns a child process to execute the echo command, which simply prints Hello, world! to the terminal.

The parent process captures this output through the data event listeners attached to stdout and stderr. Additionally, it listens for the error event to catch any errors that might occur during the execution of the child process.

Finally, the close event indicates when the child process has finished executing, along with the exit code, which can be used to determine if the process was completed successfully.

Communication between processes

In distributed systems and concurrent programming, process communication is critical for component coordination. Node.js improves this communication with its child process module. This allows you to create child processes and facilitate inter-process communication (IPC).

This IPC mechanism, characterized by the exchange of data between parent and child processes, is pivotal for constructing modular and scalable applications.

There are several methods for facilitating; one that stands out is message passing via the send() method and message. This method leverages the send() function available on child process objects to send messages to child processes, and child processes listen for these messages using the message event.

Let's illustrate this with a practical example. We'll create a simple application where a parent process forks a child process and communicates with it using the send() method and message event.

The parent file, which is the parent.js, will look like this:



const { fork } = require("child_process");

const child = fork("./child.js");

child.send({ greeting: "Hello from parent!" });

child.on("message", (msg) => {
  console.log("Message from child:", msg);
});

console.log("Waiting for response...");

The child process file, which is child.js:



process.on("message", (msg) => {
  console.log("Message received from parent:", msg);

  process.send({ response: "Hello from child!" });
});

In this example, the parent process sends a message containing a greeting to the child process. The child process listens for this message, logs it, and then sends a response back to the parent process. The parent process also listens for incoming messages from the child process and logs them upon receipt.

This pattern of using send() and message events for IPC is particularly useful in scenarios where you need to coordinate actions between parent and child processes, such as sharing data, triggering actions, or implementing request-response patterns in a Node.js application.

Best practices for managing child processes

Below are some of the best practices used to manage the child process effectively:

Monitor system resources: one of the best practices is to regularly monitor the system's CPU, memory, and network usage to identify potential bottlenecks or resource leaks. Utilizing tools like top and ps can provide you with real-time insights into resource consumption.
Set timeouts for long-running processes: Use the timeout option in spawn() to automatically terminate child processes after a specified duration. This is beneficial for avoiding resource hogging by long-running activities.
Implement graceful shutdown procedures: Graceful shutdown procedures is when all requests to the server have been responded to, and no data processing work remains. Always ensure that child processes can be shut down gracefully, releasing resources and performing any necessary cleanup. This can be achieved by listening to termination signals and responding accordingly.
Apply the kill method: Use appropriate signals (e.g., SIGTERM for graceful shutdown, SIGKILL as a last resort). Verify that the process has been terminated successfully. Handle potential errors when applying the kill method.

Child process vs workers

While child processes are useful for some jobs, Node.js also provides another method for parallel execution. This method is known as workers, which is entirely different from the child process.

The worker threads module was introduced in Node.js v10.50. It provides a more efficient way to handle multithreading compared to child processes. Below is a table highlighting their differences

Feature	Worker threads	Child processes
Memory Isolation	Shares memory space with the parent process	Each child process has its own memory heap (complete isolation)
Communication	Uses message passing with less overhead (via SharedArrayBuffer)	Communicates via IPC channels with more overhead
Performance	More lightweight, lower overhead for frequent data exchange	Higher overhead, especially for frequent communication
Use Cases	Parallel computations, tasks requiring frequent data exchange	CPU-intensive tasks, running external scripts, isolated tasks
Error Isolation	Errors can affect the main thread	Errors in child processes do not affect the parent process
API Module	`worker_threads`	`child_process`
Creation Method	`new Worker()`	`spawn()`, `fork()`, `exec()`, `execFile()`
Multithreading	True multithreading with shared memory	Separate processes, no true multithreading
Overhead	Lower due to shared memory	Higher due to complete process creation
Resource Management	Managed within the same process	Separate resource allocation for each process

When to use the child process

Thechild process can be used when you need complete isolation, such as running external scripts or managing CPU-intensive tasks that could potentially crash the parent process.

When to use workers

The worker threads, on the other hand, can be used for tasks that benefit from shared memory and require frequent communication, such as data processing and parallel computations.

Conclusion

The child process module helps enable the execution of parallel tasks, running external scripts, and managing subprocesses efficiently. When you understand these methods and how to implement them, you will be able to significantly enhance your application's performance and scalability.