At the Leadership Exchange, this panel focused on what it actually takes to move beyond experimentation and turn AI into measurable ROI.

Over the past few years, many organizations have experimented with AI, but the challenge today is translating experimentation into measurable business value. Moderated by Tracy Lee, CEO at This Dot Labs, panelists featured Dorren Schmitt, Vice President IT Strategy & Innovation at Allen Media Group, Greg Geodakyan, CTO at Client Command, and Elliott Fouts, CAIO & CTO at This Dot Labs. Panelists discussed how companies are moving from early AI experiments to initiatives that deliver real results.

They began by examining how experimentation has evolved over the past year. While many organizations did not fully utilize AI experimentation budgets in 2025, 2026 is showing a shift toward more intentional investment. Structured budgets and clearly defined frameworks are enabling companies to explore AI strategically and identify initiatives with high potential impact.

The conversation then turned to alignment and ROI. Panelists highlighted the importance of connecting AI projects to corporate strategy and leadership priorities. Ensuring that AI initiatives translate into operational efficiency, productivity gains, and measurable business impact is essential. Companies that successfully align AI efforts with organizational goals are better equipped to demonstrate tangible outcomes from their investments.

Moving from pilots and proofs of concept to production was another major focus. Governance, prioritization, and workflow integration were cited as essential for scaling AI initiatives. One panelist shared that out of nine proofs of concept, eight successfully launched, resulting in improvements in quality and operational efficiency.

Panelists also explored the future of AI within organizations, including the potential for agentic workflows and reduced human-in-the-loop processes. New capabilities are emerging that extend beyond coding tasks, reshaping how teams collaborate and how work is structured across departments.

Key Takeaways

• Structured experimentation and defined budgets allow organizations to explore AI strategically and safely.
• Alignment with business priorities is essential for translating AI capabilities into measurable outcomes.
• Governance and workflow integration are critical to moving AI initiatives from pilot stages to production deployment.

Successfully leveraging AI requires a balance between experimentation, strategic alignment, and operational discipline. Organizations that approach AI as a structured, measurable initiative can capture meaningful results and unlock new opportunities for innovation.

Curious how your organization can move from AI experimentation to real impact? Let’s talk. Reach out to continue the conversation or join us at an upcoming Leadership Exchange. Tracy can be reached at tlee@thisdot.co.

At the Leadership Exchange, this was the question at the center of the Developer Panel, where leaders from across the industry unpacked what’s really changing inside engineering teams and what organizations need to do right now to keep up.

The Developer Panel at the Leadership Exchange explored the cutting edge of AI in software engineering and examined what organizations should focus on today to prepare for the future. Moderated by Jeff Cross, Co-Founder & CEO at Nx, the panel featured Victor Savkin, Cofounder & CTO at Nx, Alex Sover, Vice President of Engineering at OpenAP, Brent Zucker, Senior Director of Engineering at Visa, and Jonathan Fontanez, AI Engineering Lead at This Dot Labs. Panelists shared insights into how AI is transforming the software development lifecycle and how teams can adopt tools effectively while preparing for organizational change.

Panelists discussed emerging workflows, including CI-in-the-loop, agentic healing, and context engineering. They examined how validation, code reviews, and PRDs are evolving alongside AI capabilities and how teams are integrating external sources such as production traces to improve quality and reliability. The discussion also covered what the next generation of agentic tools might look like and how these capabilities will shape engineering practices in the near future.

Adoption of AI comes with challenges. Teams often rely on plugins or extensions without foundational understanding, and individual contributors may fear displacement. Panelists emphasized that education, governance, and skill-building are essential for teams to manage AI agents effectively while maintaining quality. They also highlighted the need to standardize workflows and ensure organizational alignment to fully leverage AI capabilities.

The conversation extended beyond technical challenges to organizational implications. Panelists discussed how teams can avoid issues like Conway’s Law, manage distributed teams effectively, and evolve engineering practices alongside AI adoption. Leadership and management strategies play a crucial role in ensuring that AI integration delivers meaningful outcomes while maintaining efficiency and alignment with business objectives.

Key Takeaways

• AI workflows require both technical and organizational preparation.
• Education, governance, and skill development are essential for successful implementation.
• Forward-looking teams are rethinking validation, CI pipelines, and context management to fully leverage agentic AI.

The discussion highlighted that adopting AI at the cutting edge is not just about new tools - it is about rethinking processes, workflows, and organizational culture. Companies that embrace this holistic approach are most likely to succeed in leveraging AI to its full potential.

Are you interested in more conversations like this? Message us for an invite to the next, or for a private discussion around these topics. Tracy can be reached at tlee@thisdot.co.

At the Leadership Exchange, leaders unpacked how AI is reshaping the SDLC and what organizations need to address beyond just coding to make adoption successful.

Moderated by Rob Ocel, VP of Innovation at This Dot Labs, the panel featured Itai Gerchikov at Anthropic and Harald Kirschner, Principal Product Manager for GitHub Copilot & VS Code at Microsoft. Panelists explored the current state of AI adoption across the software development lifecycle and shared practical insights into how organizations can effectively integrate AI tools.

Panelists discussed how companies are investing in AI tools, skills, and managed competency programs to support developers. While AI can dramatically accelerate coding, the panel emphasized that adoption affects every stage of the SDLC. Bottlenecks now appear in testing, DevOps, product delivery, and marketing as AI speeds up development. Organizations that address technical debt and process inefficiencies are better positioned to extract maximum value from AI tools.

The conversation also focused on opportunities and risks. Security, governance, and workforce education were highlighted as critical factors for adoption. Panelists stressed that AI initiatives should be aligned with broader business goals rather than pursued in isolation. They noted that companies experimenting at the cutting edge need to consider organizational readiness just as carefully as technical capabilities.

Panelists also explored how leading organizations are navigating the early stages of adoption. Those ahead of the curve are using structured experimentation, prioritizing process improvements, and continuously evaluating outcomes to refine their AI strategies. Learning from these early adopters allows other organizations to anticipate emerging trends and prepare for the next phase of AI adoption rather than simply replicating past approaches.

Key Takeaways

• Investing in AI skills and tools should be done thoughtfully, with clear alignment to business objectives.
• Examining the full SDLC helps identify bottlenecks that AI may accelerate or expose.
• Organizations can gain a competitive advantage by learning from early adopters and planning for where AI adoption is heading.

AI adoption is not just a technical initiative; it is a strategic transformation that requires attention to people, process, and technology. Organizations that balance innovation with operational discipline will be best positioned to capture the full potential of AI across the software lifecycle.

Seeing similar challenges in your own SDLC? Let’s compare notes. Join us at an upcoming Leadership Exchange or reach out to continue the conversation. Tracy can be reached at tlee@thisdot.co.

Modern web development involves transforming your source code before deploying it. We minify JavaScript to reduce file sizes, bundle multiple files together, transpile TypeScript to JavaScript, and convert modern syntax into browser-compatible code. These optimizations are essential for performance, but they create a significant problem: the code running in production does not look like the original code you wrote.

Here's a simple example. Your original code might look like this:

function calculateTotal(items) {
  return items.reduce((total, item) => {
    return total + (item.price * item.quantity);
  }, 0);
}

const total = calculateTotal(cart);
console.log(`Total is: $${total}`);

After minification, it becomes something like this:

function a(b){return b.reduce((c,d)=>c+d.price*d.quantity,0)}const e=a(f);console.log(`Total is: $${e}`);

Now imagine trying to debug an error in that minified code. Which line threw the exception? What was the value of variable d?

This is where sourcemaps come in. A sourcemap is a JSON file that contains a mapping between your transformed code and your original source files. When you open browser DevTools, the browser reads these mappings and reconstructs your original code, allowing you to debug with variable names, comments, and proper formatting intact.

How Sourcemaps Work

When you build your application with tools like Webpack, Vite, or Rollup, they can generate sourcemap files alongside your production bundles. A minified file references its sourcemap using a special comment at the end:

//# sourceMappingURL=bundle.min.js.map

The sourcemap file itself contains a JSON structure with several key fields:

{
  "version": 3,
  "sources": ["cart.js", "checkout.js"],
  "names": ["calculateTotal", "items", "total", "item"],
  "mappings": "AAAA,SAASA,...",
  "file": "checkout.min.js",
  "sourcesContent": ["function calculateTotal(items) { ... }"]
}

The mappings field uses an encoding format called VLQ (Variable Length Quantity) to map each position in the minified code back to its original location. The browser's DevTools use this information to show you the original code while you're debugging.

Types of Sourcemaps

Build tools support several variations of sourcemaps, each with different trade-offs:

Inline sourcemaps: The entire mapping is embedded directly in your JavaScript file as a base64 encoded data URL. This increases file size significantly but simplifies deployment during development.

//# sourceMappingURL=data:application/json;base64,eyJ2ZXJzaW9uIjozLC...

External sourcemaps: A separate .map file that's referenced by the JavaScript bundle. This is the most common approach, as it keeps your production bundles lean since sourcemaps are only downloaded when DevTools is open.

Hidden sourcemaps: External sourcemap files without any reference in the JavaScript bundle. These are useful when you want sourcemaps available for error tracking services like Sentry, but don't want to expose them to end users.

Why Sourcemaps

During development, sourcemaps are absolutely critical. They will help avoid having to guess where errors occur, making debugging much easier.

Most modern build tools enable sourcemaps by default in development mode.

Sourcemaps in Production

Should you ship sourcemaps to production? It depends.

While security by making your code more difficult to read is not real security, there's a legitimate argument that exposing your source code makes it easier for attackers to understand your application's internals. Sourcemaps can reveal internal API endpoints and routing logic, business logic, and algorithmic implementations, code comments that might contain developer notes or TODO items.

Anyone with basic developer tools can reconstruct your entire codebase when sourcemaps are publicly accessible. While the Apple leak contained no credentials or secrets, it did expose their component architecture and implementation patterns.

Additionally, code comments can inadvertently contain internal URLs, developer names, or company-specific information that could potentially be exploited by attackers.

But that’s not all of it. On the other hand, services like Sentry can provide much more actionable error reports when they have access to sourcemaps. So you can understand exactly where errors happened.

If a customer reports an issue, being able to see the actual error with proper context makes diagnosis significantly faster.

If your security depends on keeping your frontend code secret, you have bigger problems. Any determined attacker can reverse engineer minified JavaScript. It just takes more time. Sourcemaps are only downloaded when DevTools is open, so shipping them to production doesn't affect load times or performance for end users.

How to manage sourcemaps in production

You don't have to choose between no sourcemaps and publicly accessible ones.

For example, you can restrict access to sourcemaps with server configuration. You can make .map accessible from specific IP addresses.

Additionally, tools like Sentry allow you to upload sourcemaps during your build process without making them publicly accessible. Then configure your build to generate sourcemaps without the reference comment, or use hidden sourcemaps. Sentry gets the mapping information it needs, but end users can't access the files.

Learning from Apple's Incident

Apple's sourcemap incident is a valuable reminder that even the largest tech companies can make deployment oversights. But it also highlights something important: the presence of sourcemaps wasn't actually a security vulnerability. This can be achieved by following good security practices. Never include sensitive data in client code.

Developers got an interesting look at how Apple structures its Svelte codebase.

The lesson is that you must be intentional about your deployment configuration. If you're going to include sourcemaps in production, make that decision deliberately after considering the trade-offs. And if you decide against using public sourcemaps, verify that your build process actually removes them.

In this case, the public repo was quickly removed after Apple filed a DMCA takedown. (https://github.com/github/dmca/blob/master/2025/11/2025-11-05-apple.md)

Making the Right Choice

So what should you do with sourcemaps in your projects?

For development: Always enable them. Use fast options, such as eval-source-map in Webpack or the default configuration in Vite. The debugging benefits far outweigh any downsides.

For production: Consider your specific situation. But most importantly, make sure your sourcemaps don't accidentally expose secrets. Review your build output, check for hardcoded credentials, and ensure sensitive configurations stay on the backend where they belong.

Conclusion

Sourcemaps are powerful development tools that bridge the gap between the optimized code your users download and the readable code you write. They're essential for debugging and make error tracking more effective.

The question of whether to include them in production doesn't have a unique answer. Whatever you decide, make it a deliberate choice. Review your build configuration. Verify that sourcemaps are handled the way you expect. And remember that proper frontend security doesn't come from hiding your code.

Useful Resources

• Source map specification - https://tc39.es/ecma426/
• What are sourcemaps - https://web.dev/articles/source-maps
• VLQ implementation - https://github.com/Rich-Harris/vlq
• Sentry sourcemaps - https://docs.sentry.io/platforms/javascript/sourcemaps/
• Apple DMCA takedown - https://github.com/github/dmca/blob/master/2025/11/2025-11-05-apple.md

That’s why Vercel created BotID, an invisible CAPTCHA that has real-time protections against sophisticated bots that help you protect your critical endpoints.

In this blog post, we will explore why you should care about this new tool, how to set it up, its use cases, and some key considerations to take into account.

We will be using Next.js for our examples, but please note that this tool is not tied to this framework alone; the only requirement is that your app is deployed and running on Vercel.

Why Should You Care?

Think about these scenarios:

• Checkout flows are overwhelmed by scalpers
• Signup forms inundated with fake registrations
• API endpoints draining resources with malicious requests

They all impact you and your users in a negative way. For example, when bots flood your checkout page, real customers are unable to complete their purchases, resulting in your business losing money and damaging customer trust.

Fake signups clutter the app, slowing things down and making user data unreliable. When someone deliberately overloads your app’s API, it can crash or become unusable, making users angry and creating a significant issue for you, the owner.

BotID automatically detects and filters bots attempting to perform any of the above actions without interfering with real users.

How does it work? A lightweight first-party script quickly gathers a high set of browser & environment signals (this takes ~30ms, really fast so no worry about performance issues), packages them into an opaque token, and sends that token with protected requests via the rewritten challenge/proxy path + header; Vercel’s edge scores it, attaches a verdict, and checkBotId() function simply reads that verdict so your code can allow or block. We will see how this is implemented in a second! But first, let’s get started.

Getting Started in Minutes

1. Install the SDK:

npm install botid

1. Configure redirects

Wrap your next.config.ts with BotID’s helper. This sets up the right rewrites so BotID can do its job (and not get blocked by ad blockers, extensions, etc.):

import { withBotId } from 'botid/next/config';

const nextConfig = {
  // Your existing Next.js config
};

export default withBotId(nextConfig);

2. Integrate the client on public-facing pages (where BotID runs checks):

Declare which routes are protected so BotID can attach special headers when a real user triggers those routes.

We need to create instrumentation-client.ts (place it in the root of your application or inside a src folder) and initialize BotID once:

import { initBotId } from 'botid/client/core';

// Define the paths that need bot protection.
// These are paths that are routed to by your app.
// These can be:
// - API endpoints (e.g., '/api/checkout')
// - Server actions invoked from a page (e.g., '/dashboard')
// - Dynamic routes (e.g., '/api/create/*')

initBotId({
  protect: [
    {
      path: '/api/checkout',
      method: 'POST',
    },
    {
      // Wildcards can be used to expand multiple segments
      // /team/*/activate will match
      // /team/a/activate
      // /team/a/b/activate
      // /team/a/b/c/activate
      // ...
      path: '/team/*/activate',
      method: 'POST',
    },
    {
      // Wildcards can also be used at the end for dynamic routes
      path: '/api/user/*',
      method: 'POST',
    },
  ],
});

instrumentation-client.ts runs before the app hydrates, so it’s a perfect place for a global setup!

If we have an inferior Next.js version than 15.3, then we would need to use a different approach. We need to render the React component inside the pages or layouts you want to protect, specifying the protected routes:

import { BotIdClient } from 'botid/client';
import { ReactNode } from 'react';

const protectedRoutes = [
  {
    path: '/api/checkout',
    method: 'POST',
  },
];

type RootLayoutProps = {
  children: ReactNode;
};

export default function RootLayout({ children }: RootLayoutProps) {
  return (
    <html lang="en">
      <head>
        <BotIdClient protect={protectedRoutes} />
      </head>
      <body>{children}</body>
    </html>
  );
}

3. Verify requests on your server or API:

import { checkBotId } from 'botid/server';

export async function POST(req: Request) {
  const { isBot } = await checkBotId();

  if (isBot) {
   return new Response("Access Denied", { status: 403 });
  } 

  return new Response("✅ Success!");
}

• NOTE: checkBotId() will fail if the route wasn’t listed on the client, because the client is what attaches the special headers that let the edge classify the request!

You’re all set - your routes are now protected!

In development, checkBotId() function will always return isBot = false so you can build without friction. To disable this, you can override the options for development:

const { isBot } = await checkBotId({
    developmentOptions: {
      bypass: 'BAD-BOT', // default: 'HUMAN'
    },
  });

What happens on a failed check?

In our example above, if the check failed, we return a 403, but it is mostly up to you what to do in this case; the most common approaches for this scenario are:

• Hard block with a 403 for obviously automated traffic (just what we did in the example above)
• Soft fail (generic error/“try again”) when you want to be cautious.
• Step-up (require login, email verification, or other business logic).

Remember, although rare, false positives can occur, so it’s up to you to determine how you want to balance your fail strategy between security, UX, telemetry, and attacker behavior.

checkBotId()

So far, we have seen how to use the property isBot from checkBotId(), but there are a few more properties that you can leverage from it. There are:

isHuman (boolean): true when BotID classifies the request as a real human session (i.e., a clear “pass”). BotID is designed to return an unambiguous yes/no, so you can gate actions easily.

isBot (boolean): We already saw this one. It will be true when the request is classified as automated traffic.

isVerifiedBot (boolean): Here comes a less obvious property. Vercel maintains and continuously updates a comprehensive directory of known legitimate bots from across the internet. This directory is regularly updated to include new legitimate services as they emerge. This could be helpful for allowlists or custom logic per bot. We will see an example in a sec.

verifiedBotName? (string): The name for the specific verified bot (e.g., “claude-user”).

verifiedBotCategory? (string): The type of the verified bot (e.g., “webhook”, “advertising”, “ai_assistant”).

bypassed (boolean): it is true if the request skipped BotID check due to a configured Firewall bypass (custom or system). You could use this flag to avoid taking bot-based actions when you’ve explicitly bypassed protection.

Handling Verified Bots

• NOTE: Handling verified bots is available in botid@1.5.0 and above.

It might be the case that you don’t want to block some verified bots because they are not causing damage to you or your users, as it can sometimes be the case for AI-related bots that fetch your site to give information to a user.

We can use the properties related to verified bots from checkBotId() to handle these scenarios:

import { checkBotId } from "botid/server";
import { NextResponse } from "next/server";

export async function POST(request: Request) {
  const botResult = await checkBotId();

  const { isBot, verifiedBotName, isVerifiedBot } = botResult;

  // Check if it's ChatGPT Operator
  const isOperator = isVerifiedBot && verifiedBotName === "chatgpt-operator";

  if (isBot && !isOperator) {
    return Response.json({ error: "Access denied" }, { status: 403 });
  }

  // ... rest of your handler
  return Response.json(botResult);
} 

Choosing your BotID mode

When leveraging BotID, you can choose between 2 modes:

• Basic Mode: Instant session-based protection, available for all Vercel plans.
• Deep Analysis Mode: Enhanced Kasada-powered detection, only available for Pro and Enterprise plan users. Using this mode, you will leverage a more advanced detection and will block the hardest to catch bots

To specify the mode you want, you must do so in both the client and the server. This is important because if either of the two does not match, the verification will fail!

// Client side
initBotId({
  protect: [
    {
      path: '/api/checkout',
      method: 'POST',
      advancedOptions: {
        checkLevel: 'deepAnalysis'
      },
    },
 ...
  ],
});

// Server side
export async function POST(request: NextRequest) {
  const verification = await checkBotId({
    advancedOptions: {
      checkLevel: 'deepAnalysis', // Must match client-side config
    },
  });

  if (verification.isBot) {
    return NextResponse.json({ error: 'Access denied' }, { status: 403 });
  }

  // Your protected logic here
}

Conclusion

Stop chasing bots - let BotID handle them for you! Bots are and will get smarter and more sophisticated. BotID gives you a simple way to push back without slowing your customers down. It is simple to install, customize, and use.

Stronger protection equals fewer headaches. Add BotID, ship with confidence, and let the bots trample into a wall without knowing what’s going on.

In our previous blog post about Docusign Extension Apps, Advanced Authentication and Onboarding Workflows with Docusign Extension Apps, we touched on how you can extend the OAuth 2 flow to build a more powerful onboarding flow for your Extension Apps. In this blog post, we will continue explaining more advanced patterns in developing Extension Apps. For that reason, we assume at least basic familiarity with how Extension Apps work and ideally some experience developing them.

To give a brief recap, Docusign Extension Apps are a powerful way to embed custom logic into Docusign agreement workflows. These apps are lightweight services, typically cloud-hosted, that integrate at specific workflow extension points to perform custom actions, such as data validation, participant input collection, or interaction with third-party services. Each Extension App is configured using a manifest file. This manifest defines metadata such as the app's author, support links, and the list of extension points it uses (these are the locations in the workflow where your app's logic will be executed).

The extension points that are relevant for us in the context of this blog post are GetTypeNames and GetTypeDefinitions. These are used by Docusign to retrieve the types supported by the Extension App and their definitions, and to show them in the Maestro UI.

In most apps, these types are static and rarely change. However, they don't have to be. They can also be dynamic and change based on certain configurations in the target system that the Extension App is integrating with, or based on the user role assigned to the Maestro administrator on the target system.

Static vs. Dynamic Types

To explain the difference between static and dynamic types, we'll use the example from our previous blog post, where we integrated with an imaginary task management system called TaskVibe. In the example, our Extension App enabled agreement workflows to communicate with TaskVibe, allowing tasks to be read, created, and updated.

Our first approach to implementing the GetTypeNames and GetTypeDefinitions endpoints for the TaskVibe Extension App might look like the following. The GetTypeNames endpoint returns a single record named task:

{
    "typeNames": [
        {
            "typeName": "task",
            "label": "Task",
            "description": "A task on TaskVibe."
        }
    ]
}

Given the type name task, the GetTypeDefinitions endpoint would return the following definition for that type:

{
    "declarations": [
        {
            // ...
            "name": "task",
            "isAbstract": false,
            "identified": {
                "$class": "concerto.metamodel@1.0.0.IdentifiedBy",
                "name": "recordId"
            },
            "properties": [
                {
                  // ...
                  "name": "recordId"
                },
                {
                  // ...
                  "name": "title"
                },
                // Other task properties
            ]
        }
    ]
}

As noted in the Docusign documentation, this endpoint must return a Concerto schema representing the type. For clarity, we've omitted most of the Concerto-specific properties. The above declaration states that we have a task type, and this type has properties that correspond to task fields in TaskVibe, such as record ID, title, description, assignee, and so on.

The type definition and its properties, as described above, are static and they never change. A TaskVibe task will always have the same properties, and these are essentially set in stone.

Now, imagine a scenario where TaskVibe supports custom properties that are also project-dependent. One project in TaskVibe might follow a typical agile workflow with sprints, and the project manager might want a "Sprint" field in every task within that project. Another project might use a Kanban workflow, where the project manager wants a status field with values like "Backlog," "ToDo," and so on. With static types, we would need to return every possible field from any project as part of the GetTypeDefinitions response, and this introduces new challenges. For example, we might be dealing with hundreds of custom field types, and showing them in the Maestro UI might be too overwhelming for the Maestro administrator. Or we might be returning fields that are simply not usable by the Maestro administrator because they relate to projects the administrator doesn't have access to in TaskVibe.

With dynamic types, however, we can support this level of customization.

Implementing Dynamic Types

When Docusign sends a request to the GetTypeNames endpoint and the types are dynamic, the Extension App has a bit more work than before.

As we've mentioned earlier, we can no longer return a generic task type. Instead, we need to look into each of the TaskVibe projects the user has access to, and return the tasks as they are represented under each project, with all the custom fields. (Determining access can usually be done by making a query to a user information endpoint on the target system using the same OAuth 2 token used for other calls.)

Once we find the task definitions on TaskVibe, we then need to return them in the response of GetTypeNames, where each type corresponds to a task for the given project. This is a big difference from static types, where we would only return a single, generic task.

For example:

{
    "typeNames": [
        {
            "typeName": "task_project1",
            "label": "Task - Project 1",
            "description": "A task on TaskVibe, project 1."
        },
        {
            "typeName": "task_project2",
            "label": "Task - Project 2",
            "description": "A task on TaskVibe, project 2."
        }      
    ]
}

The key point here is that we are now returning one type per task in a TaskVibe project. You can think of this as having a separate class for each type of task, in object-oriented lingo. The type name can be any string you choose, but it needs to be unique in the list, and it needs to contain the minimum information necessary to be able to distinguish it from other task definitions in the list. In our case, we've decided to form the ID by concatenating the string "task_" with the ID of the project on TaskVibe.

The implementation of the GetTypeDefinitions endpoint needs to:

1. Extract the project ID from the requested type name.
2. Using the project ID, retrieve the task definition from TaskVibe for that project. This definition specifies which fields are present on the project's tasks, including all custom fields.
3. Once the fields are retrieved, map them to the properties of the Concerto schema.

The resulting JSON could look like this (again, many of the Concerto properties have been omitted for clarity):

{
    "declarations": [
        {
            // ... 
            "name": "task_project1",
            "isAbstract": false,
            "identified": {
                "$class": "concerto.metamodel@1.0.0.IdentifiedBy",
                "name": "project1_task_recordId"
            },
            "properties": [
                {
                  // ...
                  "name": "project1_task_recordId"
                },
                {
                  // ...
                  "name": "project1_task_title"
                },
                {
                  // ...
                  "name": "project1_task_spring" // This is a custom property on TaskVibe!
                },
                // Other task properties
            ]
        }
    ]
}

Now, type definitions are fully dynamic and project-dependent.

Caching of Type Definitions on Docusign

Docusign maintains a cache of type definitions after an initial connection. This means that changes made to your integration (particularly when using dynamic types) might not be immediately visible in the Maestro UI. To ensure users see the latest data, it's useful to inform them that they may need to refresh their Docusign connection in the App Center UI if new fields are added to their integrated system (like TaskVibe). As an example, a newly added custom field on a TaskVibe project wouldn't be reflected until this refresh occurs.

Conclusion

In this blog post, we've explored how to leverage dynamic types within Docusign Extension Apps to create more flexible integrations with external systems. While static types offer simplicity, they can be constraining when working with external systems that offer a high level of customization. We hope that this blog post provides you with some ideas on how you can tackle similar problems in your Extension Apps.

Example of Lightweight MCP Server Design

At This Dot Labs, we built an MCP server that leverages the DocuSign Navigator API. The tools, like get_agreements, make a request to the DocuSign API to fetch data and then respond in an LLM-friendly way.

   // Get agreements tool that requires authentication
   server.tool(
     'get_agreements',
     'Retrieve DocuSign Navigator agreements. Returns a list of all agreements available in the system with metadata like title, type, status, and parties.',
     {}, // No input parameters needed
     getAgreementsHandler
   );

   // Get agreement by ID tool that requires authentication
   server.tool(
     'get_agreement_by_id',
     'Retrieve detailed information about a specific DocuSign Navigator agreement by its ID. Returns comprehensive details including title, type, status, summary, parties, provisions, metadata, and custom attributes. REQUIRED: agreementId parameter must be provided.',
     { agreementId: z.string().min(1, 'Agreement ID is required') },
     getAgreementByIdHandler
   );

Before the MCP can request anything, it needs to guide the client on how to kick off OAuth. This involves providing some MCP spec metadata API endpoints that include necessary information about where to obtain authorization tokens and what resources it can access. By understanding these details, the client can seamlessly initiate the OAuth process, ensuring secure and efficient data access.

The Oauth flow begins when the user's LLM client makes a request without a valid auth token. In this case they’ll get a 401 response from our server with a WWW-Authenticate header, and then the client will leverage the metadata we exposed to discover the authorization server. Next, the OAuth flow kicks off directly with Docusign as directed by the metadata. Once the client has the token, it passes it in the Authorization header for tool requests to the API.

API Routes
├── Health & Monitoring
│   └── GET /health
│
├── OAuth 2.0 Discovery (.well-known)
│   ├── GET /.well-known/oauth-authorization-server
│   └── GET /.well-known/oauth-protected-resource
│
├── OAuth 2.0 Flow
│   ├── GET/POST /register
│   ├── GET /authorize
│   ├── POST /token
│   └── GET /auth/callback
│
└── MCP (Model Context Protocol)
    └── POST /mcp Main endpoint

This minimal set of API routes enables me to fetch Docusign Navigator data using natural language in my agent chat interface.

Deployment Options

I deployed this MCP server two different ways: as a Fastify backend and then by Vercel functions. Seeing how simple my Fastify MCP server was, and not really having a plan for deployment yet, I was eager to rewrite it for Vercel.

The case for Vercel:

• My own familiarity with Next.js API deployment
• Fit for architecture
• The extremely simple deployment process
• Deploy previews (the eternal Vercel customer conversion feature, IMO)

Previews of unfamiliar territory

Did you know that the MCP spec doesn’t “just work” for use as ChatGPT tooling? Neither did I, and I had to experiment to prove out requirements that I was unfamiliar with. Part of moving fast for me was just deploying Vercel previews right out of the CLI so I could test my API as a Connector in ChatGPT. This was a great workflow for me, and invaluable for the team in code review.

Stuff I’m Not Worried About

Vercel’s mcp-handler package made setup effortless by abstracting away some of the complexity of implementing the MCP server. It gives you a drop-in way to define tools, setup https-streaming, and handle Oauth. By building on Vercel’s ecosystem, I can focus entirely on shipping my product without worrying about deployment, scaling, or server management. Everything just works.

import { createMcpHandler, withMcpAuth } from 'mcp-handler';
import { z } from 'zod';
import {
 authStatusHandler,
 getAgreementsHandler,
 getAgreementByIdHandler,
 searchHandler,
 fetchHandler,
} from '../lib/mcp/handlers/index.js';
import { createTokenVerifier } from '../lib/mcp/auth.js';

// Create the base MCP handler with both authenticated and non-authenticated tools
const handler = createMcpHandler(
 server => {

   // Get agreements tool that requires authentication
   server.tool(
     'get_agreements',
     'Retrieve DocuSign Navigator agreements. Returns a list of all agreements available in the system with metadata like title, type, status, and parties.',
     {}, // No input parameters needed
     getAgreementsHandler
   );
);

// Wrap the handler with authentication - all tools require valid authentication
const authHandler = withMcpAuth(handler, createTokenVerifier(), {
 required: true, // All tools require authentication - this triggers 401 responses
 requiredScopes: ['signature'], // Require at least the signature scope
 resourceMetadataPath: '/.well-known/oauth-protected-resource', // Custom metadata path
});

export { authHandler as GET, authHandler as POST };

A Brief Case for MCP on Next.js

Building an API without Next.js on Vercel is straightforward. Though, I’d be happy deploying this as a Next.js app, with the frontend features serving as the documentation, or the tools being a part of your website's agentic capabilities. Overall, this lowers the barrier to building any MCP you want for yourself, and I think that’s cool.

Conclusion

I'll avoid quoting Vercel documentation in this post. AI tooling is a critical component of this natural language UI, and we just want to ship. I declare Vercel is excellent for stateless MCP servers served over http.

Eventually, this thought led to an interesting conversation on our company's Slack about the impact of AI on our tech stack choices. Some of the views shared there included:

• "The battle between static and dynamic types is over. TypeScript won."
• "The fast-paced development of new frameworks and the excitement around new shiny technologies is slowing down. AI can make existing things work with a workaround in a few minutes, so why create or adopt something new?"
• "AI models are more trained on the most popular stacks, so they will naturally favor those, leading to a self-reinforcing loop."
• "A lot of AI coding assistants serve as marketing funnels for specific stacks, such as v0 being tailored to Next.js and Vercel or Lovable using Supabase and Clerk."

All of these points are valid and interesting, but they also made me think about the bigger picture. So I decided to do some extensive research (read "I decided to make the OpenAI Deep Research tool do it for me") and summarize my findings in this article.

So without further ado, here are some structured thoughts on how AI is reshaping our tech stack choices, and what it means for the future of software development.

1. LLMs as the New Developer Platform

If software development is a journey, LLMs have become the new high-speed train line. Long gone are the days when we used Copilot as a fancy autocomplete tool. Don't get me wrong, it was mind-bogglingly good when it first came out, and I've used it extensively. But now, a few years later, LLMs have evolved into something much more powerful. With the rise of tools like Cursor, Windsurf, Roo Code, or Claude Code, LLMs are essentially becoming the new developer platform. They are no longer just a helper that autocompletes a switch statement or a function signature, but a full-fledged platform that can generate entire applications, write tests, and even refactor code.

And it is not just a few evangelists or early adopters who are using these tools. They have become mainstream, with millions of developers relying on them daily. According to Deloitte, nearly 20% of devs in tech firms were already using generative AI coding tools by 2024, with 76% of StackOverflow respondents using or planning to use AI tools in their development process, according to the 2024 StackOverflow Developer Survey.

They've become an integral part of the development workflow, mediating how code is written, reviewed, and learned. I've argued in the past that LLMs are becoming a new layer of abstraction in software development, but now I believe they are evolving into something even more powerful - a new developer platform that is shaping how we think about and approach software development.

2. The Reinforcement Loop: Popular Stacks Get Smarter

As we travel this AI-guided road, we find that certain routes become highways, while others lead to narrow paths or even dead ends. AI tools are not just helping us write code faster; they are also shaping our preferences for certain tech stacks. The most popular frameworks and languages, such as React.js on the frontend and Node.js on the backend (both with ~40% adoption), are the ones that AI tools perform best with. Their increasing popularity is not just a coincidence; it's a result of a self-reinforcing loop.

AI models are trained on vast amounts of code, and the most popular stacks naturally have more data available for training, given their widespread use, leading to more questions, answers, and examples in the training data. This means that AI tools are inherently better at understanding and generating code for these stacks.

As an anecdotal example, I've noticed that AI tools tend to suggest React.js even when I specify a preference for another framework. As someone working with multiple tech stacks, I can attest that AI tools are significantly more effective with React.js or Node.js than, say, Yii2 or CakePHP.

This phenomenon is not limited to just one or two stacks; it applies to the entire ecosystem. The more a stack is used, the more data there is for AI to learn from, and the better it gets at generating code for that stack, resulting in a feedback loop:

1. AI performs better on popular stacks.
2. Popular stacks get more adoption as developers find them easier to work with.
3. More developers using those stacks means more data for AI to learn from.
4. The cycle continues, reinforcing the popularity of those stacks.

The issue is maybe even more evident with CSS frameworks. TailwindCSS, for example, has gained immense popularity thanks to its utility-first approach, which aligns well with AI's ability to generate and manipulate styles. As more developers adopt TailwindCSS, AI tools become better at understanding its conventions and generating appropriate styles, further driving its adoption.

However, the Tailwind CSS example also highlights a potential pitfall of this reinforcement loop. Tailwind CSS v4 was released in January 2025. From my experience, AI tools still attempt to generate code using v3 concepts and often need to be reminded to use Tailwind CSS v4, requiring spoon-feeding with documentation to get it right. Effectively, this phenomenon can lead to a situation where AI tools not only reinforce the popularity of certain stacks but also potentially slow down the adoption of newer versions or alternatives.

3. Frontend Acceleration: React, Angular, and Beyond

Navigating the frontend landscape has always been tricky, but with AI, some paths feel like smooth expressways while others remain bumpy dirt roads. AI is particularly transformative in frontend development, where the complexity and boilerplate code can be overwhelming. Established frameworks like React and Angular, which are already popular, are seeing even more adoption due to AI's ability to generate components, tests, and optimizations.

React's widespread adoption and its status as the most popular framework on the frontend make it the go-to choice for many developers, especially with AI tools that can quickly scaffold new components or entire applications.

However, Angular's strict structure and type safety also make it a strong contender. Angular's opinionated nature can actually benefit AI-generated code, as it provides a clear framework for the AI to follow, reducing ambiguity and potential bugs.

Call me crazy but I think that long term Angular is going to work better with AI tools for frontend work.

More strict rules to follow, easier to build and scale. Just like for humans.

We just need to keep Angular opinionated enough.

— Daniel Glejzner on X

But it's not just about how the frameworks are structured; it's also the documentation they provide. It has recently become the norm for frameworks to have AI-friendly documentation. Angular, for instance, has a llms.txt file that you can reference in your AI prompts to get more relevant results. The best example, however, in my opinion, is the Nuxt.ui documentation, which provides the option to copy each documentation page as markdown or a link to its markdown version, making it easy to reference in AI prompts.

Frameworks that incorporate AI-friendly documentation and tooling are likely to experience increased adoption, as they facilitate developers' ability to leverage AI's capabilities.

4. Full-Stack TS/JS: The Sweet Spot

On this AI-accelerated journey, some stacks have emerged as the smoothest rides, and full-stack JavaScript/TypeScript is leading the way. The combination of React on the frontend and Node.js on the backend provides a unified language ecosystem, making the road less bumpy for developers. Shared types, common tooling, and mature libraries enable faster prototyping and reduced context switching.

AI seems to enjoy these well-paved highways too. I've observed numerous instances where AI tools default to suggesting Next.js and Tailwind CSS for new projects, even when users are prompted otherwise. While you can force a slight detour to something like Nuxt or SvelteKit, the road suddenly gets patchier - AI becomes less confident, requires more hand-holding, and sometimes outright stalls. So while still technically being in the sweet spot of full-stack JavaScript/TypeScript, deviating from the "main highway" even slightly can lead to a much rougher ride.

React-based full-stack frameworks are becoming mainstream, not necessarily because they are always the best solution, but because they are the path of least resistance for both humans and AI.

5. The Polyglot Shift: AI Enables Multilingual Devs

One fascinating development on this journey is how AI is enabling more developers to become polyglots. Where switching stacks used to feel like taking detours into unknown territory, AI now acts like an on-demand guide. Whether it’s switching from Laravel to Spring Boot or from Angular to Svelte, AI helps bridge those knowledge gaps quickly.

At This Dot, we've always taken pride in our polyglot approach, but AI is lowering the barriers for everyone. Yes, we've done this before the rise of AI tooling. If you are an experienced engineer with a strong understanding of programming concepts, you'll be able to adapt to different stacks and projects quickly. But AI is now enabling even junior developers to become polyglots, and it's making it even easier for the experienced ones to switch between stacks seamlessly. AI doesn’t just shorten the journey - it makes more destinations accessible.

This "AI boost" not only facilitates the job of a software consultant, such as myself, who often has to switch between different projects, but it also opens the door to unlimited possibilities for companies to mix and match stacks based on their needs - particularly useful for companies that have diverse tech stacks, as it allows them to leverage the strengths of different languages and frameworks without the steep learning curve that usually comes with it.

6. AI-Generated Stack Bundles: The Trojan Horse

Trend I'm seeing: AI app generators are a sales funnel.

-Chef uses Convex.

-V0 is optimized for Vercel.

-Lovable uses Supabase and Clerk.

-Firebase Studio uses Google services.

These tools act like a trojan horse - they "sell" a tech stack.

Choose wisely.

— Cory House on X

Some roads come pre-built, but with toll booths you may not notice until you're halfway through the trip. AI-generated apps from tools like v0, Firebase Studio, or Lovable are convenience highways - fast, smooth, and easy to follow - but they quietly nudge you toward specific tech stacks, backend services, databases, and deployment platforms.

It's a smart business model. These tools don't just scaffold your app; they bundle in opinions on hosting, auth providers, and DB layers. The convenience is undeniable, but there's a trade-off in flexibility and long-term maintainability. Engineering leaders must stay alert, like seasoned navigators, ensuring that the allure of speed doesn't lead their teams down the alleyways of vendor lock-in.

7. From 'Buy vs Build' to 'Prompt vs Buy'

The classic dilemma used to be “buy vs build” - now it’s becoming “prompt vs buy.” Why pay for a bloated tour bus of a SaaS product, packed with destinations and detours you’ll never take (and priced accordingly), when you can chart a custom route with a few well-crafted prompts and have a lightweight internal tool up and running in days—or even hours?

Do you need a simple tool to track customer contacts with a few custom fields and a clean interface? In the past, you might have booked a seat on the nearest SaaS solution - one that gets you close enough to your destination but comes with unnecessary stops and baggage. With AI, you can now skip the crowded bus altogether and build a tailor-made vehicle that drives exactly where you need to go, no more, no less.

AI reshapes the travel map of product development. The road to MVPs has become faster, cheaper, and more direct. This shift is already rerouting the internal tooling landscape, steering companies away from bulky, one-size-fits-all platforms toward lean, AI-assembled solutions. And over time, it may change not just how we build, but where we build - with the smoothest highways forming around AI-friendly, modular ecosystems like Node, React, and TypeScript, while older “corporate” expressways like .NET, Java, or even Angular risk becoming the slow scenic routes of enterprise tech.

8. Strategic Implications: Velocity vs Maintainability

Every shortcut comes with trade-offs. The fast lane that AI offers boosts productivity but can sometimes encourage shortcuts in architecture and design. Speeding to your destination is great - until you hit the maintenance toll booth further down the road.

AI tooling makes it easier to throw together an MVP, but without experienced oversight, the resulting codebases can turn into spaghetti highways. Teams need to implement AI-era best practices: structured code reviews, prompt hygiene, and deliberate stack choices that prioritize long-term maintainability over short-term convenience.

Failing to do so can lead to a "quick and dirty" mentality, where the focus is on getting things done fast rather than building robust, maintainable solutions, which is particularly concerning for companies that rely on in-house developers or junior teams who may not have the experience to recognize potential pitfalls in AI-generated code.

9. Closing Reflection: Are We Still Choosing Our Stacks?

So, where are we heading?

Looking at the current "traffic" on the modern software development pathways, one thing becomes clear: AI isn't just a productivity tool - the roads themselves are starting to shape the journey. What was once a deliberate process of choosing the right vehicle for the right terrain - picking our stacks based on product goals, team expertise, and long-term maintainability - now feels more like following GPS directions that constantly recalculate to the path of least resistance.

AI is repaving the main routes, widening the lanes for certain tech stacks, and putting up "scenic route" signs for some frameworks while leaving others on neglected backroads. This doesn't mean we've lost control of the steering wheel, but it does mean that the map is changing beneath us in ways that are easy to overlook.

The risk is clear: we may find ourselves taking the smoothest on-ramps without ever asking if they lead to where we actually want to go. Convenience can quietly take priority over appropriateness. Productivity gains in the short term can pave over technical debt potholes that become unavoidable down the road.

But the story isn't entirely one of caution. There's a powerful opportunity here too. With AI as a co-pilot, we can explore more destinations than ever before - venturing into unfamiliar tech stacks, accelerating MVP development, or rapidly prototyping ideas that previously seemed out of reach. The key is to remain intentional about when to cruise with AI autopilot and when to take the wheel with both hands and steer purposefully.

In this new era of AI-shaped development, the question every engineering team should be asking is not just "how fast can we go?" but "are we on the right road?" and "who's really choosing our route?"

And let’s not forget — some of these roads are still being built. Open-source maintainers and framework authors play a pivotal role in shaping which paths become highways. By designing AI-friendly architectures, providing structured, machine-readable documentation, and baking in patterns that are easy for AI models to learn and suggest, they can guide where AI directs traffic. Frameworks that proactively optimize for AI tooling aren’t just improving developer experience — they’re shaping the very flow of adoption in this AI-accelerated landscape.

If we're not mindful, we risk becoming passengers on a journey defined by default choices. However, if we remain vigilant, we can utilize AI to create more accurate maps, not just follow the fastest roads, but also chart new ones. Because while the routes may be getting redrawn, the destination should always be ours to choose.

In the end, the real competitive advantage will belong to those who can harness AI's speed while keeping their hands firmly on the wheel - navigating not by ease, but by purpose. In this new era, the most valuable skill may not be prompt engineering - it might be strategic discernment.

What is Temporaal?

Temporal is a proposal currently at stage 3 of the TC39 process. It's expected to revolutionize how we handle dates in JavaScript, which has always been a challenging aspect of the language.

But what does it mean that it's at stage 3 of the process?

• The specification is complete
• It has been reviewed
• It's unlikely to change significantly at this point

Key Features of Temporal

Temporal introduces a new global object with a fresh API. Here are some important things to know about Temporal:

1. All Temporal objects are immutable
2. They're represented in local calendar systems, but can be converted
3. Time values use 24-hour clocks
4. Leap seconds aren't represented

Why Do We Need Temporal?

The current Date object in JavaScript has several limitations:

• No support for time zones other than the user's local time and UTC
• Date objects can be mutated
• Unpredictable behavior
• No support for calendars other than Gregorian
• Daylight savings time issues

While some of these have workarounds, not all can be fixed with the current Date implementation.

Let's see some useful examples where Temporal will improve our lives:

Some Examples

Creating a day without a time zone is impossible using Date, it also adds time beyond the date. Temporal introduces PlainDate to overcome this.

let usingDate = new Date('2025-04-03');
// 2025-04-03T00:00:00.000Z

console.log(usingDate);
// Wed Apr 02 2025 21:00:00 GMT-0300 (Chile Summer Time)

let usingTemporal = Temporal.PlainDate.from('2025-04-03');
// PlainDate [Temporal.PlainDate] {}
console.log(usingTemporal.toString());
// 2025-04-03

But what if we want to add timezone information? Then we have ZonedDateTime for this purpose. The timezone must be added in this case, as it also allows a lot of flexibility when creating dates.

let zoned = Temporal.ZonedDateTime.from('2025-04-03T00:00Z[UTC]');
console.log(zoned.toString());

Temporal is very useful when manipulating and displaying the dates in different time zones.

let utc = Temporal.ZonedDateTime.from('2025-04-03T00:00Z[UTC]'); // Created as UTC
console.log(utc.toString());
//2025-04-03T00:00:00+00:00[UTC]

let clientZoned = zoned.withTimeZone(Temporal.Now.timeZoneId()); // Convert to the client timezone

console.log(clientZoned.toString());
// 2025-04-02T21:00:00-03:00[America/Santiago]

Let's try some more things that are currently difficult or lead to unexpected behavior using the Date object.

Operations like adding days or minutes can lead to inconsistent results. However, Temporal makes these operations easier and consistent.

let date = new Date('2025-03-09');
console.log(date); // 2025-03-09T00:00:00.000Z

// add 100 days
date.setDate(date.getDate + 100));
console.log(date); // 2025-06-17T01:00:00.000Z

const zoned = Temporal.ZonedDateTime.from('2025-03-09[UTC]');
console.log(zoned.toString()); // 2025-03-09T00:00:00+00:00[UTC]
console.log(zoned.add({days:100}).toString()); // 2025-06-17T00:00:00+00:00[UTC]

Another interesting feature of Temporal is the concept of Duration, which is the difference between two time points. We can use these durations, along with dates, for arithmetic operations involving dates and times. Note that Durations are serialized using the ISO 8601 duration format

const duration = Temporal.Duration.from({ hours: 5, minutes: 15 });
console.log(duration.toString());
// PT5H15M

const zoned = Temporal.ZonedDateTime.from('2025-03-09[UTC]');
console.log(zoned.toString()); // 2025-03-09T00:00:00+00:00[UTC]
console.log(zoned.add(duration).toString()); // 2025-03-09T00:05:15+00:00[UTC]

Temporal Objects

We've already seen some of the objects that Temporal exposes. Here's a more comprehensive list.

• Temporal
• Temporal.Duration`
• Temporal.Instant
• Temporal.Now
• Temporal.PlainDate
• Temporal.PlainDateTime
• Temporal.PlainMonthDay
• Temporal.PlainTime
• Temporal.PlainYearMonth
• Temporal.ZonedDateTime

Try Temporal Today

If you want to test Temporal now, there's a polyfill available. You can install it using:

npm install @js-temporal/polyfill

Note that this doesn't install a global Temporal object as expected in the final release, but it provides most of the Temporal implementation for testing purposes.

Conclusion

Working with dates in JavaScript has always been a bit of a mess. Between weird quirks in the Date object, juggling time zones, and trying to do simple things like “add a day,” it’s way too easy to introduce bugs.

Temporal is finally fixing that. It gives us a clear, consistent, and powerful way to work with dates and times.

If you’ve ever struggled with JavaScript dates (and who hasn’t?), Temporal is definitely worth checking out.

Roo Code is an extension for VS Code that provides agentic-style AI code editing functionality. You can configure Roo to use any LLM model and version you want by providing API keys. Once configured, Roo allows you to easily switch between models and provide custom instructions through what Roo calls "modes."

Roo Modes can be thought of as a "personality" that the LLM takes on. When you create a new mode in Roo, you provide it with a description of what personality Roo should take on, what LLM model should be used, and what custom instructions the mode should follow. You can also define workspace-level instructions via a .roo/rules-{modeSlug}/ directory at your project root with markdown files inside. Having different modes allows developers to quickly fine-tune how the Roo Code agent performs its tasks.

Roo ships out-of-the-box with some default modes: Code Mode, Architect Mode, Ask Mode, Debug Mode, and Orchestrator Mode. These can get you far, but I have expanded on this list with a few custom modes I have made for specific scenarios I run into every day as a software engineer.

My Custom Modes

📜 Documenter Mode

I created this mode to help me with generating documentation for legacy codebases my team works with. I use this mode to help produce documentation interactively with me while I read a codebase.

Mode Definition

You are Roo, a highly skilled technical documentation writer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices. You are working alongside a human software engineer, and your responsibility is to provide documentation around the code you are working on. You will be asked to provide documentation in the form of comments, markdown files, or other formats as needed.

Mode-specific Instructions

You will respect the following rules:

• You will not write any code, only markdown files.
• In your documentation, you will provide references to specific files and line numbers of code you are referencing.
• You will not attempt to execute any commands.
• You will not attempt to run the application in the browser.
• You will only look at the code and infer functionality from that.

👥 Pair Programmer Mode

I created a “Pair Programmer” mode to serve as my personal coding partner. It’s designed to work in a more collaborative way with a human software engineer. When I want to explore multiple ideas quickly, I switch to this mode to rapidly iterate on code with Roo. In this setup, I take on the role of the navigator—guiding direction, strategy, and decisions—while Roo handles the “driving” by writing and testing the code we need.

Mode Definition

You are Roo, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices. You are working alongside a human software engineer who will be checking your work and providing instructions. If you get stuck, ask for help and we will solve problems together.

Mode-specific Instructions

You will respect the following rules:

• You will not install new 3rd party libraries without first providing usage metrics (stars, downloads, latest version update date).
• You will not do any additional tasks outside of what you have been told to do.
• You will not assume to do any additional work outside of what you have been instructed to do.
• You will not open the browser and test the application. Your pairing partner will do that for you.
• You will not attempt to open the application or the URL at which the application is running. Assume your pairing partner will do that for you.
• You will not attempt to run npm run dev or similar commands. Your pairing partner will do that for you.
• You will not attempt to run a development server of any kind. Your pairing partner will handle that for you.
• You will not write tests unless instructed to.
• You will not make any git commits unless explicitly told to do so.
• You will not make suggestions of commands to run the software or execute the test suite. Assume that your human counterpart has the application running and will check your work.

🧑‍🏫 Project Manager

I created this mode to help me write tasks for my team with clear and actionable acceptance criteria.

Mode Definition

You are a professional project manager. You are highly skilled in breaking down large tasks into bite-sized pieces that are actionable by an engineering team or an LLM performing engineering tasks. You analyze features carefully and detail out all edge cases and scenarios so that no detail is missed.

Mode-specific Instructions

Think creatively about how to detail out features. Provide a technical and business case explanation about feature value. Break down features and functionality in the following way. The following example would be for user login:

User Login: As a user, I can log in to the application so that I can make changes. This prevents anonymous individuals from accessing the admin panel.

Acceptance Criteria

• On the login page, I can fill in my email address:
  • This field is required.
  • This field must enforce email format validation.
• On the login page, I can fill in my password:
  • This field is required.
  • The input a user types into this field is hidden.
• On failure to log in, I am provided an error dialog:
  • The error dialog should be the same if the email exists or not so that bad actors cannot glean info about active user accounts in our system.
  • Error dialog should be a red box pinned to the top of the page.
  • Error dialog can be dismissed.
• After 4 failed login attempts, the form becomes locked:
  • Display a dialog to the user letting them know they can try again in 30 minutes.
  • Form stays locked for 30 minutes and the frontend will not accept further submissions.

🦾 Agent Consultant

I created this mode for assistance with modifying my existing Roo modes and rules files as well as generating higher quality prompts for me. This mode leverages the Context7 MCP to keep up-to-date with documentation on Roo Code and prompt engineering best practices.

Mode Definition

You are an AI Agent coding expert. You are proficient in coding with agents and defining custom rules and guidelines for AI powered coding agents. Your specific expertise is in the Roo Code tool for VS Code are you are exceptionally capable at creating custom rules files and custom mode.

This is your workflow that you should always follow:

1. 1. Begin every task by retrieving relevant documentation from context7
   2. First retrieve Roo documentation using get-library-docs with "/roovetgit/roo-code-docs"
   3. Then retrieve prompt engineering best practices using get-library-docs with “/dair-ai/prompt-engineering-guide"
2. Reference this documentation explicitly in your analysis and recommendations
3. Only after consulting these resources, proceed with the task

Wrapping It Up

Roo’s “Modes” have become an essential part of how I leverage AI in my day-to-day work as a software engineer. By tailoring each mode to specific tasks—whether it’s generating documentation, pairing on code, writing project specs, or improving prompt quality—I’ve been able to streamline my workflow and get more done with greater clarity and precision.

Roo’s flexibility lets me define how it should behave in different contexts, giving me fine-grained control over how I interact with AI in my coding environment. Roo also has the capability of defining custom modes per project if that is needed by your team. If you find yourself repeating certain workflows or needing more structure in your interactions with AI tools, I highly recommend experimenting with your own custom modes. The payoff in productivity and developer experience is absolutely worth it.

If you encounter errors like these, you may be experiencing Connection Storming:

• MongoServerSelectionError: connect ECONNREFUSED <IP_ADDRESS>:<PORT>
• MongoNetworkError: failed to connect to server [<hostname>:<port>] on first connect
• MongoTimeoutError: Server selection timed out after <x> ms
• MongoTopologyClosedError: Topology is closed, please connect
• Mongo Atlas: Connections % of configured limit has gone above 80

Connection storming occurs when your application has to mount a connection to Mongo for every serverless function or API endpoint call. Vercel executes your application’s code in a highly concurrent and isolated fashion. So, if you create new database connections on each request, your app might quickly exceed the connection limit of your database.

We can leverage Vercel’s fluid compute model to keep our database connection objects warm across function invocations. Traditional serverless architecture was designed for quick, stateless web app transactions. Now, especially with the rise of LLM-oriented applications built with Next.js, interactions with applications are becoming more sequential. We just need to ensure that we assign our MongoDB connection to a global variable.

Protip: Use global variables

Vercel’s fluid compute model means all memory, including global constants like a MongoDB client, stays initialized between requests as long as the instance remains active. By assigning your MongoDB client to a global constant, you avoid redundant setup work and reduce the overhead of cold starts. This enables a more efficient approach to reusing connections for your application’s MongoDB client.

The example below demonstrates how to retrieve an array of users from the users collection in MongoDB and either return them through an API request to /api/users or render them as an HTML list at the /users route. To support this, we initialize a global clientPromise variable that maintains the MongoDB connection across warm serverless executions, avoiding re-initialization on every request.

// lib/mongodb.ts
import { MongoClient, Db } from 'mongodb';

if (!process.env.MONGODB_URI) {
  throw new Error('Invalid/Missing environment variable: "MONGODB_URI"');
}

const clientPromise: Promise<MongoClient> = (async () => {
  const client = new MongoClient(process.env.MONGODB_URI!);
  const connectedClient = await client.connect();
  console.log('✅ MongoDB connection established');
  return connectedClient;
})();

export async function getDatabase(): Promise<Db> {
  const client = await clientPromise;
  return client.db('testing_db');
}

Using this database connection in your API route code is easy:

// src/app/api/users/route.ts
import { NextResponse } from 'next/server';
import { getDatabase } from '@/lib/mongodb';

export async function GET() {
  const db = await getDatabase();
  const collection = db.collection('users');
  const users = await collection.find({}).toArray();
  return NextResponse.json({ users });
}

You can also use this database connection in your server-side rendered React components.

// src/app/users/page.tsx
import { getDatabase } from '@/lib/mongodb'

export default async function UserList() {
  const db = await getDatabase()
  const collection = db.collection('users')
  const users = await collection.find({}).toArray()

  return (
    <div>
      <h1>Users List</h1>
      <ul>
        {users.map((user) => (
          <li key={user._id.toString()}>{user.name}</li>
        ))}
      </ul>
    </div>
  )
}

In serverless environments like Vercel, managing database connections efficiently is key to avoiding connection storming. By reusing global variables and understanding the serverless execution model, you can ensure your Next.js app remains stable and performant.

Docusign Extension Apps are a relatively new feature on the Docusign platform. They act as little apps or plugins that allow building custom steps in Docusign agreement workflows, extending them with custom functionality. Docusign agreement workflows have many built-in steps that you can utilize. With Extension Apps, you can create additional custom steps, enabling you to execute custom logic at any point in the agreement process, from collecting participant information to signing documents.

An Extension App is a small service, often running in the cloud, described by the Extension App manifest. The manifest file provides information about the app, including the app's author and support pages, as well as descriptions of extension points used by the app or places where the app can be integrated within an agreement workflow.

Most often, these extension points need to interact with an external system to read or write data, which cannot be done anonymously, as all data going through Extension Apps is usually sensitive. Docusign allows authenticating to external systems using the OAuth 2 protocol, and the specifics about the OAuth 2 configuration are also placed in the manifest file. Currently, only OAuth 2 is supported as the authentication scheme for Extension Apps.

OAuth 2 is a robust and secure protocol, but not all systems support it. Some systems use alternative authentication schemes, such as the PKCE variant of OAuth 2, or employ different authentication methods (e.g., using secret API keys). In such cases, we need to use a slightly different approach to integrate these systems with Docusign.

In this blog post, we'll show you how to do that securely. We will not go too deep into the implementation details of Extension Apps, and we assume a basic familiarity with how they work. Instead, we'll focus on the OAuth 2 part of Extension Apps and how we can extend it.

Extending the OAuth 2 Flow in Extension Apps

For this blog post, we'll integrate with an imaginary task management system called TaskVibe, which offers a REST API to which we authenticate using a secret API key. We aim to develop an extension app that enables Docusign agreement workflows to communicate with TaskVibe, allowing tasks to be read, created, and updated.

TaskVibe does not support OAuth 2. We need to ensure that, once the TaskVibe Extension App is connected, the user is prompted to enter their secret API key. We then need to store this API key securely so it can be used for interacting with the TaskVibe API. Of course, the API key can always be stored in the database of the Extension App. Sill, then, the Extension App has a significant responsibility for storing the API key securely. Docusign already has the capability to store secure tokens on its side and can utilize that instead. After all, most Extension Apps are meant to be stateless proxies to external systems.

Updating the Manifest

To extend OAuth 2, we will need to hook into the OAuth 2 flow by injecting our backend's endpoints into the authorization URL and token URL parts of the manifest. In any other external system that supports OAuth 2, we would be using their OAuth 2 endpoints. In our case, however, we must use our backend endpoints so we can emulate OAuth 2 to Docusign.

"connections": [
    {
        "name": "authentication",
        "description": "Secure connection to TaskVibe",
        "type": "oauth2",
        "params": {
            "provider": "CUSTOM",
            "clientId": "my-client-id",
            "clientSecret": "my-secret",
            "scopes": [],
            "grantType": "authorization_code",
            "customConfig": {
                "authorizationMethod": "body",
                "authorizationParams": {
                    "prompt": "consent",
                    "audience": "api.taskvibe.example.com",
                    "client_id": "my-client-id",
                    "response_type": "code"
                },
                "authorizationUrl": "https://your-backend/authorize",
                "requiredScopes": [],
                "scopeSeparator": " ",
                "tokenUrl": "https://your-backend/api/token",
                "refreshScopes": []
            }
        }
    }
]

The complete flow will look as follows:

In the diagram, we have four actors: the end-user on behalf of whom we are authenticating to TaskVibe, DocuSign, the Extension App, and TaskVibe. We are only in control of the Extension App, and within the Extension App, we need to adhere to the OAuth 2 protocol as expected by Docusign.

1. In the first step, Docusign will invoke the /authorize endpoint of the Extension App and provide the state, client_id, and redirect_uri parameters. Of these three parameters, state and redirect_uri are essential.
2. In the /authorize endpoint, the app needs to store state and redirect_uri, as they will be used in the next step. It then needs to display a user-facing form where the user is expected to enter their TaskVibe API key.
3. Once the user submits the form, we take the API key and encode it in a JWT token, as we will send it over the wire back to Docusign in the form of the code query parameter. This is the "custom" part of our implementation. In a typical OAuth 2 flow, the code is generated by the OAuth 2 server, and the client can then use it to request the access token. In our case, we'll utilize the code to pass the API key to Docusign so it can send it back to us in the next step. Since we are still in control of the user session, we redirect the user to the redirect URI provided by Docusign, along with the code and the state as query parameters.
4. The redirect URI on Docusign will display a temporary page to the user, and in the background, attempt to retrieve the access token from our backend by providing the code and state to the /api/token endpoint.
5. The /api/token endpoint takes the code parameter and decodes it to extract the TaskVibe API secret key. It can then verify if the API key is even valid by making a dummy call to TaskVibe using the API key. If the key is valid, we encode it in a new JWT token and return it as the access token to Docusign.
6. Docusign stores the access token securely on its side and uses it when invoking any of the remaining extension points on the Extension App.

By following the above step, we ensure that the API key is stored in an encoded format on Docusign, and the Extension App effectively extends the OAuth 2 flow. The app is still stateless and does not have the responsibility of storing any secure information locally. It acts as a pure proxy between Docusign and TaskVibe, as it's meant to be.

Writing the Backend

Most Extension Apps are backend-only, but ours needs to have a frontend component for collecting the secret API key. A good fit for such an app is Next.js, which allows us to easily set up both the frontend and the backend.

We'll start by implementing the form for entering the secret API key. This form takes the state, client ID, and redirect URI from the enclosing page, which takes these parameters from the URL.

The form is relatively simple, with only an input field for the API key. However, it can also be used for any additional onboarding questions. If you will ever need to store additional information on Docusign that you want to use implicitly in your Extension App workflow steps, this is a good place to store it alongside the API secret key on Docusign.

// components/auth-form.tsx
"use client";

import type React from "react";
import { useState } from "react";
import { authorizeUser } from "@/lib/actions";

interface AuthFormProps {
  state: string;
  clientId: string;
  redirectUri: string;
}

export function AuthForm({ state, clientId, redirectUri }: AuthFormProps) {
  const [apiKey, setApiKey] = useState("");
  const [isSubmitting, setSubmitting] = useState(false);

  const handleSubmit = async (e: React.FormEvent) => {
    e.preventDefault();
    setSubmitting(true);

    try {
      await authorizeUser(apiKey, state, redirectUri);
    } catch (error) {
      console.error("Authorization failed:", error);
      setSubmitting(false);
    }
  };

  return (
    <div className="card max-w-md w-full">
      <div className="card-header">
        <h2 className="card-title">Connect to TaskVibe</h2>
        <p className="card-description">
          To authenticate with TaskVibe task management tool, please enter your
          API secret key below.
        </p>
      </div>
      <form onSubmit={handleSubmit}>
        <div className="card-content">
          <div className="form-group">
            <label htmlFor="apiKey" className="form-label">
              API Secret Key
            </label>
            <input
              id="apiKey"
              type="password"
              className="form-input"
              placeholder="Enter your TaskVibe API key starting with tv_"
              value={apiKey}
              onChange={(e) => setApiKey(e.target.value)}
              required
              autoComplete="off"
            />
          </div>
          <input type="hidden" name="state" value={state} />
          <input type="hidden" name="redirectUri" value={redirectUri} />
        </div>
        <div className="card-footer">
          <button
            type="submit"
            className="btn btn-primary w-full"
            disabled={isSubmitting}
          >
            {isSubmitting ? "Connecting..." : "Connect"}
          </button>
        </div>
      </form>
    </div>
  );
}

Submitting the form invokes a server action on Next.js, which takes the entered API key, the state, and the redirect URI. It then creates a JWT token using Jose that contains the API key and redirects the user to the redirect URI, sending the JWT token in the code query parameter, along with the state query parameter. This JWT token can be short-lived, as it's only meant to be a temporary holder of the API key while the authentication flow is running.

This is the server action:

// lib/actions.ts
"use server";

import { redirect } from "next/navigation";
import { signJwt } from "./jwt";

export async function authorizeUser(
  apiKey: string,
  state: string,
  redirectUri: string,
) {
  // Create a JWT with 1 hour expiration
  // This is only for the initial authorization code flow, which should be short-lived
  const code = await signJwt({ apiKey }, { expiresIn: "1h" });

  // Construct the redirect URL with state and code
  const redirectUrl = new URL(redirectUri);
  redirectUrl.searchParams.append("state", state);
  redirectUrl.searchParams.append("code", code);

  // Redirect to the callback URL on Docusign
  // Docusign will then invoke the token endpoint with the code to obtain the access token
  redirect(redirectUrl.toString());
}

After the user is redirected to Docusign, Docusign will then invoke the /api/token endpoint to obtain the access token. This endpoint will also be invoked occasionally after the authentication flow, before any extension endpoint is invoked, to get the latest access token using a refresh token. Therefore, the endpoint needs to cover two scenarios.

In the first scenario, during the authentication phase, Docusign will send the code and state to the /api/token endpoint. In this scenario, the endpoint must retrieve the value of the code parameter (storing the JWT value), parse the JWT, and extract the API key. Optionally, it can verify the API key's validity by invoking an endpoint on TaskVibe using that key.

Then, it should return an access token and a refresh token back to Docusign. Since we are not using refresh tokens in our case, we can create a new JWT token containing the API key and return it as both the access token and the refresh token to Docusign.

In the second scenario, Docusign will send the most recently obtained refresh token to get a new access token. Again, because we are not using refresh tokens, we can return both the retrieved access token and the refresh token to Docusign.

The api/token endpoint is implemented as a Next.js route handler:

// src/app/api/token/route.ts

export async function POST(request: NextRequest) {
  try {
    const body = await request.text();
    const parsedBody = parseQueryString(body);
    const { code, refresh_token } = parsedBody;

    if (code) {
      // This is the initial authorization code flow
      // Verify and decode the JWT from the authorization code
      const payload = await verifyJwt<{ apiKey: string }>(code);
      const { apiKey } = payload;

      // Verify the API key with TaskVibe
      const isValid = await verifyApiKey(apiKey);

      if (!isValid) {
        return NextResponse.json({ error: "Invalid API key" }, { status: 401 });
      }

      // Create a new JWT with no expiration
      const accessToken = await signJwt({ apiKey });

      // Return the tokens
      // We are not using a refresh token in this implementation, so we are returning the same token for both access and refresh
      return NextResponse.json({
        access_token: accessToken,
        refresh_token: accessToken,
        token_type: "Bearer",
      });
    } else if (refresh_token) {
      // This is the flow that happens for every subsequent request
      // The refresh token is the same as the access token we created in the initial authorization code flow
      return NextResponse.json({
        access_token: refresh_token,
        refresh_token: refresh_token,
        token_type: "Bearer",
      });
    }

    return NextResponse.json(
      { error: "Missing required parameters" },
      { status: 400 },
    );
  } catch (error) {
    console.error("Token exchange error:", error);
    return NextResponse.json(
      { error: "Invalid or expired token" },
      { status: 401 },
    );
  }
}

In all the remaining endpoints defined in the manifest file, Docusign will provide the access token as the bearer token. It's up to each endpoint to then read this value, parse the JWT, and extract the secret API key.

Conclusion

In conclusion, your Extension App does not need to be limited by the fact that the external system you are integrating with does not have OAuth 2 support or requires additional onboarding. We can safely build upon the existing OAuth 2 protocol and add custom functionality on top of it. This is also a drawback of the approach - it involves custom development, which requires additional work on our part to ensure all cases are covered. Fortunately, the scope of the Extension App does not extend significantly. All remaining endpoints are implemented in the same manner as any other OAuth 2 system, and the app remains a stateless proxy between Docusign and the external system as all necessary information, such as the secret API key and other onboarding details, is stored as an encoded token on the Docusign side.

We hope this blog post was helpful. Keep an eye out for more Docusign content soon, and if you need help building an Extension App of your own, feel free to reach out. The complete source code for this project is available on StackBlitz.

If you come from a JavaScript background, you'll likely be familiar with some of its famous quirks, such as 1 + "1" equaling "11". Well, PHP has its own set of quirks and gotchas, too. Some are oddly similar to JavaScript's, while others can surprise a JavaScript developer.

Let's start with the more familiar ones.

1. Type Juggling and Loose Comparisons

Like JavaScript, PHP has two types of comparison operators: strict and loose. The loose comparison operator in PHP uses ==, while the strict comparison operator uses ===.

Here's an example of a loose vs. strict comparison in PHP:

var_dump(1 == "1"); // true
var_dump(1 === "1"); // false

PHP is a loosely typed language, meaning it will automatically convert variables from one type to another when necessary, just like JavaScript. This is not only when doing comparisons but also, for example, when doing numeric operations. Such conversions can lead to some unexpected results if you're not careful:

var_dump(1 + "1"); // int(2)
var_dump(1 + "1.5"); // float(2.5)
var_dump(1 + "foo"); // int(1) in PHP 7, TypeError in PHP 8

As you can see, the type system has gotten a bit stricter in PHP 8, so it won't let you commit some of the "atrocities" that were possible in earlier versions, throwing a TypeError instead. PHP 8 introduced many changes that aim to eliminate some of the unpredictable behavior; we will cover some of them throughout this article.

1.1. Truthiness of Strings

This is such a common gotcha in PHP that it deserves its own heading. By default, PHP considers an empty string as false and a non-empty string as true:

if ("0") {
    // This block executes because "0" is a non-empty string
    echo "This is considered TRUE in PHP";
}

But wait, there's more! PHP also considers the string "0" as false:

if ("0" == false) {
    // This block executes because "0" is considered FALSE in PHP
    echo "This is considered FALSE in PHP";
}

You might think we're done here, but no! Try comparing a string such as "php" to 0:

if ("php" == 0) {
    // This block executes in PHP 7
    echo "This is considered TRUE in PHP 7";
}

Until PHP7, any non-numeric string was converted to 0 when cast to an integer to compare it to the other integer. That's why this example will be evaluated as true. This quirk has been fixed in PHP 8.

For a comprehensive comparison table of PHP's truthiness, check out the PHP documentation.

1.2. Switch Statements

Switch statements in PHP use loose comparisons, so don't be surprised if you see some unexpected behavior when using them:

$value = "foo";
switch ($value) {
    case 0:
        echo "Value was 0"; // This block executes
        break;
    case "foo":
        echo "Value was foo";
        break;
}

The New Match Expression in PHP 8

PHP 8 introduced the match expression, which is similar to switch but uses strict comparisons (i.e., === under the hood) and returns a value:

$result = match ($value) {
    0 => 'Value is zero',
    1 => 'Value is one',
    default => 'Something else',
};

Unlike switch, there is no "fall-through" behavior in match, and each branch must return a value, making match a great alternative when you need a more precise or concise form of branching—especially if you want to avoid the loose comparisons of a traditional switch.

1.3 String to Number Conversion

In earlier versions of PHP, string-to-number conversions were often done silently, even if the string wasn’t strictly numeric (like '123abc'). In PHP 7, this would typically result in 123 plus a Notice:

// In PHP 7:
var_dump("123abc" + 0);
// int(123), with a Notice

In PHP 8, you’ll still get int(123), but now with a Warning, and in other scenarios (like extremely malformed strings), you might see a TypeError. This stricter behavior can reveal hidden bugs in code that relied on implicit type juggling.

Stricter Type Checks & Warnings in PHP 8

• Performing arithmetic on non-numeric strings:

  As noted, in older versions, something like "123abc" + 0 would silently drop the non-numeric part, often producing 123 plus a PHP Notice. In PHP 8, such operations throw a more visible Warning or TypeError, depending on the exact scenario.

• Null to Non-Nullable Internal Arguments:

  Passing null to a function parameter that’s internally declared as non-nullable will trigger a TypeError in PHP 8. Previously, this might have been silently accepted or triggered only a warning.

• Internal Function Parameter Names:

  PHP 8 introduced named arguments but also made internal parameter names part of the public API. If you use named arguments with built-in functions, be aware that renaming or reordering parameters in future releases might break your code. Always match official parameter names as documented in the PHP manual.

Union Types & Mixed

Since PHP 8.0, we can declare union types, which allows you to specify that a parameter or return value can be one of multiple types. For example:

function getUser(int|string $id) {
// ...
}

Specifying the union of types your function accepts can help clarify your code’s intent and reveal incompatibilities if your existing code relies on looser type checking, preventing some of the conversion quirks we’ve discussed.

2. Operator Precedence and Associativity

Operator precedence can lead to confusing situations if you’re not careful with parentheses. For instance, the . operator (string concatenation similar to + in JavaScript) has left-to-right associativity, but certain logical operators have lower precedence than assignment or concatenation, leading to puzzling results in PHP 7 and earlier:

echo "Sum: " . 1 + 2;
// Actually interpreted as ((echo "Sum: ") . 1) + 2
// Outputs `2` and a Warning: A non-numeric value encountered

echo "Sum: " . (1 + 2);
// Correctly prints "Sum: 3"

PHP 8 has fixed this issue by making the + and - operators take a higher precedence.

3. Variable Variables and Variable Functions

Now, we're getting into unfamiliar territory as JavaScript Developers. PHP allows you to define variable variables and variable functions. This can be a powerful feature, but it can also lead to some confusing code:

$varName = 'hello';
$$varName = 'world';

echo $hello; // Outputs 'world'

In this example, the variable $varName contains the string 'hello'. By using $$varName, we're creating a new variable with the name 'hello' and assigning it the value 'world'.

Similarly, you can create variable functions:

function greet() {
    echo "Hello!";
}

$func = 'greet';
$func(); // Calls greet()

4. Passing Variables by Reference

You can pass variables by reference using the & operator in PHP. This means that any changes made to the variable inside the function will be reflected outside the function:

function increment(&$num) {
    $num++;
}

$number = 5;
increment($number);
echo $number; // Outputs 6

While this example is straightforward, not knowing the pass-by-reference feature can lead to some confusion, and bugs can arise when you inadvertently pass variables by reference.

5. Array Handling

PHP arrays are a bit different from JavaScript arrays. They can be used as both arrays and dictionaries, and they have some quirks that can catch you off guard. For example, if you try to access an element that doesn't exist in an array, PHP will return null instead of throwing an error:

$arr = [1, 2, 3];
var_dump($arr[3]); // NULL

Furthermore, PHP arrays can contain both numerical and string keys at the same time, but numeric string keys can sometimes convert to integers, depending on the context>

$array = [
    "1"   => "One (as string)",
    1     => "One (as int)",
    true  => "True as key?"
];

var_dump($array);
// Output can be surprising:
// array(1) {
//   [1] => string(12) "True as key?"
// }

In this example:

• "1" (string) and 1 (integer) collide, resulting in the array effectively having only one key: 1.
• true is also cast to 1 as an integer, so it overwrites the same key.

And last, but not least, let's go back to the topic of passing variables by reference. You can assign an array element by reference, which can feel quite unintuitive:

$array = ['apple', 'banana'];
$fruit = &$array[0];  // $fruit is now referencing the first element
$fruit = 'pear';

var_dump($array);
// array(2) {
//   [0] => "pear",
//   [1] => "banana"
// }

6 Checking for Variable Truthiness (isset, empty, and nullsafe operator)

In PHP, you can use the empty() function to check if a variable is empty. But what does "empty" mean in PHP? The mental model of what's considered "empty" in PHP might differ from what you're used to in JavaScript. Let's clarify this:

The following values are considered empty by the empty() function:

• "" (an empty string)
• 0 (0 as an integer)
• 0.0 (0 as a float)
• "0" (0 as a string)
• null
• false
• [] (an empty array)

This means that the following values are not considered empty:

• "0" (a string containing "0")
• " " (a string containing a space)
• 0.0 (0 as a float)
• new stdClass() (an empty object)

Keep this in mind when using empty() in your code, otherwise, you might end up debugging some unexpected behavior.

Undefined Variables and isset()

Another little gotcha is that you might expect empty() to return true for undefined variables too - they contain nothing after all, right? Unfortunately, empty() will throw a notice in such case. To account for undefined variables, you may want to use the isset() function, which checks if a variable is set and not null:

$var = 0;
if (isset($var) && !empty($var)) {
    echo "Variable is set and not empty";
}

The Nullsafe Operator

If you have a chain of properties or methods that you want to access, you may tend to check each step with isset() to avoid errors:

if (isset($object) && isset($object->child)) {
    echo $object->child->getName();
}

In fact, because isset() is a special language construct and it doesn't fully evaluate an undefined part of the chain, it can be used to evaluate the whole chain at once:

if (isset($object->child)) {
    $result = $object->child->getName();
}

That's much nicer! However, it could be even more elegant with the nullsafe operator (?->) introduced in PHP 8:

// Instead of checking multiple times if $object or $object->child is null:
$result = $object?->child?->getName();

If you’ve used optional chaining in JavaScript or other languages, this should look familiar. It returns null if any part of the chain is null, which is handy but can also hide potential logic mistakes — if your application logic expects objects to exist, silently returning null may lead to subtle bugs.

Conclusion

While PHP shares a few loose typing quirks with JavaScript, it also has its own distinctive behaviors around type juggling, operator precedence, passing by reference, and array handling. Becoming familiar with these nuances — and with the newer, more predictable features in PHP 8 — will help you avoid subtle bugs and write clearer, more robust code. PHP continues to evolve, so always consult the official documentation to stay current on best practices and language changes.

Autonomous coding agents are no longer experimental, they are becoming an integral part of modern development workflows, redefining how software is built and maintained. As models become more capable, agents have become easier to produce, leading to an explosion of options with varying depth and utility. Drawing insights from our experience using many agents, let's delve into the features that you'll absolutely want to get the best results.

1. Customizable System Prompts

Custom agent modes, or roles, allow engineers to tailor the outputs to the desired results of their task. For instance, an agent can be set to operate in a "planning mode" focused on outlining development steps and gathering requirements, a "coding mode" optimized for generating and testing code, or a "documentation mode" emphasizing clarity and completeness of written artifacts. You might start with the off-the-shelf planning prompt, but you'll quickly want your own tailored version. Regardless of which modes are included out of the box, the ability to customize and extend them is critical. Agents must adapt to your unique workflows and prioritize what's important to your project. Without this flexibility, even well-designed defaults can fall short in real-world use.

Engineers have preferences, and projects contain existing work. The best agents offer ways to communicate these preferences and decisions effectively. For example, 'pnpm' instead of 'npm' for package management, requiring the agent to seek root causes rather than offer temporary workarounds, or mandating that tests and linting must pass before a task is marked complete. Rules are a layer of control to accomplish this. Rules reinforce technical standards but also shape agent behavior to reflect project priorities and cultural norms. They inform the agent across contexts, think constraints, preferences, or directives that apply regardless of the task. Rules can encode things like style guidelines, risk tolerances, or communication boundaries. By shaping how the agent reasons and responds, rules ensure consistent alignment with desired outcomes.

Roo code is an agent that makes great use of custom modes, and rules are ubiquitous across coding agents. These features form a meta-agent framework that allows engineers to construct the most effective agent for their unique project and workflow details.

2. Usage-based Pricing

The best agents provide as much relevant information as possible to the model. They give transparency and control over what information is sent. This allows engineers to leverage their knowledge of the project to improve results. Being liberal with relevant information to the models is more expensive however, it also significantly improves results.

The pricing model of some agents prioritizes fixed, predictable costs that include model fees. This creates an incentive to minimize the amount of information sent to the model in order to control costs. To get the most out of these tools, you’ve got to get the most out of models, which typically implies usage-based pricing.

3. Autonomous Workflows

The way we accomplish work has phases. For example, creating tests and then making them pass, creating diagrams or plans, or reviewing work before submitting PRs. The best agents have mechanisms to facilitate these phases in an autonomous way. For the best results, each phase should have full use of a context window without watering down the main session's context. This should leverage your custom modes, which excel at each phase of your workflow.

4. Working in the Background

The best agents are more effective at producing desired results and thus are able to be more autonomous. As agents become more autonomous, the ability to work in the background or work on multiple tasks at once becomes increasingly necessary to unlock their full potential. Agents that leverage local or cloud containers to perform work independently of IDEs or working copies on an engineer's machine further increase their utility. This allows engineers to focus on drafting plans and reviewing proposed changes, ultimately to work toward managing multiple tasks at once, overseeing their agent-powered workflows as if guiding a team.

5. Integrations with your Tools

The Model Context Protocol (MCP) serves as a standardized interface, allowing agents to interact with your tools and data sources. The best agents seamlessly integrate with the platforms that engineers rely on, such as Confluence for documentation, Jira for tasks, and GitHub for source control and pull requests. These integrations ensure the agent can participate meaningfully across the full software development lifecycle.

6. Support for Multiple Model Providers

Reliance on a single AI provider can be limiting. Top-tier agents support multiple providers, allowing teams to choose the best models for specific tasks. This flexibility enhances performance, the ability to use the latest and greatest, and also safeguards against potential downtimes or vendor-specific issues.

Final Thoughts

Selecting the right autonomous coding agent is a strategic decision. By prioritizing the features mentioned, technology leaders can adopt agents that can be tuned for their team's success. Tuning agents to projects and teams takes time, as does configuring the plumbing to integrate well with other systems. However, unlocking massive productivity gains is worth the squeeze. Models will become better and better, and the best agents capitalize on these improvements with little to no added effort. Set your organization and teams up to tap into the power of AI-enhanced engineering, and be more effective and more competitive.

In this post, we'll break down each strategy, what it's good for, and how it impacts your site's performance, especially Core Web Vitals. We'll also explore hybrid approaches and provide practical guidance on choosing the right strategy for your use case.

What Are Core Web Vitals?

Core Web Vitals are a set of metrics defined by Google that measure real-world user experience on websites. These metrics play a major role in search engine rankings and directly affect how users perceive the speed and smoothness of your site.

• Largest Contentful Paint (LCP): This measures loading performance. It calculates the time taken for the largest visible content element to render. A good LCP is 2.5 seconds or less.
• Interaction to Next Paint (INP): This measures responsiveness to user input. A good INP is 200 milliseconds or less.
• Cumulative Layout Shift (CLS): This measures the visual stability of the page. It quantifies layout instability during load. A good CLS is 0.1 or less.

If you want to dive deeper into Core Web Vitals and understand more about their impact on your website's performance, I recommend reading this detailed guide on New Core Web Vitals and How They Work.

Next.js Rendering Strategies and Core Web Vitals

Let's explore each rendering strategy in detail:

1. Static Rendering (Server Rendering Strategy)

Static Rendering is the default for Server Components in Next.js. With this approach, components are rendered at build time (or during revalidation), and the resulting HTML is reused for each request. This pre-rendering happens on the server, not in the user's browser. Static rendering is ideal for routes where the data is not personalized to the user, and this makes it suitable for:

• Content-focused websites: Blogs, documentation, marketing pages
• E-commerce product listings: When product details don't change frequently
• SEO-critical pages: When search engine visibility is a priority
• High-traffic pages: When you want to minimize server load

How Static Rendering Affects Core Web Vitals

• Largest Contentful Paint (LCP): Static rendering typically leads to excellent LCP scores (typically < 1s). The Pre-rendered HTML can be cached and delivered instantly from CDNs, resulting in very fast delivery of the initial content, including the largest element. Also, there is no waiting for data fetching or rendering on the client.
• Interaction to Next Paint (INP): Static rendering provides a good foundation for INP, but doesn't guarantee optimal performance (typically ranges from 50-150 ms depending on implementation). While Server Components don't require hydration, any Client Components within the page still need JavaScript to become interactive. To achieve a very good INP score, you will need to make sure the Client Components within the page is minimal.
• Cumulative Layout Shift (CLS): While static rendering delivers the complete page structure upfront which can be very beneficial for CLS, achieving excellent CLS requires additional optimization strategies:
  • Static HTML alone doesn't prevent layout shifts if resources load asynchronously
  • Image dimensions must be properly specified to reserve space before the image loads
  • Web fonts can cause text to reflow if not handled properly with font display strategies
  • Dynamically injected content (ads, embeds, lazy-loaded elements) can disrupt layout stability
  • CSS implementation significantly impacts CLS—immediate availability of styling information helps maintain visual stability

Code Examples:

1. Basic static rendering:

// app/page.tsx (Server Component - Static Rendering by default)
export default async function Page() {
  const res = await fetch('https://api.example.com/static-data');
  const data = await res.json();
  return (
    <div>
      <h1>Static Content</h1>
      <p>{data.content}</p>
    </div>
  );
}

2. Static rendering with revalidation (ISR):

// app/dashboard/page.tsx
export default async function Dashboard() {
  // Static data that revalidates every day
  const siteStats = await fetch('https://api.example.com/site-stats', {
    next: { revalidate: 86400 } // 24 hours
  }).then(r => r.json());

  // Data that revalidates every hour
  const popularProducts = await fetch('https://api.example.com/popular-products', {
    next: { revalidate: 3600 } // 1 hour
  }).then(r => r.json());

  // Data with a cache tag for on-demand revalidation
  const featuredContent = await fetch('https://api.example.com/featured-content', {
    next: { tags: ['featured'] }
  }).then(r => r.json());

  return (
    <div className="dashboard">
      <section className="stats">
        <h2>Site Statistics</h2>
        <p>Total Users: {siteStats.totalUsers}</p>
        <p>Total Orders: {siteStats.totalOrders}</p>
      </section>

      <section className="popular">
        <h2>Popular Products</h2>
        <ul>
          {popularProducts.map(product => (
            <li key={product.id}>{product.name} - {product.sales} sold</li>
          ))}
        </ul>
      </section>

      <section className="featured">
        <h2>Featured Content</h2>
        <div>{featuredContent.html}</div>
      </section>
    </div>
  );
}

3. Static path generation:

// app/products/[id]/page.tsx
export async function generateStaticParams() {
  const products = await fetch('https://api.example.com/products').then(r => r.json());

  return products.map((product) => ({
    id: product.id.toString(),
  }));
}

export default async function Product({ params }) {
  const product = await fetch(`https://api.example.com/products/${params.id}`).then(r => r.json());

  return (
    <div>
      <h1>{product.name}</h1>
      <p>${product.price.toFixed(2)}</p>
      <p>{product.description}</p>
    </div>
  );
}

2. Dynamic Rendering (Server Rendering Strategy)

Dynamic Rendering generates HTML on the server for each request at request time. Unlike static rendering, the content is not pre-rendered or cached but freshly generated for each user. This kind of rendering works best for:

• Personalized content: User dashboards, account pages
• Real-time data: Stock prices, live sports scores
• Request-specific information: Pages that use cookies, headers, or search parameters
• Frequently changing data: Content that needs to be up-to-date on every request

How Dynamic Rendering Affects Core Web Vitals

• Largest Contentful Paint (LCP): With dynamic rendering, the server needs to generate HTML for each request, and that can't be fully cached at the CDN level. It is still faster than client-side rendering as HTML is generated on the server.
• Interaction to Next Paint (INP): The performance is similar to static rendering once the page is loaded. However, it can become slower if the dynamic content includes many Client Components.
• Cumulative Layout Shift (CLS): Dynamic rendering can potentially introduce CLS if the data fetched at request time significantly alters the layout of the page compared to a static structure. However, if the layout is stable and the dynamic content size fits within predefined areas, the CLS can be managed effectively.

Code Examples:

1. Explicit dynamic rendering:

// app/dashboard/page.tsx
export const dynamic = 'force-dynamic'; // Force this route to be dynamically rendered

export default async function Dashboard() {
  // This will run on every request
  const data = await fetch('https://api.example.com/dashboard-data').then(r => r.json());

  return (
    <div>
      <h1>Dashboard</h1>
      <p>Last updated: {new Date().toLocaleString()}</p>
      {/* Dashboard content */}
    </div>
  );
}

2. Simplicit dynamic rendering with cookies:

// app/profile/page.tsx
import { cookies } from 'next/headers';

export default async function Profile() {
  // Using cookies() automatically opts into dynamic rendering
  const userId = cookies().get('userId')?.value;

  const user = await fetch(`https://api.example.com/users/${userId}`).then(r => r.json());

  return (
    <div>
      <h1>Welcome, {user.name}</h1>
      <p>Email: {user.email}</p>
      {/* Profile content */}
    </div>
  );
}

3. Dynamic routes:

// app/blog/[slug]/page.tsx
export default async function BlogPost({ params }) {
  // It will run at request time for any slug not explicitly pre-rendered
  const post = await fetch(`https://api.example.com/posts/${params.slug}`).then(r => r.json());

  return (
    <article>
      <h1>{post.title}</h1>
      <div>{post.content}</div>
    </article>
  );
}

3. Streaming (Server Rendering Strategy)

Streaming allows you to progressively render UI from the server. Instead of waiting for all the data to be ready before sending any HTML, the server sends chunks of HTML as they become available. This is implemented using React's Suspense boundary.

React Suspense works by creating boundaries in your component tree that can "suspend" rendering while waiting for asynchronous operations. When a component inside a Suspense boundary throws a promise (which happens automatically with data fetching in React Server Components), React pauses rendering of that component and its children, renders the fallback UI specified in the Suspense component, continues rendering other parts of the page outside this boundary, and eventually resumes and replaces the fallback with the actual component once the promise resolves.

When streaming, this mechanism allows the server to send the initial HTML with fallbacks for suspended components while continuing to process suspended components in the background. The server then streams additional HTML chunks as each suspended component resolves, including instructions for the browser to seamlessly replace fallbacks with final content. It works well for:

• Pages with mixed data requirements: Some fast, some slow data sources
• Improving perceived performance: Show users something quickly while slower parts load
• Complex dashboards: Different widgets have different loading times
• Handling slow APIs: Prevent slow third-party services from blocking the entire page

How Streaming Affects Core Web Vitals

• Largest Contentful Paint (LCP): Streaming can improve the perceived LCP. By sending the initial HTML content quickly, including potentially the largest element, the browser can render it sooner. Even if other parts of the page are still loading, the user sees the main content faster.
• Interaction to Next Paint (INP): Streaming can contribute to a better INP. When used with React's <Suspense />, interactive elements in the faster-loading parts of the page can become interactive earlier, even while other components are still being streamed in. This allows users to engage with the page sooner.
• Cumulative Layout Shift (CLS): Streaming can cause layout shifts as new content streams in. However, when implemented carefully, streaming should not negatively impact CLS. The initially streamed content should establish the main layout, and subsequent streamed chunks should ideally fit within this structure without causing significant reflows or layout shifts. Using placeholders and ensuring dimensions are known can help prevent CLS.

Code Examples:

1. Basic Streaming with Suspense:

// app/dashboard/page.tsx
import { Suspense } from 'react';
import UserProfile from './components/UserProfile';
import RecentActivity from './components/RecentActivity';
import PopularPosts from './components/PopularPosts';

export default function Dashboard() {
  return (
    <div className="dashboard">
      {/* This loads quickly */}
      <h1>Dashboard</h1>

      {/* User profile loads first */}
      <Suspense fallback={<div className="skeleton-profile">Loading profile...</div>}>
        <UserProfile />
      </Suspense>

      {/* Recent activity might take longer */}
      <Suspense fallback={<div className="skeleton-activity">Loading activity...</div>}>
        <RecentActivity />
      </Suspense>

      {/* Popular posts might be the slowest */}
      <Suspense fallback={<div className="skeleton-posts">Loading popular posts...</div>}>
        <PopularPosts />
      </Suspense>
    </div>
  );
}

2. Nested Suspense boundaries for more granular control:

// app/complex-page/page.tsx
import { Suspense } from 'react';

export default function ComplexPage() {
  return (
    <Suspense fallback={<PageSkeleton />}>
      <Header />

      <div className="content-grid">
        <div className="main-content">
          <Suspense fallback={<MainContentSkeleton />}>
            <MainContent />
          </Suspense>
        </div>

        <div className="sidebar">
          <Suspense fallback={<SidebarTopSkeleton />}>
            <SidebarTopSection />
          </Suspense>

          <Suspense fallback={<SidebarBottomSkeleton />}>
            <SidebarBottomSection />
          </Suspense>
        </div>
      </div>

      <Footer />
    </Suspense>
  );
}

3. Using Next.js loading.js convention:

// app/products/loading.tsx - This will automatically be used as a Suspense fallback
export default function Loading() {
  return (
    <div className="products-loading-skeleton">
      <div className="header-skeleton" />
      <div className="filters-skeleton" />
      <div className="products-grid-skeleton">
        {Array.from({ length: 12 }).map((_, i) => (
          <div key={i} className="product-card-skeleton" />
        ))}
      </div>
    </div>
  );
}

// app/products/page.tsx
export default async function ProductsPage() {
  // This component can take time to load
  // Next.js will automatically wrap it in Suspense
  // and use the loading.js as the fallback
  const products = await fetchProducts();

  return <ProductsList products={products} />;
}

4. Client Components and Client-Side Rendering

Client Components are defined using the React 'use client' directive. They are pre-rendered on the server but then hydrated on the client, enabling interactivity. This is different from pure client-side rendering (CSR), where rendering happens entirely in the browser. In the traditional sense of CSR (where the initial HTML is minimal, and all rendering happens in the browser), Next.js has moved away from this as a default approach but it can still be achievable by using dynamic imports and setting ssr: false.

// app/csr-example/page.tsx
'use client';

import { useState, useEffect } from 'react';
import dynamic from 'next/dynamic';

// Lazily load a component with no SSR
const ClientOnlyComponent = dynamic(
  () => import('../components/heavy-component'),
  { ssr: false, loading: () => <p>Loading...</p> }
);

export default function CSRPage() {
  const [isClient, setIsClient] = useState(false);

  useEffect(() => {
    setIsClient(true);
  }, []);

  return (
    <div>
      <h1>Client-Side Rendered Page</h1>
      {isClient ? (
        <ClientOnlyComponent />
      ) : (
        <p>Loading client component...</p>
      )}
    </div>
  );
}

Despite the shift toward server rendering, there are valid use cases for CSR:

1. Private dashboards: Where SEO doesn't matter, and you want to reduce server load
2. Heavy interactive applications: Like data visualization tools or complex editors
3. Browser-only APIs: When you need access to browser-specific features like localStorage or WebGL
4. Third-party integrations: Some third-party widgets or libraries that only work in the browser

While these are valid use cases, using Client Components is generally preferable to pure CSR in Next.js. Client Components give you the best of both worlds: server-rendered HTML for the initial load (improving SEO and LCP) with client-side interactivity after hydration. Pure CSR should be reserved for specific scenarios where server rendering is impossible or counterproductive.

Client components are good for:

• Interactive UI elements: Forms, dropdowns, modals, tabs
• State-dependent UI: Components that change based on client state
• Browser API access: Components that need localStorage, geolocation, etc.
• Event-driven interactions: Click handlers, form submissions, animations
• Real-time updates: Chat interfaces, live notifications

How Client Components Affect Core Web Vitals

• Largest Contentful Paint (LCP): Initial HTML includes the server-rendered version of Client Components, so LCP is reasonably fast. Hydration can delay interactivity but doesn't necessarily affect LCP.
• Interaction to Next Paint (INP): For Client Components, hydration can cause input delay during page load, and when the page is hydrated, performance depends on the efficiency of event handlers. Also, complex state management can impact responsiveness.
• Cumulative Layout Shift (CLS): Client-side data fetching can cause layout shifts as new data arrives. Also, state changes might alter the layout unexpectedly. Using Client Components will require careful implementation to prevent shifts.

Code Examples:

1. Basic Client Component:

// app/components/Counter.tsx
'use client';

import { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}

2. Client Component with server data:

// app/products/page.tsx - Server Component
import ProductFilter from '../components/ProductFilter';

export default async function ProductsPage() {
  // Fetch data on the server
  const products = await fetch('https://api.example.com/products').then(r => r.json());

  // Pass server data to Client Component as props
  return <ProductFilter initialProducts={products} />;
}

Hybrid Approaches and Composition Patterns

In real-world applications, you'll often use a combination of rendering strategies to achieve the best performance. Next.js makes it easy to compose Server and Client Components together.

Server Components with Islands of Interactivity

One of the most effective patterns is to use Server Components for the majority of your UI and add Client Components only where interactivity is needed. This approach:

1. Minimizes JavaScript sent to the client
2. Provides excellent initial load performance
3. Maintains good interactivity where needed

// app/products/[id]/page.tsx - Server Component
import AddToCartButton from '../../components/AddToCartButton';
import ProductReviews from '../../components/ProductReviews';
import RelatedProducts from '../../components/RelatedProducts';

export default async function ProductPage({ params }: {
  params: { id: string; }
}) {
  // Fetch product data on the server
  const product = await fetch(`https://api.example.com/products/${params.id}`).then(r => r.json());

  return (
    <div className="product-page">
      <div className="product-main">
        <h1>{product.name}</h1>
        <p className="price">${product.price.toFixed(2)}</p>
        <div className="description">{product.description}</div>

        {/* Client Component for interactivity */}
        <AddToCartButton product={product} />
      </div>

      {/* Server Component for product reviews */}
      <ProductReviews productId={params.id} />

      {/* Server Component for related products */}
      <RelatedProducts categoryId={product.categoryId} />
    </div>
  );
}

Partial Prerendering (Next.js 15)

Next.js 15 introduced Partial Prerendering, a new hybrid rendering strategy that combines static and dynamic content in a single route. This allows you to:

1. Statically generate a shell of the page
2. Stream in dynamic, personalized content
3. Get the best of both static and dynamic rendering

Note: At the time of this writing, Partial Prerendering is experimental and is not ready for production use. Read more

// app/dashboard/page.tsx
import { unstable_noStore as noStore } from 'next/cache';
import StaticContent from './components/StaticContent';
import DynamicContent from './components/DynamicContent';

export default function Dashboard() {
  return (
    <div className="dashboard">
      {/* This part is statically generated */}
      <StaticContent />

      {/* This part is dynamically rendered */}
      <DynamicPart />
    </div>
  );
}

// This component and its children will be dynamically rendered
function DynamicPart() {
  // Opt out of caching for this part
  noStore();

  return <DynamicContent />;
}

Measuring Core Web Vitals in Next.js

Understanding the impact of your rendering strategy choices requires measuring Core Web Vitals in real-world conditions. Here are some approaches:

1. Vercel Analytics

If you deploy on Vercel, you can use Vercel Analytics to automatically track Core Web Vitals for your production site:

// app/layout.tsx
import { Analytics } from '@vercel/analytics/react';

export default function RootLayout({ children }: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body>
        {children}
        <Analytics />
      </body>
    </html>
  );
}

2. Web Vitals API

You can manually track Core Web Vitals using the web-vitals library:

// app/components/WebVitalsReporter.tsx
'use client';

import { useEffect } from 'react';
import { onCLS, onINP, onLCP } from 'web-vitals';

export function WebVitalsReporter() {
  useEffect(() => {
    // Report Core Web Vitals
    onCLS(metric => console.log('CLS:', metric.value));
    onINP(metric => console.log('INP:', metric.value));
    onLCP(metric => console.log('LCP:', metric.value));

    // In a real app, you would send these to your analytics service
  }, []);

  return null; // This component doesn't render anything
}

3. Lighthouse and PageSpeed Insights

For development and testing, use:

• Chrome DevTools Lighthouse tab
• PageSpeed Insights
• Chrome User Experience Report

Making Practical Decisions: Which Rendering Strategy to Choose?

Choosing the right rendering strategy depends on your specific requirements. Here's a decision framework:

Choose Static Rendering when

• Content is the same for all users
• Data can be determined at build time
• Page doesn't need frequent updates
• SEO is critical
• You want the best possible performance

Choose Dynamic Rendering when

• Content is personalized for each user
• Data must be fresh on every request
• You need access to request-time information
• Content changes frequently

Choose Streaming when

• Page has a mix of fast and slow data requirements
• You want to improve perceived performance
• Some parts of the page depend on slow APIs
• You want to prioritize showing critical UI first

Choose Client Components when

• UI needs to be interactive
• Component relies on browser APIs
• UI changes frequently based on user input
• You need real-time updates

Conclusion

Next.js provides a powerful set of rendering strategies that allow you to optimize for both performance and user experience. By understanding how each strategy affects Core Web Vitals, you can make informed decisions about how to build your application.

Remember that the best approach is often a hybrid one, combining different rendering strategies based on the specific requirements of each part of your application. Start with Server Components as your default, use Static Rendering where possible, and add Client Components only where interactivity is needed.

By following these principles and measuring your Core Web Vitals, you can create Next.js applications that are fast, responsive, and provide an excellent user experience.

In this blog, we will dig into Vercel’s Flags SDK. We'll explore how it works, highlight its key capabilities, and discuss best practices to get the most out of it.

You'll also understand why you might prefer this tool over other feature flag solutions out there. And, despite its strong integration with Next.js, this SDK isn't limited to just one framework—it's fully compatible with React and SvelteKit. We'll use Next.js for examples, but feel free to follow along with the framework of your choice.

Why should I use it?

You might wonder, "Why should I care about yet another feature flag library?" Unlike some other solutions, Vercel's Flags SDK offers unique, practical features. It offers simplicity, flexibility, and smart patterns to help you manage feature flags quickly and efficiently.

It’s simple

Let's start with a basic example:

app
 ↳flags.js

import { flag } from 'flags/next';

export const exampleFlag = flag({
    key: 'example-flag',
    identify() {
        return { user: { id: '123' } };
    },
    decide({ entities }) {
        return entities.user.id === '123';
    },
});

// page.js
const exampleValue = await exampleFlag();

This might look simple — and it is! — but it showcases some important features. Notice how easily we can define and call our flag without repeatedly passing context or configuration.

Many other SDKs require passing the flag's name and context every single time you check a flag, like this:

const exampleValue = await client.getBooleanValue('exampleFlag', context);

This can become tedious and error-prone, as you might accidentally use different contexts throughout your app. With the Flags SDK, you define everything once upfront, keeping things consistent across your entire application.

By "context", I mean the data needed to evaluate the flag, like user details or environment settings. We'll get into more detail shortly.

It’s flexible

Vercel’s Flags SDK is also flexible. You can integrate it with other popular feature flag providers like LaunchDarkly or Statsig using built-in adapters. And if the provider you want to use isn’t supported yet, you can easily create your own custom adapter.

While we'll use Next.js for demonstration, remember that the SDK works just as well with React or SvelteKit.

Latency solutions

Feature flags require definitions and context evaluations to determine their values — imagine checking conditions like, "Is the user ID equal to 12?" Typically, these evaluations involve fetching necessary information from a server, which can introduce latency.

These evaluations happen through two primary functions: identify and decide. The identify function gathers the context needed for evaluation, and this context is then passed as an argument named entities to the decide function. Let's revisit our earlier example to see this clearly:

app
 ↳flags.js

import { flag } from 'flags/next';

export const exampleFlag = flag({
    key: 'example-flag',
    identify() {
        // Identify our evaluation context   
        return { user: { id: '123' } };
    },
    decide({ entities }) {
        // Evaluate or decide our value based on our condition
        return entities.user.id === '123';
    },
});

You could add a custom evaluation context when reading a feature flag, but it’s not the best practice, and it’s not usually recommended.

Using Edge Config

When loading our flags, normally, these definitions and evaluation contexts get bootstrapped by making a network request and then opening a web socket listening to changes on the server. The problem is that if you do this in Serverless Functions with a short lifespan, you would need to bootstrap the definitions not just once but multiple times, which could cause latency issues.

To handle latency efficiently, especially in short-lived Serverless Functions, you can use Edge Config. Edge Config stores flag definitions at the Edge, allowing super-fast retrieval via Edge Middleware or Serverless Functions, significantly reducing latency.

Cookies

For more complex contexts requiring network requests, avoid doing these requests directly in Edge Middleware or CDNs, as this can drastically increase latency. Edge Middleware and CDNs are fast because they avoid making network requests to the origin server. Depending on the end user’s location, accessing a distant origin can introduce significant latency. For example, a user in Tokyo might need to connect to a server in the US before the page can load.

Instead, a good pattern that the Flags SDK offers us to avoid this is cookies. You could use cookies to store context data. The browser automatically sends cookies with each request in a standard format, providing consistent (no matter if you are in Edge Middleware, App Router or Page Router), low-latency access to evaluation context data:

export const exampleFlag = flag({
    // Definition
    key: 'example-flag',
    // Context
    identify({ cookies }) {
        // We get the cookie that we need for our context
        const userId = cookies.get('user-id')?.value;
        return { user: userId ? { id: userId } : undefined };
    },
    // Evaluation
    decide({ entities }) {
        return entities?.user?.id === 12;
    },
});

You can also encrypt or sign cookies for additional security from the client side.

Dedupe

Dedupe helps you cache function results to prevent redundant evaluations. If multiple flags rely on a common context method, like checking a user's region, Dedupe ensures the method executes only once per runtime, regardless of how many times it's invoked. Additionally, similar to cookies, the Flags SDK standardizes headers, allowing easy access to them. Let's illustrate this with the following example:

app
 ↳flags.js

 import { dedupe, flag } from "flags/next";

// Simulate a fake fetch function
async function fakeFetch(url, options) {
    return new Response(JSON.stringify({ region: 'EU' }), { status: 200 });
}

// Simulated function to get the user's region from the request headers.
async function getUserRegion(headers) {
    // In a real-world scenario, this might involve calling an external geolocation API.
    // So we'll use a fake API to simulate the response.
    const response = await fakeFetch('https://api.example.com/get-region', {
        method: 'GET',
        headers: { 'x-country': headers.get('x-country') || '' }
    });
    const data = await response.json();
    return data;
}

// Wrap the region retrieval function using dedupe so that it runs only once per request.
const identifyRegion = dedupe(
    async ({ headers }) => {
        return await getUserRegion(headers);
    },
);

// Define the feature flag that decides the promotional discount eligibility based on the user's region.
export const promoDiscountFlag = flag({
    key: 'promo-discount-flag',
    // Use the deduped identify function for evaluation context.
    identify: identifyRegion,
    decide({ entities }) {
        // If the region isn’t determined, disable the flag.
        if (!entities?.region) return false;
        // Only enable the promotion for users in either 'EU' or 'NA'.
        return ['EU', 'NA'].includes(entities.region);
    },
});

app
 ↳plans
   ↳page.jsx

import { promoDiscountFlag } from '../flags';

export default async function PlansPage() {
    const isPromoAvailable = await promoDiscountFlag();

    return (
        <div className="p-4">
            <h1 className="text-2xl font-bold mb-4">Store</h1>

            <div className="grid grid-cols-1 md:grid-cols-2 gap-4">
                <div className="border rounded-lg p-4">
                    <h2 className="text-xl font-semibold mb-2">Basic Plan</h2>
                    <p className="text-gray-600 mb-2">Essential features for everyday use</p>
                    <p className="text-2xl font-bold">$9.99/month</p>
                </div>

                <div className="border rounded-lg p-4">
                    <h2 className="text-xl font-semibold mb-2">Premium Plan</h2>
                    <p className="text-gray-600 mb-2">Advanced features for power users</p>
                    { isPromoAvailable ? (
                        <div>
                            <p className="text-sm text-gray-500 line-through">$19.99/month</p>
                            <p className="text-2xl font-bold text-green-600">$14.99/month</p>
                            <p className="text-sm text-green-600">Special regional promotion!</p>
                        </div>
                    ) : (
                        <p className="text-2xl font-bold">$19.99/month</p>
                    )}
                </div>
            </div>
        </div>
    );
}

Server-side patterns for static pages

You can use feature flags on the client side, but that will lead to unnecessary loaders/skeletons or layout shifts, which are never that great. Of course, it brings benefits, like static rendering.

To maintain static rendering benefits while using server-side flags, the SDK provides a method called precompute.

Precompute

Precompute lets you decide which page version to display based on feature flags and then we can cache that page to statically render it. You can precompute flag combinations in Middleware or Route Handlers:

app
 ↳flags.js

import { flag } from "flags/next";

export const showNewLayout = flag({
    // Definition
    key: 'new-layout',
    // Context
    identify({ cookies }) {
        const userId = cookies.get('user-id')?.value;
        return { user: userId ? { id: userId } : undefined };
    },
    // Evaluation
    decide({ entities }) {
        return entities?.user?.id === '12';
    },
});

export const showSilksongBanner = flag({
    key: 'silksong-banner',
    identify({ cookies }) {
        return { user: cookies.get('vessel')?.value ? { id: cookies.get('vessel')?.value } : undefined };
    },
    decide({ entities }) {
        return entities?.user?.id === 'hornet';
    },
});

// Export our flags in an array (it can be just one or multiple flags)
export const homePageFlags = [showNewLayout, showSilksongBanner];

Next, inside a middleware (or route handler), we will precompute these flags and create static pages per each combination of them.

// middleware.ts
import { type NextRequest, NextResponse } from 'next/server';
import { precompute } from 'flags/next';
import { homePageFlags } from './flags';

// Note that we're running this middleware for / only, but
//You could extend it to further pages you're experimenting on
export const config = { matcher: ['/'] };

export async function middleware(request: NextRequest) {
  // precompute returns a string encoding each flag's returned value
  const code = await precompute(homePageFlags);

  // rewrites the request to include the precomputed code for this flag combination
  const nextUrl = new URL(
    `/${code}${request.nextUrl.pathname}${request.nextUrl.search}`,
    request.url,
  );

  return NextResponse.rewrite(nextUrl, { request });
}

The user will never notice this because, as we use “rewrite”, they will only see the original URL.

Now, on our page, we “invoke” our flags, sending the code from the params:

app
 ↳[code]
   ↳page.jsx

import { Params } from "next/dist/server/request/params";
import { showSilksongBanner, homePageFlags, showNewLayout } from "../flags";

export default async function Page({ params }) {
    const { code } = params;
    const shouldShowSilksongBanner = await showSilksongBanner(code, homePageFlags);
    const shouldShowNewLayout = await showNewLayout(code, homePageFlags);

    return (
        <div className="p-4">
            {shouldShowSilksongBanner && (
                <div className="bg-blue-100 p-3 mb-4 rounded">
                    🎮 Silksong Available
                </div>
            )}

            <div className="bg-white p-4 rounded shadow">
                <h1 className="text-xl font-bold mb-2">Welcome to Hallownest</h1>

                {shouldShowNewLayout ? (
                    <div className="mt-4">
                        <h2 className="font-semibold mb-2">Your Progress</h2>
                        <div className="space-y-2">
                            <div>✅ 3 areas completed</div>
                            <div>🔄 2 areas in progress</div>
                            <div>🔒 5 areas locked</div>
                        </div>
                    </div>
                ) : (
                    <p className="text-gray-600">Start your journey in the vast underground kingdom.</p>
                )}
            </div>
        </div>
    );
}

By sending our code, we are not really invoking the flag again but getting the value right away. Our middleware is deciding which variation of our pages to display to the user.

Finally, after rendering our page, we can enable Incremental Static Regeneration (ISR). ISR allows us to cache the page and serve it statically for subsequent user requests:

import { Params } from "next/dist/server/request/params";
import { showSilksongBanner, homePageFlags, showNewLayout } from "../flags";

interface HomeParams extends Params {
    code: string;
}

export async function generateStaticParams() {
    // returning an empty array is enough to enable ISR
    return [];
}

export default async function Page({ params }: { params: HomeParams }) {
...
}

Using precompute is particularly beneficial when enabling ISR for pages that depend on flags whose values cannot be determined at build time. Headers, geo, etc., we can’t know their value at build, so we use precompute() so the Edge can evaluate it on the fly. In these cases, we rely on Middleware to dynamically determine the flag values, generate the HTML content once, and then cache it. At build time, we simply create an initial HTML shell.

Generate Permutations

If we prefer to generate static pages at build-time instead of runtime, we can use the generatePermutations function from the Flags SDK. This method enables us to pre-generate static pages with different combinations of flags at build time. It's especially useful when the flag values are known beforehand. For example, scenarios involving A/B testing and a marketing site with a single on/off banner flag are ideal use cases.

app
 ↳flags.js

import { flag } from 'flags/next'; 

export const showSilksongBanner = flag({
    key: 'showSilksongBanner',
    decide() {
        return true;
    },
});

export const showNewLayout = flag({
    key: 'showNewLayout',
    decide() {
        return true;
    },
});

export const greetingStyle = flag({
    key: 'greetingStyle',
    options: ['classic', 'modern', 'steampunk'],
    decide() {
        return 'classic';
    },
});

export const homePageFlags = [
  showSilksongBanner,
  showNewLayout,
  greetingStyle,
];

import { generatePermutations } from 'flags/next';
import {
  showSilksongBanner,
  showNewLayout,
  greetingStyle,
  homePageFlags,
} from '../flags';
import { Params } from 'next/dist/server/request/params';

// 1) at build time, Next will run this and prerender each combo
export async function generateStaticParams() {
  const codes = await generatePermutations(homePageFlags);
  return codes.map((code) => ({ code }));
}

export default async function Page({ params }) {
  const { code } = params;

  // 2) at request time, Next simply reads the prerendered HTML for this code
  const showBanner = await showSilksongBanner(code, homePageFlags);
  const useNewLayout = await showNewLayout(code, homePageFlags);
  const style = await greetingStyle(code, homePageFlags);

  return (
    <div className="p-4">
      {showBanner && (
        <div className="bg-blue-100 p-3 mb-4 rounded">
          🎮 Silksong Available
        </div>
      )}

      <div className="bg-white p-4 rounded shadow">
        <h1 className="text-xl font-bold mb-2">
          {style === 'steampunk'
            ? 'Welcome, Cog-and-Gear Explorer!'
            : style === 'modern'
            ? 'Welcome Back to Hallownest'
            : 'Welcome to Hallownest'}
        </h1>

        {useNewLayout ? (
          <div className="mt-4">
            <h2 className="font-semibold mb-2">Your Progress</h2>
            <div className="space-y-2">
              <div>✅ 3 areas completed</div>
              <div>🔄 2 areas in progress</div>
              <div>🔒 5 areas locked</div>
            </div>
          </div>
        ) : (
          <p className="text-gray-600">
            Start your journey in the vast underground kingdom.
          </p>
        )}
      </div>
    </div>
  );
}

Conclusion

Vercel’s Flags SDK stands out as a powerful yet straightforward solution for managing feature flags efficiently. With its ease of use, remarkable flexibility, and effective patterns for reducing latency, this SDK streamlines the development process and enhances your app’s performance. Whether you're building a Next.js, React, or SvelteKit application, the Flags SDK provides intuitive tools that keep your application consistent, responsive, and maintainable. Give it a try, and see firsthand how it can simplify your feature management workflow!

In the first part of my series on the importance of a scientific mindset in software engineering, we explored how the principles of the scientific method can help us evaluate sources and make informed decisions. Now, we will focus on how these principles can help us tackle one of the most crucial and challenging tasks in software engineering: debugging.

In software engineering, debugging is often viewed as an art - an intuitive skill honed through experience and trial and error. In a way, it is - the same as a GP, even a very evidence-based one, will likely diagnose most of their patients based on their experience and intuition and not research scientific literature every time; a software engineer will often rely on their experience and intuition to identify and fix common bugs. However, an internist faced with a complex case will likely not be able to rely on their intuition alone and must apply the scientific method to diagnose the patient. Similarly, a software engineer can benefit from using the scientific method to identify and fix the problem when faced with a complex bug.

From that perspective, treating engineering challenges like scientific inquiries can transform the way we tackle problems. Rather than resorting to guesswork or gut feelings, we can apply the principles of the scientific method—forming hypotheses, designing controlled experiments, gathering and evaluating evidence—to identify and eliminate bugs systematically.

This approach, sometimes referred to as "scientific debugging," reframes debugging from a haphazard process into a structured, disciplined practice. It encourages us to be skeptical, methodical, and transparent in our reasoning. For instance, as Andreas Zeller notes in the book Why Programs Fail, the key aspect of scientific debugging is its explicitness: Using the scientific method, you make your assumptions and reasoning explicit, allowing you to understand your assumptions and often reveals hidden clues that can lead to the root cause of the problem on hand.

Note: If you'd like to read an excerpt from the book, you can find it on Embedded.com.

Scientific Debugging

At its core, scientific debugging applies the principles of the scientific method to the process of finding and fixing software defects. Rather than attempting random fixes or relying on intuition, it encourages engineers to move systematically, guided by data, hypotheses, and controlled experimentation. By adopting debugging as a rigorous inquiry, we can reduce guesswork, speed up the resolution process, and ensure that our fixes are based on solid evidence.

Just as a scientist begins with a well-defined research question, a software engineer starts by identifying the specific symptom or error condition. For instance, if our users report inconsistencies in the data they see across different parts of the application, our research question could be: "Under what conditions does the application display outdated or incorrect user data?"

From there, we can follow a structured debugging process that mirrors the scientific method:

• 1. Observe and Define the Problem: First, we need to clearly state the bug's symptoms and the environment in which it occurs. We should isolate whether the issue is deterministic or intermittent and identify any known triggers if possible. Such a structured definition serves as the groundwork for further investigation.

• 2. Formulate a Hypothesis: A hypothesis in debugging is a testable explanation for the observed behavior. For instance, you might hypothesize: "The data inconsistency occurs because a caching layer is serving stale data when certain user profiles are updated." The key is that this explanation must be falsifiable; if experiments don't support the hypothesis, it must be refined or discarded.

• 3. Collect Evidence and Data: Evidence often includes logs, system metrics, error messages, and runtime traces. Similar to reviewing primary sources in academic research, treat your raw debugging data as crucial evidence. Evaluating these data points can reveal patterns. In our example, such patterns could be whether the bug correlates with specific caching mechanisms, increased memory usage, or database query latency. During this step, it's essential to approach data critically, just as you would analyze the quality and credibility of sources in a research literature review. Don't forget that even logs can be misleading, incomplete, or even incorrect, so cross-referencing multiple sources is key.

• 4. Design and Run Experiments: Design minimal, controlled tests to confirm or refute your hypothesis. In our example, you may try disabling or shortening the cache's time-to-live (TTL) to see if more recent data is displayed correctly. By manipulating one variable at a time - such as cache invalidation intervals - you gain clearer insights into causation. Tools such as profilers, debuggers, or specialized test harnesses can help isolate factors and gather precise measurements.

• 5. Analyze Results and Refine Hypotheses: If the experiment's outcome doesn't align with your hypothesis, treat it as a stepping stone, not a dead end. Adjust your explanation, form a new hypothesis, or consider additional variables (for example, whether certain API calls bypass caching). Each iteration should bring you closer to a better understanding of the bug's root cause. Remember, the goal is not to prove an initial guess right but to arrive at a verifiable explanation.

• 6. Implement and Verify the Fix: Once you're confident in the identified cause, you can implement the fix. Verification doesn't stop at deployment - re-test under the same conditions and, if possible, beyond them. By confirming the fix in a controlled manner, you ensure that the solution is backed by evidence rather than wishful thinking.

  • Personally, I consider implementing end-to-end tests (e.g., with Playwright) that reproduce the bug and verify the fix to be a crucial part of this step. This both ensures that the bug doesn't reappear in the future due to changes in the codebase and avoids possible imprecisions of manual testing.

Now, we can explore these steps in more detail, highlighting how the scientific method can guide us through the debugging process.

Establishing Clear Debugging Questions (Formulating a Hypothesis)

A hypothesis is a proposed explanation for a phenomenon that can be tested through experimentation. In a debugging context, that phenomenon is the bug or issue you're trying to resolve. Having a clear, falsifiable statement that you can prove or disprove ensures that you stay focused on the real problem rather than jumping haphazardly between possible causes. A properly formulated hypothesis lets you design precise experiments to evaluate whether your explanation holds true.

To formulate a hypothesis effectively, you can follow these steps:

1. Clearly Identify the Symptom(s)

Before forming any hypothesis, pin down the specific issue users are experiencing. For instance:

• "Users intermittently see outdated profile information after updating their accounts."
• "Some newly created user profiles don't reflect changes in certain parts of the application."

Having a well-defined problem statement keeps your hypothesis focused on the actual issue. Just like a research question in science, the clarity of your symptom definition directly influences the quality of your hypothesis.

2. Draft a Tentative Explanation

Next, convert your symptom into a statement that describes a possible root cause, such as:

• "Data inconsistency occurs because the caching layer isn't invalidating or refreshing user data properly when profiles are updated."

• "Stale data is displayed because the cache timeout is too long under certain load conditions."

This step makes your assumption about the root cause explicit. As with the scientific method, your hypothesis should be something you can test and either confirm or refute with data or experimentation.

3. Ensure Falsifiability

A valid hypothesis must be falsifiable - meaning it can be proven wrong. You'll struggle to design meaningful experiments if a hypothesis is too vague or broad. For example:

• Not Falsifiable: "Occasionally, the application just shows weird data."

• Falsifiable: "Users see stale data when the cache is not invalidated within 30 seconds of profile updates."

Making your hypothesis specific enough to fail a test will pave the way for more precise debugging.

4. Align with Available Evidence

Match your hypothesis to what you already know - logs, stack traces, metrics, and user reports. For example:

• If logs reveal that cache invalidation events aren't firing, form a hypothesis explaining why those events fail or never occur.

• If metrics show that data served from the cache is older than the configured TTL, hypothesize about how or why the TTL is being ignored.

If your current explanation contradicts existing data, refine your hypothesis until it fits.

5. Plan for Controlled Tests

Once you have a testable hypothesis, figure out how you'll attempt to disprove it. This might involve:

• Reproducing the environment: Set up a staging/local system that closely mimics production. For instance with the same cache layer configurations.

• Varying one condition at a time: For example, only adjust cache invalidation policies or TTLs and then observe how data freshness changes.

• Monitoring metrics: In our example, such monitoring would involve tracking user profile updates, cache hits/misses, and response times. These metrics should lead to confirming or rejecting your explanation.

These plans become your blueprint for experiments in further debugging stages.

Collecting and Evaluating Evidence

After formulating a clear, testable hypothesis, the next crucial step is to gather data that can either support or refute it. This mirrors how scientists collect observations in a literature review or initial experiments.

1. Identify "Primary Sources" (Logs, Stack Traces, Code History):

   • Logs and Stack Traces: These are your direct pieces of evidence - treat them like raw experimental data. For instance, look closely at timestamps, caching-related events (e.g., invalidation triggers), and any error messages related to stale reads.

   • Code History: Look for related changes in your source control, e.g. using Git bisect. In our example, we would look for changes to caching mechanisms or references to cache libraries in commits, which could pinpoint when the inconsistency was introduced. Sometimes, reverting a commit that altered cache settings helps confirm whether the bug originated there.

2. Corroborate with "Secondary Sources" (Documentation, Q&A Forums):

   • Documentation: Check official docs for known behavior or configuration details that might differ from your assumptions.

   • Community Knowledge: Similar issues reported on GitHub or StackOverflow may reveal known pitfalls in a library you're using.

3. Assess Data Quality and Relevance:

   • Look for Patterns: For instance, does stale data appear only after certain update frequencies or at specific times of day?

   • Check Environmental Factors: For instance, does the bug happen only with particular deployment setups, container configurations, or memory constraints?

   • Watch Out for Biases: Avoid seeking only the data that confirms your hypothesis. Look for contradictory logs or metrics that might point to other root causes.

You keep your hypothesis grounded in real-world system behavior by treating logs, stack traces, and code history as primary data - akin to raw experimental results. This evidence-first approach reduces guesswork and guides more precise experiments.

Designing and Running Experiments

With a hypothesis in hand and evidence gathered, it's time to test it through controlled experiments - much like scientists isolate variables to verify or debunk an explanation.

1. Set Up a Reproducible Environment:

   • Testing Environments: Replicate production conditions as closely as possible. In our example, that would involve ensuring the same caching configuration, library versions, and relevant data sets are in place.

   • Version Control Branches: Use a dedicated branch to experiment with different settings or configuration, e.g., cache invalidation strategies. This streamlines reverting changes if needed.

2. Control Variables One at a Time:

   • For instance, if you suspect data inconsistency is tied to cache invalidation events, first adjust only the invalidation timeout and re-test.

   • Or, if concurrency could be a factor (e.g., multiple requests updating user data simultaneously), test different concurrency levels to see if stale data issues become more pronounced.

3. Measure and Record Outcomes:

   • Automated Tests: Tests provide a great way to formalize and verify your assumptions. For instance, you could develop tests that intentionally update user profiles and check if the displayed data matches the latest state.

   • Monitoring Tools: Monitor relevant metrics before, during, and after each experiment. In our example, we might want to track cache hit rates, TTL durations, and query times.

   • Repeat Trials: Consistency across multiple runs boosts confidence in your findings.

4. Validate Against a Baseline:

   • If baseline tests manifest normal behavior, but your experimental changes manifest the bug, you've isolated the variable causing the issue. E.g. if the baseline tests show that data is consistently fresh under normal caching conditions but your experimental changes cause stale data.

   • Conversely, if your change eliminates the buggy behavior, it supports your hypothesis - e.g. that the cache configuration was the root cause.

Each experiment outcome is a data point supporting or contradicting your hypothesis. Over time, these data points guide you toward the true cause.

Analyzing Results and Iterating

In scientific debugging, an unexpected result isn't a failure - it's valuable feedback that brings you closer to the right explanation.

1. Compare Outcomes to the hypothesis. For instance:

   • Did user data stay consistent after you reduced the cache TTL or fixed invalidation logic?

   • Did logs show caching events firing as expected, or did they reveal unexpected errors?

   • Are there only partial improvements that suggest multiple overlapping issues?

2. Incorporate Unexpected Observations:

   • Sometimes, debugging uncovers side effects - e.g. performance bottlenecks exposed by more frequent cache invalidations. Note these for future work.

   • If your hypothesis is disproven, revise it. For example, the cache may only be part of the problem, and a separate load balancer setting also needs attention.

3. Avoid Confirmation Bias:

   • Don't dismiss contrary data. For instance, if you see evidence that updates are fresh in some modules but stale in others, you may have found a more nuanced root cause (e.g., partial cache invalidation).

   • Consider other credible explanations if your teammates propose them. Test those with the same rigor.

4. Decide If You Need More Data:

   • If results aren't conclusive, add deeper instrumentation or enable debug modes to capture more detailed logs.

   • For production-only issues, implement distributed tracing or sampling logs to diagnose real-world usage patterns.

5. Document Each Iteration:

   • Record the results of each experiment, including any unexpected findings or new hypotheses that arise.

   • Through iterative experimentation and analysis, each cycle refines your understanding. By letting evidence shape your hypothesis, you ensure that your final conclusion aligns with reality.

Implementing and Verifying the Fix

Once you've identified the likely culprit - say, a misconfigured or missing cache invalidation policy - the next step is to implement a fix and verify its resilience.

1. Implementing the Change:

   • Scoped Changes: Adjust just the component pinpointed in your experiments. Avoid large-scale refactoring that might introduce other issues.

   • Code Reviews: Peer reviews can catch overlooked logic gaps or confirm that your changes align with best practices.

2. Regression Testing:

   • Re-run the same experiments that initially exposed the issue. In our stale data example, confirm that the data remains fresh under various conditions.

   • Conduct broader tests - like integration or end-to-end tests - to ensure no new bugs are introduced.

3. Monitoring in Production:

   • Even with positive test results, real-world scenarios can differ. Monitor logs and metrics (e.g. cache hit rates, user error reports) closely post-deployment.

   • If the buggy behavior reappears, revisit your hypothesis or consider additional factors, such as unpredicted user behavior.

4. Benchmarking and Performance Checks (If Relevant):

   • When making changes that affect the frequency of certain processes - such as how often a cache is refreshed - be sure to measure the performance impact. Verify you meet any latency or resource usage requirements.

   • Keep an eye on the trade-offs: For instance, more frequent cache invalidations might solve stale data but could also raise system load.

By systematically verifying your fix - similar to confirming experimental results in research - you ensure that you've addressed the true cause and maintained overall software stability.

Documenting the Debugging Process

Good science relies on transparency, and so does effective debugging. Thorough documentation guarantees your findings are reproducible and valuable to future team members.

1. Record Your Hypothesis and Experiments:

   • Keep a concise log of your main hypothesis, the tests you performed, and the outcomes.

   • A simple markdown file within the repo can capture critical insights without being cumbersome.

2. Highlight Key Evidence and Observations:

   • Note the logs or metrics that were most instrumental - e.g., seeing repeated stale cache hits 10 minutes after updates.

   • Document any edge cases discovered along the way.

3. List Follow-Up Actions or Potential Risks:

   • If you discover additional issues - like memory spikes from more frequent invalidation - note them for future sprints.

   • Identify parts of the code that might need deeper testing or refactoring to prevent similar issues.

4. Share with Your Team:

   • Publish your debugging report on an internal wiki or ticket system. A well-documented troubleshooting narrative helps educate other developers.

   • Encouraging open discussion of the debugging process fosters a culture of continuous learning and collaboration.

By paralleling scientific publication practices in your documentation, you establish a knowledge base to guide future debugging efforts and accelerate collective problem-solving.

Conclusion

Debugging can be as much a rigorous, methodical exercise as an art shaped by intuition and experience. By adopting the principles of scientific inquiry - forming hypotheses, designing controlled experiments, gathering evidence, and transparently documenting your process - you make your debugging approach both systematic and repeatable.

The explicitness and structure of scientific debugging offer several benefits:

• Better Root-Cause Discovery: Structured, hypothesis-driven debugging sheds light on the true underlying factors causing defects rather than simply masking symptoms.

• Informed Decisions: Data and evidence lead the way, minimizing guesswork and reducing the chance of reintroducing similar issues.

• Knowledge Sharing: As in scientific research, detailed documentation of methods and outcomes helps others learn from your process and fosters a collaborative culture.

Ultimately, whether you are diagnosing an intermittent crash or chasing elusive performance bottlenecks, scientific debugging brings clarity and objectivity to your workflow. By aligning your debugging practices with the scientific method, you build confidence in your solutions and empower your team to tackle complex software challenges with precision and reliability.

But most importantly, do not get discouraged by the number of rigorous steps outlined above or by the fact you won't always manage to follow them all religiously. Debugging is a complex and often frustrating process, and it's okay to rely on your intuition and experience when needed. Feel free to adapt the debugging process to your needs and constraints, and as long as you keep the scientific mindset at heart, you'll be on the right track.

In a world drowning in PDFs and paperwork, I never thought I’d get goosebumps about agreements – until I attended Docusign Momentum 2025. I went in expecting talks about e-signatures; I left realizing the big push and emphasis with many enterprise-level organizations will be around Intelligent Agreement Management (IAM). It is positioned to transform how we build business software, so let’s talk about it. As Director of Technology at This Dot Labs, I had a front-row seat to all the exciting announcements at Docusign Momentum. Our team also had a booth there showing off the 6 Docusign extension apps This Dot Labs has released this year. We met 1-on-1 with a lot of companies and leaders to discuss the exciting promise of IAM. What can your company accomplish with IAM? Is it really worth it for you to start adopting IAM?? Let’s dive in and find out.

After his keynote, I met up with Robert Chatwani, President of Docusign and he said this

“At Docusign, we truly believe that the power of a great platform is that you won’t be able to exactly predict what can be built on top of it,and builders and developers are at the heart of driving this type of innovation. Now with AI, we have entered what I believe is a renaissance era for new ideas and business models, all powered by developers.”

Docusign’s annual conference in NYC was an eye-opener: agreements are no longer just documents to sign and shelve, but dynamic data hubs driving key processes. Here’s my take on what I learned, why it matters, and why developers should pay attention.

From E-Signatures to Intelligent Agreements – A New Era

Walking into Momentum 2025, you could feel the excitement. Docusign’s CEO and product team set the tone in the keynote: “Agreements make the world go round, but for too long they’ve been stuck in inboxes and PDFs, creating drag on your business.” Their message was clear – Docusign is moving from a product to a platform​. In other words, the company that pioneered e-signatures now aims to turn static contracts into live, integrated assets that propel your business forward.

I saw this vision click when I chatted with an attendee from a major financial services firm. His team manages millions of forms a year – loan applications, account forms, you name it. He admitted they were still “just scanning and storing PDFs” and struggled to imagine how IAM could help. We discussed how much value was trapped in those documents (what Docusign calls the “Agreement Trap” of disconnected processes​). By the end of our coffee, the lightbulb was on: with the right platform, those forms could be automatically routed, data-extracted, and trigger workflows in other systems – no more black hole of PDFs. His problem wasn’t unique; many organizations have critical data buried in agreements, and they’re waking up to the idea that it doesn’t have to be this way.

What Exactly is Intelligent Agreement Management (IAM)?

So what is Docusign’s Intelligent Agreement Management? In essence, IAM is an AI-powered platform that connects every part of the agreement lifecycle. It’s not a single product, but a collection of services and tools working in concert​. Docusign IAM helps transform agreement data into insights and actions, accelerate contract cycles, and boost productivity across departments. The goal is to address the inefficiencies in how agreements are created, signed, and managed – those inefficiencies that cost businesses time and money.

At Momentum, Docusign showcased the core components of IAM:

• Docusign Navigator link: A smart repository to centrally store, search, and analyze agreements. It uses AI to convert your signed documents (which are basically large chunks of text) into structured, queryable data​. Instead of manually digging through contracts for a specific clause, you can search across all agreements in seconds. Navigator gives you a clear picture of your organization’s contractual relationships and obligations (think of it as Google for your contracts). Bonus: it comes with out-of-the-box dashboards for things like renewal dates, so you can spot risks and opportunities at a glance.

• Docusign Maestro link: A no-code workflow engine to automate agreement workflows from start to finish. Maestro lets you design customizable workflows that orchestrate Docusign tasks and integrate with third-party apps – all without writing code​. For example, you could have a workflow for new vendor onboarding: once a vendor contract is signed, Maestro could automatically notify your procurement team, create a task in your project tracker, and update a record in your ERP system. At the conference, they demoed how Maestro can streamline processes like employee onboarding and compliance checks through simple drag-and-drop steps or archiving PDFs of signed agreements into Google Drive or Dropbox.

• Docusign Iris (AI Engine) link: The brains of the operation. Iris is the new AI engine powering all of IAM’s “smarts” – from reading documents to extracting data and making recommendations​. It’s behind features like automatic field extraction, AI-assisted contract review, intelligent search, and even document summarization. In the keynote, we saw examples of Iris in action: identify key terms (e.g. payment terms or renewal clauses) across a stack of contracts, or instantly generate a summary of a lengthy agreement. These capabilities aren’t just gimmicks; as one Docusign executive put it, they’re “signals of a new way of working with agreements”. Iris essentially gives your agreement workflow a brain – it can understand the content of agreements and help you act on it.

• Docusign App Center link: A hub to connect the tools of your trade into Docusign. App Center is like an app store for integrations – it lets you plug in other software (project management, CRM, HR systems, etc.) directly into your Maestro workflows. This is huge for developers (and frankly, anyone tired of building one-off integrations). Instead of treating Docusign as an isolated e-signature tool, App Center makes it a platform you can extend. I’ll dive more into this in the next section, since it’s close to my heart – my team helped build some of these integrations!

In short, IAM ties together the stages of an agreement (create → sign → store → manage) and supercharges each with automation and AI. It’s modular, too – you can adopt the pieces you need. Docusign essentially unbundled the agreement process into building blocks that developers and admins can mix-and-match. The future of agreements, as Docusign envisions it, is a world where organizations “seamlessly add, subtract, and rearrange modular solutions to meet ever-changing needs” on a single trusted platform.

The App Center and Real-World Integrations (Yes, We Built Those!)

One of the most exciting parts of Momentum 2025 for me was seeing the Docusign App Center come alive. As someone who works on integrations, I was practically grinning during the App Center demos. Docusign highlighted several partner-built apps that snap into IAM, and I’m proud to say This Dot Labs built six of them – including integrations for Monday.com, Slack, Jira, Asana, Airtable, and Mailchimp. Why are these integrations a big deal? Because developers often spend countless hours wiring up systems that need to talk to each other. With App Center, a lot of that heavy lifting is already done. You can install an app with a few clicks and configure data flows in minutes instead of coding for months​. In fact, a study found it takes the average org 12 months to develop a custom workflow via APIs, whereas with Docusign’s platform you can do it via configuration almost immediately​. That’s a game-changer for time-to-value. At our This Dot Labs booth, I spoke with many developers who were intrigued by these possibilities. For example, we showed how our Docusign Slack Extension lets teams send Slack messages and notifications when agreements are sent and signed.. If a sales contract gets signed, the Slack app can automatically post a notification in your channel and even attach the signed PDF – no more emailing attachments around. People loved seeing how easily Docusign and Slack now talk to each other using this extension​. Another popular one was our Monday.com app. With it, as soon as an agreement is signed, you can trigger actions in Monday – like assigning onboarding tasks for a new client or employee. Essentially, signing the document kicks off the next steps automatically. These integrations showcase why IAM is not just about Docusign’s own features, but about an ecosystem. App Center already includes connectors for popular platforms like Salesforce, HubSpot, Workday, ServiceNow, and more. The apps we built for Monday, Slack, Jira, etc., extend that ecosystem. Each app means one less custom integration a developer has to build from scratch. And if an app you need doesn’t exist yet – well, that’s an opportunity. (Shameless plug: we’re happy to help build it!)

The key takeaway here is that Docusign is positioning itself as a foundational layer in the enterprise software stack. Your agreement workflow can now natively include things like project management updates, CRM entries, notifications, and data syncs. As a developer, I find that pretty powerful. It’s a shift from thinking of Docusign as a single SaaS tool to thinking of it as a platform that glues processes together.

Not Just Another Contract Tool – Why IAM Matters for Business

After absorbing all the Momentum keynotes and sessions, one thing is clear: IAM is not “just another contract management tool.” It’s aiming to be the platform that automates critical business processes which happen to revolve around agreements. The use cases discussed were not theoretical – they were tangible scenarios every developer or IT lead will recognize:

• Procurement Automation: We heard how companies are using IAM to streamline procurement. Imagine a purchase order process where a procurement request triggers an agreement that goes out for e-signature, and once signed, all relevant systems update instantly. One speaker described connecting Docusign with their ERP so that vendor contracts and purchase orders are generated and tracked automatically. This reduces the back-and-forth with legal and ensures nothing falls through the cracks. It’s easy to see the developer opportunity: instead of coding a complex procurement approval system from scratch, you can leverage Docusign’s workflow + integration hooks to handle it. Docusign IAM is designed to connect to systems like CRM, HR, and ERP so that agreements flow into the same stream of data. For developers, that means using pre-built connectors and APIs rather than reinventing them.

• Faster Employee Onboarding: Onboarding a new hire or client typically involves a flurry of forms and tasks – offer letters or contracts to sign, NDAs, setup of accounts, etc. We saw how IAM can accelerate onboarding by combining e-signature with automated task generation. For instance, the moment a new hire signs their offer letter, Maestro could trigger an onboarding workflow: provisioning the employee in systems, scheduling orientation, and creating tasks in tools like Asana or Monday. All those steps get kicked off by the signed agreement. Docusign Maestro’s integration capabilities shine here – it can tie into HR systems or project management apps to carry the baton forward​. The result is a smoother day-one experience for the new hire and less manual coordination for IT and HR. As developers, we can appreciate how this modular approach saves us from writing yet another “onboarding script”; we configure the workflow, and IAM handles the rest.

• Reducing Contract Auto-Renewal Risk: If your company manages a lot of recurring contracts (think vendor services, subscriptions, leases), missing a renewal deadline can be costly. One real-world story shared at Momentum was about using IAM to prevent unwanted auto-renewals. With traditional tracking (spreadsheets or calendar reminders), it’s easy to forget a termination notice and end up locked into a contract for another year. Docusign’s solution: let the AI engine (Iris) handle it. It can scan your repository, surface any renewal or termination dates, and proactively remind stakeholders – or even kick off a non-renewal workflow if desired. As the Bringing Intelligence to Obligation Management session highlighted, “Missed renewal windows lead to unwanted auto-renewals or lost revenue… A forgotten termination deadline locks a company into an unneeded service for another costly term.”​ With IAM, those pitfalls are avoidable. The system can automatically flag and assign tasks well before a deadline hits​. For developers, this means we can deliver risk-reduction features without building a custom date-tracking system – the platform’s AI and notification framework has us covered.

These examples all connect to a bigger point: agreements are often the linchpin of larger business processes (buying something, hiring someone, renewing a service). By making agreements “intelligent,” Docusign IAM is essentially automating chunks of those processes. This translates to real outcomes – faster cycle times, fewer errors, and less risk. From a technical perspective, it means we developers have a powerful ally: we can offload a lot of workflow logic to the IAM platform. Why code it from scratch if a combination of Docusign + a few integration apps can do it?

Why Developers Should Care about IAM (Big Time)

If you’re a software developer or architect building solutions for business teams, you might be thinking: This sounds cool, but is it relevant to me? Let me put it this way – after Momentum 2025, I’m convinced that ignoring IAM would be a mistake for anyone in enterprise software. Here’s why:

• Faster time-to-value for your clients or stakeholders: Business teams are always pressuring IT to deliver solutions faster. With IAM, you have ready-made components to accelerate projects. Need to implement a contract approval workflow? Use Maestro, not months of coding. Need to integrate Docusign with an internal system? Check App Center for an app or use their APIs with far less glue code. Docusign’s own research shows that connecting systems via App Center and Maestro can cut development time dramatically (from ~12 months of custom dev to mere weeks or less). For us developers, that means we can deliver results sooner, which definitely wins points with the business.

• Fewer custom builds (and less maintenance): Let’s face it – maintaining custom scripts or one-off integrations is not fun. Every time a SaaS API changes or a new requirement comes in, you’re back in the code. IAM’s approach offers more reuse and configuration instead of raw code. The platform is doing the hard work of staying updated (for example, when Slack or Salesforce change something in their API, Docusign’s connector app will handle it). By leveraging these pre-built connectors and templates, you write less custom code, which means fewer bugs and lower maintenance overhead. You can focus your coding effort on the unique parts of your product, not the boilerplate integration logic.

• Reusable and modular workflows: I love designing systems as Lego blocks – and IAM encourages that. You can build a workflow once and reuse it across multiple projects or clients with slight tweaks. For instance, an approval workflow for sales contracts might be 90% similar to one for procurement contracts – with IAM, you can reuse that blueprint. The fact that everything is on one platform also means these workflows can talk to each other or be combined. This modularity is a developer’s dream because it leads to cleaner architecture. Docusign explicitly touts this modular approach, noting that organizations can easily rearrange solutions on the fly to meet new needs​. It’s like having a library of proven patterns to draw from.

• AI enhancements with minimal effort: Adding AI into your apps can be daunting if you have to build or train models yourself. IAM essentially gives you AI-as-a-service for agreements. Need to extract key data from 1,000 contracts? Iris can do that out-of-the-box​. Want to implement a risk scoring for contracts? The AI can flag unusual terms or deviations. As a developer, being able to call an API or trigger a function that returns “these are the 5 clauses to look at” is incredibly powerful – you’re injecting intelligence without needing a data science team. It means you can offer more value in your applications (and impress those end-users!) by simply tapping into IAM’s AI features.

Ultimately, Docusign IAM empowers developers to build more with less code. It’s about higher-level building blocks. This doesn’t replace our jobs – it makes our jobs more focused on the interesting problems. I’d rather spend time designing a great user experience or tackling a complex business rule than coding yet another Docusign-to-Slack integration. IAM is taking care of the plumbing and adding a layer of smarts on top.

Don’t Underestimate Agreement Intelligence – Your Call to Action

Momentum 2025 left me with a clear call to action: embrace agreement intelligence. If you’re a developer or tech leader, it’s time to explore what Docusign IAM can do for your projects. This isn’t just hype from a conference – it’s a real shift in how we can deliver solutions.

Here are a few ways to get started:

• Browse the IAM App Center – Take a look at the growing list of apps in the Docusign App Center. You might find that integration you’ve been meaning to build is already available (or one very close to it). Installing an app is trivial, and you can configure it to fit your workflow. This is the low-hanging fruit to immediately add value to your existing Docusign processes. If you have Docusign eSignature or CLM in your stack, App Center is where you extend it.

• Think about integrations that could unlock value – Consider the systems in your organization that aren’t talking to each other. Is there a manual step where someone re-enters data from a contract into another system? Maybe an approval that’s done via email and could be automated? Those are prime candidates for an IAM solution. For example, if Legal and Sales use different tools, an integration through IAM can bridge them, ensuring no agreement data falls through the cracks. Map out your agreement process end-to-end and identify gaps – chances are, IAM has a feature to fill them.

• Experiment with Maestro and the API – If you’re technical, spin up a trial of Docusign IAM. Try creating a Maestro workflow for a simple use case, or use the Docusign API/SDKs to trigger some AI analysis on a document. Seeing it in action will spark ideas. I was amazed how quickly I could set up a workflow with conditions and parallel steps – things that would take significant coding time if I did them manually. The barrier to entry for adding complex logic has gotten a lot lower.

• Stay informed and involved – Docusign’s developer community and IAM documentation are growing. Momentum may be over, but the “agreement intelligence” movement is just getting started. Keep an eye on upcoming features (they hinted at even more AI-assisted tools coming soon). Engage with the community forums or join Docusign’s IAM webinars. And if you’re building something cool with IAM, consider sharing your story – the community benefits from hearing real use cases.

My final thought: don’t underestimate the impact that agreement intelligence can have in modern workflows. We spend so much effort optimizing various parts of our business, yet often overlook the humble agreement – the contracts, forms, and documents that initiate or seal every deal. Docusign IAM is shining a spotlight on these and saying, “Here is untapped gold. Let’s mine it.” As developers, we have an opportunity (and now the tools) to lead that charge. I’m incredibly excited about this new chapter. After seeing what Docusign has built, I’m convinced that intelligent agreements can be a foundational layer for digital transformation. It’s not just about getting documents signed faster; it’s about connecting dots and automating workflows in ways we couldn’t before. As I reflect on Momentum 2025, I’m inspired and already coding with new ideas in mind. I encourage you to do the same – check out IAM, play with the App Center, and imagine what you could build when your agreements start working intelligently for you. The future of agreements is here, and it’s time for us developers to take full advantage of it.

Ready to explore? Head to the Docusign App Center and IAM documentation and see how you can turn your agreements into engines of growth. Trust me – the next time you attend Momentum, you might just have your own success story to share. Happy building!

Her days were filled with rehearsals, concerts, and teaching, and she hadn’t considered a tech career until the world changed in 2020.

“When the pandemic hit, most of my gigs were canceled,” she says. “I suddenly had time on my hands and an idea for a site I wanted to build.”

That site, a tribute to Black musicians in classical and jazz music, turned into much more than a personal project. It opened the door to a whole new career where her creative instincts and curiosity could thrive just as much as they had in music.

Now at freeCodeCamp, Jessica maintains and develops the very JavaScript curriculum that has helped her and millions of developers around the world.

We spoke with Jessica about her advice for JavaScript learners, why musicians make great developers, and how inclusive communities are helping more women thrive in tech.

Jessica’s Top 3 JavaScript Skill Picks for 2025

If you ask Jessica what it takes to succeed as a JavaScript developer in 2025, she won’t point you straight to the newest library or trend.

Instead, she lists three skills that sound simple, but take real time to build:

“Learning how to ask questions and research when you get stuck. Learning how to read error messages. And having a strong foundation in the fundamentals”

She says those skills don’t come from shortcuts or shiny tools. They come from building.

“Start with small projects and keep building,” she says. “Books like You Don’t Know JS help you understand the theory, but experience comes from writing and shipping code. You learn a lot by doing.”

And don’t forget the people around you.

“Meetups and conferences are amazing,” she adds. “You’ll pick up things faster, get feedback, and make friends who are learning alongside you.”

Why So Many Musicians End Up in Tech

A musical past like Jessica’s isn’t unheard of in the JavaScript industry. In fact, she’s noticed a surprising number of musicians making the leap into software.

“I think it’s because music and code have a lot in common,” she says. “They both require creativity, pattern recognition, problem-solving… and you can really get into flow when you’re deep in either one.”

That crossover between artistry and logic feels like home to people who’ve lived in both worlds.

What the Tech Community Is Getting Right

Jessica has seen both the challenges and the wins when it comes to supporting women in tech.

“There’s still a lot of toxicity in some corners,” she says. “But the communities that are doing it right—like Women Who Code, Women in Tech, and Virtual Coffee—create safe, supportive spaces to grow and share experiences.”

She believes those spaces aren’t just helpful, but they’re essential.

“Having a network makes a huge difference, especially early in your career.”

What’s Next for Jessica Wilkins?

With a catalog of published articles, open-source projects under her belt, and a growing audience of devs following her journey, Jessica is just getting started.

She’s still writing. Still mentoring. Still building. And still proving that creativity doesn’t stop at the orchestra pit—it just finds a new stage.

Follow Jessica Wilkins on X and Linkedin to keep up with her work in tech, her musical roots, and whatever she’s building next.

Sticker illustration by Jacob Ashley.

In her ten years in the space, she’s done more than give great conference talks or build community—she’s helped shape what the DevRel role looks like for software providers. Now as the Senior Director of Developer Relations at GitHub, Ashley is focused on building spaces where developers feel heard, seen, and supported.

“A decade ago, we were seen as amplifiers, not collaborators,” she says. “Now we’re influencing product roadmaps and shaping developer experience end to end.”

DevRel Has Changed

For Ashley, the biggest shift hasn’t been the work itself—but how it’s understood.

“The work is still outward-facing, but it’s backed by real strategic weight,” she explains. “We’re showing up in research calls and incident reviews, not just keynotes.”

That shift matters, but it’s not the finish line. Ashley is still pushing for change when it comes to burnout, representation, and sustainable metrics that go beyond conference ROI.

“We’re no longer fighting to be taken seriously. That’s a win. But there’s more work to do.”

Talking Less as a Leader

When we asked what the best advice Ashley ever received, she shared an early lesson she received from a mentor: “Your presence should create safety, not pressure.”

“It reframed how I saw my role,” she says. “Not as the one with answers, but the one who holds the space.”

Ashley knows what it’s like to be in rooms where it’s hard to speak up. She leads with that memory in mind, and by listening more than talking, normalizing breaks, and creating environments where others can lead too.

“Leadership is emotional labor. It’s not about being in control. It’s about making it safe for others to lead, too.”

Scaling More Than Just Tech

Having worked inside high-growth companies, Ashley knows firsthand: scaling tech is one thing. Scaling trust is another.

“Tech will break. Roadmaps will shift. But if there’s trust between product and engineering, between company and community—you can adapt.”

And she’s learned not to fall for premature optimization. Scale what you have. Don’t over-design for problems you don’t have yet.

Free Open Source Isn’t Free

There’s one myth Ashley is eager to debunk: that open source is “free.”

“Open source isn’t free labor. It’s labor that’s freely given,” she says. “And it includes more than just code. There’s documentation, moderation, mentoring, emotional care. None of it is effortless.”

Open source runs on human energy. And when we treat contributors like an infinite resource, we risk burning them out, and breaking the ecosystem we all rely on.

“We talk a lot about open source as the foundation of innovation. But we rarely talk about sustaining the people who maintain that foundation.”

Burnout is Not Admirable

Early in her career, Ashley wore burnout like a badge of honor. She doesn’t anymore.

“Burnout doesn’t prove commitment,” she says. “It just dulls your spark.”

Now, she treats rest as productive. And she’s learned that clarity is kindness—especially when giving feedback.

“I thought being liked was the same as being kind. It’s not. Kindness is honesty with empathy.”

The Most Underrated GitHub Feature?

Ashley’s pick: personal instructions in GitHub Copilot.

Most users don’t realize they can shape how Copilot writes, like its tone, assumptions, and context awareness.

Her own instructions are specific: empathetic, plainspoken, technical without being condescending. For Ashley, that helps reduce cognitive load and makes the tool feel more human.

“Most people skip over this setting. But it’s one of the best ways to make Copilot more useful—and more humane.”

Connect with Ashley Willis

She has been building better systems for over a decade. Whether it’s shaping Copilot UX, creating safer teams, or speaking truth about the labor behind open source, she’s doing the quiet work that drives sustainable change.

Follow Ashley on BlueSky to learn more about her work, her maker projects, and the small things that keep her grounded in a fast-moving industry.

Sticker Illustration by Jacob Ashley.

Tech giants like Shopify and smaller companies like This Dot Labs have purchased Cursor subscriptions for their developers with the goal of increased productivity.

I have been using Cursor heavily for a few months now and am excited to share how it’s impacted me personally. In this post, we will cover some of the basic features, use cases, and I’ll share some tips and tricks I’ve learned along the way.

If you love coding and building like me, I hope this post will help you unleash some of the superpowers Cursor’s AI coding features make possible. Let’s jump right in!

Cursor 101

The core tools of the Cursor tool belt are Autocomplete, Ask, and Agent.

Feature: Autocomplete

The first thing that got me hooked was Autocomplete. It just worked so much better than the tools I had used previously, like GitHub Copilot. It was quicker and smarter, and I could immediately notice the amount of keystrokes that it was saving me.

This feature is great because it doesn’t really require any work or skilled prompting from the user. There are a couple of tricks for getting a little bit more out of it that I will share later, but for now, just enjoy the ride!

Feature: Ask

If you’ve interacted with AI/LLMs before, like ChatGPT - this is what the Ask feature is. It’s just a chat feature you can easily provide context to from your code base and choose which Model to chat with.

This feature is best suited for just asking more general questions that you might have queried Google or Stack Overflow for in the past. It’s also good for planning how to implement a feature you’re working on.

After chatting or planning, you can switch directly to Agent mode to pick up and take action on something you were cooking up in Ask mode.

Here’s an example of planning a simple tic-tac-toe game implementation using the Ask feature:

Feature: Agent

Agent mode lets the AI model take the wheel and write code, make edits, or take other similar actions on your code base. The goal is that you can write prompts and give instructions, and the Agent can generate the code and build features or even entire applications for you.

With great power comes great responsibility.

Agents are a feature where the more you put into them, the more you get out. The more skilled you become in using them by providing better prompts and including the right context, you will continue to get better results.

The AI doesn’t always get it right, but the fact that the models and the users are both getting better is exciting. Throughout this post, I will share the best use cases, tips, and tricks I have found using Cursor Agent.

Here’s an example using the Agent to execute the implementation details of the tic-tac-toe game we planned using Ask:

Core Concept: Context

After understanding the features and the basics of prompting, context is the most important thing for getting the best results out of Cursor.

In Cursor and in general, whenever you’re prompting a chat or an agent, you want to make sure that it has all the relevant information that it needs to provide an answer or result.

Cursor, by default, always has some context of your code. It indexes your code base and usually keeps the open buffer in the context window at the very least.

At the top left of the Ask or Agent panel, there is an @ button, and next to that are badges for all the current items that have been explicitly added to the context for the current session. The @ button has a dropdown that allows you to add files, folders, web links, past chats, git commits, and more to the context.

Before you prompt, always make sure you add the relevant content it needs as context so that it has everything it needs to provide the best response.

Settings and Rules

Cursor has its own settings page, which you can access through Cursor → Settings → Cursor Settings.

This is where you log in to your account, manage various features, and enable or disable models.

In the General section, there is an option for Privacy Mode. This is one setting in particular I recommend enabling. Aside from that, just explore around and see what’s available.

Models

The model you use is just as important as your prompt and the context that you provide. Models are the underlying AI/LLM used to process your input. The most well-known is GPT-4o, the default model for ChatGPT. There are a lot of different models available, and Cursor provides access to most of them out of the box.

Model pricing

A lot of the most common models, like GPT-4o or Sonnet 3.5/3.7, are included in your Cursor subscription. Some models like o1 and Sonnet 3.7 MAX are considered premium models, and you will be billed for usage for these.

Be sure to pay attention to which models you are using so you don’t get any surprise bills.

Choosing a Model

Some models are better suited for certain tasks than others. You can configure which models are enabled in the Cursor Settings.

If you are planning out a big feature or trying to solve some complex logic issue, you may want to use one of the thinking models, like o1, o3-mini, or Deep Seek R1.

For most coding tasks and as a good default, I recommend using Sonnet 3.5 or 3.7.

The great thing about Cursor is that you have the options available right in your editor. The most important piece of advice that I can give in this post is to keep trying things out and experimenting. Try out different models for different tasks, get a feel for it, and find what works for you.

Use cases

Agents and LLM models are still far from perfect. That being said, there are already a lot of tasks they are very good at. The more effective you are with these tools, the more you will be able to get done in a shorter amount of time.

Generating test cases

Have some code that you would like unit tested? Cursor is very good at generating test cases and assertions for your code. The fewer barriers there are to testing a piece of code, the better the result you will get. So, try your best to write code that is easily testable! If testing the code requires some mocks or other pieces to work, do your best to provide it the context and instructions it needs before writing the tests.

Always review the test cases! There could be errors or test cases that don’t make sense. Most of the time, it will get you pretty close to where you want to be.

Here’s an example of using the Agent mode to install packages for testing and generate unit tests for the tic-tac-toe game logic:

Generating documentation

This is another thing we know AI models are good at - summarizing large chunks of information. Make sure it has the context of whatever you want to document.

This one, in particular, is really great because historically, keeping documentation up to date is a rare and challenging practice.

Here’s an example of using the Agent mode to generate documentation for the tic-tac-toe game:

Code review

There are a lot of up-and-coming tools outside of Cursor that can handle this. For example, GitHub now has Copilot integrated in pull requests for code reviews. It’s never a bad idea to have whatever change set you’re looking to commit reviewed and inspected before pushing it up to the remote, though. You can provide your unstaged changes or even specific commits as context to a Cursor Ask or Agent prompt.

Getting up to speed in a new code base

Being able to query a codebase with the power of LLM’s is truly fantastic. It can be a great help to get up to speed in a large new codebase quickly.

Some example prompts:

Please provide an overview of this project and how to get started developing with it

I need to make some changes to the way that notifications are grouped in the UI, please provide a detailed analysis and pseudo code outlining how the grouping algorithm works

If you have a question about the code base, ask Cursor!

Refactoring

Refactoring code in a code base is a much quicker process in Cursor. You can execute refactors depending on their scope in a couple of distinct ways.

For refactors that don’t span a lot of files or are less complex, you can probably get away with just using the autocomplete. For example, if you make a change to something in a file and there are several instances of the same pattern following, the autocomplete will quickly pick up on this and help you tab through the changes. If you switch to another file, this information will still be in context and can be continued most of the time.

For larger refactors spanning several files, using the Agent feature will most likely be the quickest way to get it done.

Add all the files you plan to make changes to the Agent tab’s context window.

Provide specific instructions and/or a basic example of how to execute the refactor.

Let the Agent work, if it doesn’t get it exactly right initially, you can always give it corrections in a follow-up prompt.

Generating new code/features

This is the big promise of AI agents and the one with the most room for mixed results. My main recommendation here is to keep experimenting. Keep learning to prompt more effectively, compare results from different models, and pay attention to the results you get from each use case.

I personally get the best results building new features in small, focused chunks of work. It can also be helpful to have a dialog with the Ask feature first to plan out the feature's details that the Agent can follow up on and implement.

If there are existing patterns in your codebase for accomplishing certain things, provide this information in your prompts and make sure to add the relevant code to the context. For example, if you’re adding a new form to the web page and you have other similar forms that handle validation and making back-end calls in the same way, Cursor can base the code for the new feature on this.

Example prompt: Generate a form for creating a new post, follow similar patterns from the create user profile form, and look to the post schema for the fields that should be included.

Remember that you can always follow up with additional prompts if you aren’t quite happy with the results of the first.. If the results are close but need to be adjusted in some way, let the agent know in the next prompt.

You may find that for some things, it just doesn’t do well yet. Mentally note these things and try to get to a place where you can intuit when to reach for the Agent feature or just write some of the code the old-fashioned way.

Tips and tricks

The more you use Cursor, the more you will find little ways to get more out of it. Here are some of the tips and patterns that I find particularly useful in my day-to-day work.

Generating UI with screenshots

You can attach images to your prompts that the models can understand using computer vision. To the left of the send button, there is a little button to attach an image from your computer.

This functionality is incredibly useful for generating UI code, whether you are giving it an example UI as a reference for generating new UI in your application or providing a screenshot of existing UI in your application and prompting it to change details in reference to the image.

Cursor Rules

Cursor Rules allow you to add additional information that the LLM models might need to provide the best possible experience in your codebase. You can create global rules as well as project-specific ones.

An example use case is if your project has some updated dependency with newer APIs than the one on which the LLM has been trained. I ran into this when adding Tailwind v4 to a project; the models are always generating code based on Tailwind v3 or earlier.

Here’s how we can add a rules file to handle this use case:

Path: .cursor/rules/tailwind.mdc

Rule Type: Agent Requested

Description: When generating CSS using Tailwind utility classes

Access CSS variables in Tailwind CSS using the text(--var-name) syntax and not the previous text-[var(--var-name)] syntax

If you want to see some more examples, check out the awesome-cursorrules repository.

Summary

Learn to use Cursor and similar tools to enhance your development process. It may not give you actual superpowers, but it may feel like it. All the features and tools we’ve covered in this post come together to provide an amazing experience for developing all types of software and applications.

Internationalization (i18n) is essential for providing a multi-language experience for global applications. next-intl integrates well with Next.js’ App Router, handling i18n routing, locale detection, and dynamic configuration. This guide will walk you through setting up i18n in Next.js using next-intl for URL-based routing, user-specific settings, and domain-based locale routing.

Getting Started

First, create a Next.js app with the App Router and install next-intl:

npm install next-intl

Next, configure next-intl in the next.config.ts file to provide a request-specific i18n configuration for Server Components:

import type { NextConfig } from 'next';
import createNextIntlPlugin from 'next-intl/plugin';

const withNextIntl = createNextIntlPlugin();

const nextConfig: NextConfig = {
  /* config options here */
};

export default withNextIntl(nextConfig);

Without i18n Routing

Setting up an app without i18n routing integration can be advantageous in scenarios where you want to provide a locale to next-intl based on user-specific settings or when your app supports only a single language. This approach offers the simplest way to begin using next-intl, as it requires no changes to your app’s structure, making it an ideal choice for straightforward implementations.

├── translations
│   ├── en.json
│   └── es.json
├── next.config.ts
└── src
    ├── i18n
    │   └── request.ts
    └── app
        ├── layout.tsx
        └── page.tsx

Here’s a quick explanation of each file's role:

• translations/: Stores different translations per language (e.g., en.json for English, es.json for Spanish). Organize this as needed, e.g., translations/en/common.json.
• request.ts: Manages locale-based configuration scoped to each request.

Setup request.ts for Request-Specific Configuration

Since we will be using features from next-intl in Server Components, we need to add the following configuration in i18n/request.ts:

import { getRequestConfig } from 'next-intl/server';

export default getRequestConfig(async () => {
  const locale = 'en';

  return {
    locale,
    messages: (await import(`../../translations/${locale}.json`)).default,
  };
});

Here, we define a static locale and use that to determine which translation file to import. The imported JSON data is stored in the message variable, and is returned together with the locale so that we can access them from various components in the application.

Using Translation in RootLayout

Inside RootLayout, we use getLocale() to retrieve the static locale and set the document language for SEO and pass translations to NextIntlClientProvider:

import { NextIntlClientProvider } from 'next-intl';
import { getLocale, getMessages } from 'next-intl/server';

export default async function RootLayout({ children }: { children: React.ReactNode }) {
  const locale = await getLocale();
  const messages = await getMessages();

  return (
    <html lang={locale}>
      <body>
        <NextIntlClientProvider messages={messages}>{children}</NextIntlClientProvider>
      </body>
    </html>
  );
}

Note that NextIntlClientProvider automatically inherits configuration from i18n/request.ts here, but messages must be explicitly passed.

Now you can use translations and other functionality from next-intl in your components:

import { useTranslations } from 'next-intl';
import { Link } from '@/i18n/routing';

export default function HomePage() {
  const t = useTranslations('HomePage');
  return (
    <div>
      <h1>{t('title')}</h1>
      <Link href="/about">{t('about')}</Link>
    </div>
  );
}

In case of async components, you can use the awaitable getTranslations function instead:

import { getTranslations } from 'next-intl/server';
import { Link } from '@/i18n/routing';

export default async function HomePage() {
  const t = await getTranslations('HomePage');
  return (
    <div>
      <h1>{t('title')}</h1>
      <Link href="/about">{t('about')}</Link>
    </div>
  );
}

And with that, you have i18n configured and working on your application!
Now, let’s take it a step further by introducing routing. \

With i18n Routing

To set up i18n routing, we need a file structure that separates each language configuration and translation file. Below is the recommended structure:

├── translations
│   ├── en.json
│   └── es.json
├── next.config.ts
└── src
    ├── i18n
    │   ├── routing.ts
    │   └── request.ts
    ├── middleware.ts
    └── app
        └── [locale]
            ├── layout.tsx
            └── page.tsx

We updated the earlier structure to include some files that we require for routing:

• routing.ts: Sets up locales, default language, and routing, shared between middleware and navigation.
• middleware.ts: Handles URL rewrites and locale negotiation.
• app/[locale]/: Creates dynamic routes for each locale like /en/about and /es/about.

Define Routing Configuration in i18n/routing.ts

The routing.ts file configures supported locales and the default locale, which is referenced by middleware.ts and other navigation functions:

import { defineRouting } from 'next-intl/routing';
import { createNavigation } from 'next-intl/navigation';

export const routing = defineRouting({
  locales: ['en', 'es'], // Supported locales
  defaultLocale: 'en',    // Fallback locale if none matches
});

// Provides wrappers for Next.js navigation APIs to handle locale routing
export const { Link, redirect, usePathname, useRouter } = createNavigation(routing);

This configuration lets Next.js handle URL paths like /about, with locale management managed by next-intl.

Update request.ts for Request-Specific Configuration

We need to update the getRequestConfig function from the above implementation in i18n/request.ts.

import { getRequestConfig } from 'next-intl/server';
import { routing } from './routing';

export default getRequestConfig(async ({ requestLocale }) => {
  let locale = await requestLocale;

  if (!locale || !routing.locales.includes(locale as any)) {
    locale = routing.defaultLocale;
  }

  return {
    locale,
    messages: (await import(`../../translations/${locale}.json`)).default,
  };
});

Here, request.ts ensures that each request loads the correct translation files based on the user’s locale or falls back to the default.

Setup Middleware for Locale Matching

The middleware.ts file matches the locale based on the request:

import createMiddleware from 'next-intl/middleware';
import { routing } from './i18n/routing';

export default createMiddleware(routing);

export const config = {
  matcher: ['/', '/(es|en)/:path*'], // Matches i18n paths only
};

Middleware handles locale matches and redirects to localized paths like /en or /es.

Updating the RootLayout file

Inside RootLayout, we use the locale from params (matched by middleware) instead of calling getLocale()

import { NextIntlClientProvider } from 'next-intl';
import { getMessages } from 'next-intl/server';
import { notFound } from 'next/navigation';
import { routing } from '@/i18n/routing';
import '../globals.css';

export default async function RootLayout({
  children,
  params,
}: {
  children: React.ReactNode;
  params: { locale: string };
}) {
  const { locale } = params;

  if (!routing.locales.includes(locale as any)) {
    notFound();
  }

  const messages = await getMessages();

  return (
    <html lang={locale}>
      <body>
        <NextIntlClientProvider messages={messages}>{children}</NextIntlClientProvider>
      </body>
    </html>
  );
}

The locale we get from the params was matched in the middleware.ts file and we use that here to set the document language for SEO purposes. Additionally, we used this file to pass configuration from i18n/request.ts to Client Components through NextIntlClientProvider.

Note: When using the above setup with i18n routing, next-intl will currently opt into dynamic rendering when APIs like useTranslations are used in Server Components. next-intl provides a temporary API that can be used to enable static rendering.

Static Rendering for i18n Routes

For apps with dynamic routes, use generateStaticParams to pass all possible locale values, allowing Next.js to render at build time:

import { routing } from '@/i18n/routing';

export function generateStaticParams() {
  return routing.locales.map((locale) => ({ locale }));
}

next-intl provides an API setRequestLocale that can be used to distribute the locale that is received via params in layouts and pages for usage in all Server Components that are rendered as part of the request. You need to call this function in every layout/page that you intend to enable static rendering for since Next.js can render layouts and pages independently.

import { setRequestLocale } from 'next-intl/server';
import { notFound } from 'next/navigation';
import { routing } from '@/i18n/routing';

export default async function RootLayout({ children, params: { locale } }) {
  if (!routing.locales.includes(locale as any)) {
    notFound();
  }

  setRequestLocale(locale);

  return (
    // ...
  );
}

Note: Call setRequestLocale before invoking useTranslations or getMessages or any next-intl functions.

Domain Routing

For domain-specific locale support, use the domains setting to map domains to locales, such as us.example.com/en or ca.example.com/fr.

import { defineRouting } from 'next-intl/routing';

export const routing = defineRouting({
  locales: ['en', 'fr'],
  defaultLocale: 'en',
  domains: [
    { domain: 'us.example.com', defaultLocale: 'en', locales: ['en'] },
    { domain: 'ca.example.com', defaultLocale: 'en' },
  ],
});

This setup allows you to serve localized content based on domains. Read more on domain routing here.

Conclusion

Setting up internationalization in Next.js with next-intl provides a modular way to handle URL-based routing, user-defined locales, and domain-specific configurations. Whether you need URL-based routing or a straightforward single-locale setup, next-intl adapts to fit diverse i18n needs.

With these tools, your app will be ready to deliver a seamless multi-language experience to users worldwide.

As Director of Engineering at Spot AI—a company building video intelligence software—Kelly recently expanded her role to oversee both Product and Engineering for their VMS offering. That shift means juggling strategy, execution, and team development, all while helping others step confidently into leadership themselves.

And yes, she still finds time to speak at conferences and answer DMs from people navigating the same transitions she once did.

We spoke with Kelly about spotting leadership potential early, why ambiguity doesn’t have to feel chaotic, and the lesson she learned the hard way about managing up.

Stepping into Product Leadership

Kelly’s new title might look like a promotion on paper, but the shift is more philosophical than anything.

“Engineering leadership is about execution,” she says. “Product leadership is about defining why we’re building something in the first place.”

Now leading Product and Engineering for Spot AI’s VMS product, she’s talking to customers, researching market trends, and making smart bets on where to invest next.

It’s a role she’s clearly energized by.

“I’m really looking forward to dedicating time to shaping our product’s future.”

Thriving in Ambiguity

Some people panic when problems are fuzzy or undefined. Others use it as fuel.

“There are two key traits I see in people who handle ambiguity well,” Kelly says. “They stay calm under stress, and they know how to form a hypothesis from a vague problem statement.”

That means asking the right questions, taking action quickly, and being totally okay with pivoting when something doesn’t pan out.

It’s no surprise that these same traits overlap with great product thinking—a mindset she’s now leaning into more than ever.

“I do some of my best work when navigating uncertainty,” she adds.

Read Kelly’s blog on embracing ambiguity in Product!

Creating Leadership Pathways for Women in Tech

When asked how leaders can create more leadership pathways for women in software engineering, Kelly stressed that it is not a passive process.

“Senior leaders need to be proactive,” Kelly says. “That starts with identifying and addressing bias across hiring, promotions, and day-to-day interactions.”

She emphasizes psychological safety—so women feel confident advocating for themselves and others. But she also knows not everyone feels ready to raise their hand.

“Don’t wait for someone to ask for a title change or a growth opportunity. Recognize leadership behavior early. Sometimes people don’t even realize it in themselves yet.”

On Stage, In Real Life

Kelly’s no stranger to the tech conference circuit—often giving talks on engineering leadership and team growth.

Her biggest source of inspiration? Conversations with people trying to make the leap into leadership.

“I might use the same slide deck at three conferences,” she says, “but the talk itself will be different every time.”

Rather than sticking to a script, she likes to share recent examples from her own work, tailoring the delivery to the audience in front of her. It keeps things relevant, grounded, and never too polished.

Between setting product strategy, mentoring the next generation of leaders, and hopping from one tech conference to the next, Kelly Vaughn is showing what it means to lead with clarity—even when things are unclear.

She’s not here to tell you it’s easy. But she will tell you it’s worth it.

Connect with Kelly Vaughn on Bluesky.

Sign up for Kelly Vaughn’s Newsletter!

Sticker Illustration by Jacob Ashley.

Jared Palmer of Vercel recently announced an acquisition that spiked our interest. Having worked extensively with both Next.js and Vercel, as well as React Native, we were curious to see what the appointment of Fernando Rojo, the creator of Solito, as Vercel's Head of Mobile, would mean for the future of React Native and Vercel.

While we can only speculate on what the future holds, we can look closer at Solito and its current integration with Vercel. Based on the information available, we can also make some educated guesses about what the future might hold for React Native and Vercel.

What is Solito?

Based on a recent tweet by Guillermo Rauch, one might assume that Solito allows you to build mobile apps with Next.js. While that might become a reality in the future, Jamon Holmgren, the CTO of Infinite Red, added some context to the conversation. According to Jamon, Solito is a cross-platform framework built on top of two existing technologies:

• For the web, Solito leverages Next.js.
• For mobile, Solito takes advantage of Expo.

That means that, at the moment, you can't build mobile apps using Next.js & Solito only - you still need Expo and React Native. Even Jamon, however, admits that even the current integration of Solito with Vercel is exciting.

Let's take a closer look at what Solito is according to its official website:

This library is two things:

1. A tiny wrapper around React Navigation and Next.js that lets you share navigation code across platforms.

2. A set of patterns and examples for building cross-platform apps with React Native + Next.js.

We can see that Jamon was right - Solito allows you to share navigation code between Next.js and React Native and provides some patterns and components that you can use to build cross-platform apps, but it doesn't replace React Native or Expo.

The Cross-Platformness of Solito

So, we know Solito provides a way to share navigation and some patterns between Next.js and React Native. But what precisely does that entail?

Cross-Platform Hooks and Components

If you look at Solito's documentation, you'll see that it's not only navigation you can share between Next.js and React Native. There are a few components that wrap Next.js components and make them available in React Native:

• Link - a component that wraps Next.js' Link component and allows you to navigate between screens in React Native.
• TextLink - a component that also wraps Next.js' Link component but accepts text nodes as children.
• MotiLink - a component that wraps Next.js' Link component and allows you to animate the link using moti, a popular animation library for React Native.
• SolitoImage - a component that wraps Next.js' Image component and allows you to display images in React Native.

On top of that, Solito provides a few hooks that you can use for shared routing and navigation:

• useRouter() - a hook that lets you navigate between screens across platforms using URLs and Next.js Url objects.
• useLink() - a hook that lets you create Link components across the two platforms.
• createParam() - a function that returns the useParam() and useParams() hooks which allow you to access and update URL parameters across platforms.

Shared Logic

The Solito starter project is structured as a monorepo containing:

• apps/next - the Next.js application.

• apps/expo or apps/native - the React Native application.

• packages/app - shared packages across the two applications:

  • features
  • providers
  • navigation

The shared packages contain the shared logic and components you can use across the two platforms. For example, the features package contains the shared components organized by feature, the providers package contains the shared context providers, and the navigation package includes the shared navigation logic.

One of the key principles of Solito is gradual adoption, meaning that if you use Solito and follow the recommended structure and patterns, you can start with a Next.js application only and eventually add a React Native application to the mix.

Deployments

Deploying the Next.js application built on Solito is as easy as deploying any other Next.js application. You can deploy it to Vercel like any other Next.js application, e.g., by linking your GitHub repository to Vercel and setting up automatic deployments.

Deploying the React Native application built on top of Solito to Expo is a little bit more involved - you cannot directly use the Github Action recommended by Expo without some modification as Solito uses a monorepo structure.

The adjustment, however, is luckily just a one-liner. You just need to add the working-directory parameter to the eas update --auto command in the Github Action. Here's what the modified part of the Expo Github Action would look like:

### the beginning of the Github action...

- name: Create preview
  uses: expo/expo-github-action/preview@v8
  with:
    command: eas update --auto
    working-directory: ./apps/expo # This needs to be added in order to work with the monorepo structure

What Does the Future Hold?

While we can't predict the future, we can make some educated guesses about what the future might hold for Solito, React Native, Expo, and Vercel, given what we know about the current state of Solito and the recent acquisition of Fernando Rojo by Vercel.

A Competitor to Expo?

One question that comes to mind is whether Vercel will work towards creating a competitor to Expo. While it's too early to tell, it's not entirely out of the question. Vercel has been expanding its offering beyond Next.js and static sites, and it's not hard to imagine that it might want to provide a more integrated, frictionless solution for building mobile apps, further bridging the gap between web and mobile development.

However, Expo is a mature and well-established platform, and building a mobile app toolchain from scratch is no trivial task. It would be easier for Vercel to build on top of Expo and partner with them to provide a more integrated solution for building mobile apps with Next.js.

Furthermore, we need to consider Vercel's target audience. Most of Vercel's customers are focused on web development with Next.js, and switching to a mobile-first approach might not be in their best interest. That being said, Vercel has been expanding its offering to cater to a broader audience, and providing a more integrated solution for building mobile apps might be a step in that direction.

A Cross-Platform Framework for Mobile Apps with Next.js?

Imagine a future where you write your entire application in Next.js — using its routing, file structure, and dev tools — and still produce native mobile apps for iOS and Android.

It's unlikely such functionality would be built from scratch. It would likely still rely on React Native + Expo to handle the actual native modules, build processes, and distribution. From the developer’s point of view, however, it would still feel like writing Next.js.

While this idea sounds exciting, it's not likely to happen in the near future. Building a cross-platform framework that allows you to build mobile apps with Next.js only would require a lot of work and coordination between Vercel, Expo, and the React Native community. Furthermore, there are some conceptual differences between Next.js and React Native that would need to be addressed, such as Next.js being primarily SSR-oriented and native mobile apps running on the client.

Vercel Building on Top of Solito?

One of the more likely scenarios is that Vercel will build on top of Solito to provide a more integrated solution for building mobile apps with Next.js. This could involve providing more components, hooks, and patterns for building cross-platform apps, as well as improving the deployment process for React Native applications built on top of Solito.

A potential partnership between Vercel and Expo, or at least some kind of closer integration, could also be in the cards in this scenario. While Expo already provides a robust infrastructure for building mobile apps, Vercel could provide complementary services or features that make it easier to build mobile apps on top of Solito.

Conclusion

Some news regarding Vercel and mobile development is very likely on the horizon. After all, Guillermo Rauch, the CEO of Vercel, has himself stated that Vercel will keep raising the quality bar of the mobile and web ecosystems.

While it's unlikely we'll see a full-fledged mobile app framework built on top of Next.js or a direct competitor to Expo in the near future, it's not hard to imagine that Vercel will provide more tools and services for building mobile apps with Next.js. Solito is a step in that direction, and it's exciting to see what the future holds for mobile development with Vercel.

Vercel, however, is a serverless platform, which means there are a few things you need to be aware of to keep your costs predictable and under control. This blog post covers the most important aspects of hosting a Next.js app on Vercel.

Vercel's Pricing Structure

Vercel's pricing structure is based on fixed and usage-based pricing, which is implemented through two big components of Vercel: the Developer Experience Platform (DX Platform) and the Managed Infrastructure.

The DX Platform offers a monthly-billed suite of tools and services focused on building, deploying, and optimizing web apps. Think of it as the developer-focused interface on Vercel, which assists you in managing your app and provides team collaboration tools, deployment infrastructure, security, and administrative services. Additionally, it includes Vercel support. Because the DX Platform is developer-focused, it's also charged per seat on a monthly basis. The more developers have access to the DX Platform, the more you're charged. In addition to charging per seat, there are also optional, fixed charges for non-included, extra features. Observability Plus is one such example feature.

The Managed Infrastructure, on the other hand, is what makes your app run and scale. It is a serverless platform priced per usage. Thanks to this infrastructure, you don't need to worry about provisioning, maintaining, or patching your servers. Everything is executed through serverless functions, which can scale up and down as needed. Although this sounds great, this is also one of the reasons many developers hesitate to adopt serverless; it may have unpredictable costs. One day, your site sees minimal traffic, and the next, it goes viral on Hacker News, leading to a sudden spike in costs.

Vercel addresses this uncertainty by including a set amount of free serverless usage in each of its DX Platform plans. Once you exceed those limits, additional charges apply based on usage.

Pricing Plans

The DX Platform can be used in three different pricing plans on a team level. A team can represent a single person, a team within a company, or even a whole company. When creating a team on Vercel, this team can have one or more projects.

The first of the three pricing plans is the Hobby plan, which is ideal for personal projects and experimentation. The Hobby plan is free and comes with some of the features and resources of the DX Platform and Managed Infrastructure out of the box, making it suitable for hosting small websites. However, note that the Hobby plan is limited to non-commercial, personal use only.

The Pro plan is the most recommended for most teams and can be used for commercial purposes. At the time of this writing, it costs $20 per team member and comes with generous resources that support most teams.

The third tier is the Enterprise plan, which is the most advanced and expensive option. This plan becomes necessary when your application requires specific compliance or performance features, such as isolated build infrastructure, Single Sign-On (SSO) for corporate user management or custom support with Service-Level Agreements. The Enterprise plan has a custom pricing model and is negotiated directly with Vercel.

What Contributes to Usage Costs and Limiting Them

Now that you've selected a plan for your team, you're ready to deploy Next.js. But how do you determine what contributes to your per-usage costs and ensure they stay within your plan limits?

The Vercel pricing page has a detailed breakdown of the resource usage limits for each plan, which can help you understand what affects your costs. However, in this section, we've highlighted some of the most impactful factors on pricing that we've seen on many of our client projects.

Number of Function Invocations

Each time a serverless function runs, it counts as an invocation. Most of the processing on Vercel for your Next.js apps happens through serverless functions. Some might think that only API endpoints or server actions count as serverless function invocations, but this is not true. Every request that comes to the backend goes through a serverless function invocation, which includes:

• Invoking server actions (server functions)
• Invoking API routes (from the frontend, another system, or even within another serverless function)
• Rendering a React server component tree (as part of a request to display a page)

To give you an idea of the number of invocations included in a plan, the Pro plan includes 1 million invocations per month for free. After that, it costs $0.60 per million, which can total a significant amount for popular websites.

To minimize serverless function invocations, focus on reducing any of the above points. For example:

• Batch up server actions: If you have multiple server actions, such as downloading a file and increasing its download count, you can combine them into one server action.
• Minimize calls to the backend: Closely related to the previous point, unoptimized client components can call the backend more than they need to, contributing to increased function invocation count. If needed, consider using a library such as useSwr or TanStack Query to keep your backend calls under control.
• Use API routes correctly: Next.js recommends using API routes for external systems invoking your app. For instance, Contentful can invoke a blog post through a webhook without incurring additional invocations. However, avoid invoking API routes from server component tree renders, as this counts as at least two invocations.

Reducing React server component renders is also possible. Not all pages need to be dynamic - convert dynamic routes to static content when you don’t expect them to change in real-time. On the client, utilize Next.js navigation primitives to use the client-side router cache.

Middleware in Next.js runs before every request. Although this doesn't necessarily count as a function invocation (for edge middleware, this is counted in a separate bucket), it's a good idea to minimize the number of times it has to run. To minimize middleware invocations, limit them only to requests that require it, such as protected routes. For static asset requests, you can skip middleware altogether using matchers. For example, the matcher configuration below would prevent invoking the middleware for most static assets:

export const config = {
  matcher: [
    /*
     * Match all request paths except for the ones starting with:
     * - api (API routes)
     * - _next/static (static files)
     * - _next/image (image optimization files)
     * - favicon.ico, sitemap.xml, robots.txt (metadata files)
     */
    '/((?!api|_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)',
  ],
}

Function Execution Time

The duration your serverless function takes to execute counts as the execution time, and it impacts your end bill unless it's within the limits of your plan. This means that any inefficient code that takes longer to execute directly adds up to the total function invocation time.

Many things can contribute to this, but one common pattern we've seen is not utilizing caching properly or under-caching. Next.js offers several caching techniques you can use, such as:

• Using a data cache to prevent unnecessary database calls or API calls
• Using memoization to prevent too many API or database calls in the same rendering pass

Another reason, especially now in the age of AI APIs, is having a function run too long due to AI processing. In this case, what we could do is utilize some sort of queuing for long-processing jobs, or enable Fluid Compute, a recent feature by Vercel that optimizes function invocations and reusability.

Bandwidth Usage

The volume of data transferred between users and Vercel, including JavaScript bundles, RSC payload, API responses, and assets, directly contributes to bandwidth usage. In the Pro plan, you receive 1 TB/month of included bandwidth, which may seem substantial but can quickly be consumed by large Next.js apps with:

• Large JavaScript bundles
• Many images
• Large API JSON payloads

Image optimization is crucial for reducing bandwidth usage, as images are typically large assets. By implementing image optimization, you can significantly reduce the amount of data transferred.

To further optimize your bandwidth usage, focus on using the Link component efficiently. This component performs automatic prefetch of content, which can be beneficial for frequently accessed pages. However, you may want to disable this feature for infrequently accessed pages.

The Link component also plays a role in reducing bandwidth usage, as it aids in client-side navigation. When a page is cached client-side, no request is made when the user navigates to it, resulting in reduced bandwidth usage.

Additionally, API and RSC payload responses count towards bandwidth usage. To minimize this impact, always return only the minimum amount of data necessary to the end user.

Image Transformations

Every time Vercel transforms an image from an unoptimized image, this counts as an image transformation. After transformation, every time an optimized image is written to Vercel's CDN network and then read by the user's browser, this counts as an image cache read and an image cache write, respectively.

The Pro plan includes 10k transformations per month, 600k CDN cache reads, and 200k CDN cache writes. Given the high volume of image requests in many apps, it's worth checking if the associated costs can be reduced.

Firstly, not every image needs to be transformed. Certain types of images, such as logos and icons, small UI elements (e.g., button graphics), vector graphics, and other pre-optimized images you may have optimized yourself already, don't require transformation. You can store these images in the public folder and use the unoptimized property with the Image component to mark them as non-transformable.

Another approach is to utilize an external image provider like Cloudinary or AWS CloudFront, which may have already optimized the images. In this case, you can use a custom image loader to take advantage of their optimizations and avoid Vercel's image transformations.

Finally, Next.js provides several configuration options to fine-tune image transformation:

• images.minimumCacheTTL: Controls the cache duration, reducing the need for rewritten images.
• images.formats: Allows you to limit eligible image formats for transformation.
• images.remotePatterns: Defines external sources for image transformation, giving you more control over what's optimized.
• images.quality: Enables you to set the image quality for transformed images, potentially reducing bandwidth usage.

Monitoring

The "Usage" tab on the team page in Vercel provides a clear view of your team's resource usage. It includes information such as function invocation counts, function durations, and fast origin transfer amounts. You can easily see how far you are from reaching your team's limit, and if you're approaching it, you'll see the amount. This page is a great way to monitor regularity.

However, you don't need to check it constantly. Vercel offers various aspects of spending management, and you can set alert thresholds to get notified when you're close to or exceed your limit. This helps you proactively manage your spending and avoid unexpected charges.

One good feature of Vercel is its ability to pause projects when your spending reaches a certain point, acting as an "emergency break" in the case of a DDoS attack or a very unusual spike in traffic. However, this will stop the production deployment, and the users will not be able to use your site, but at least you won't be charged for any extra usage. This option is enabled by default.

Conclusion

Hosting a Next.js app on Vercel offers a great developer experience, but it's also important to consider how this contributes to your end bill and keep it under control. Hopefully, this blog post will clear up some of the confusion around pricing and how to plan, optimize, and monitor your costs.

We hope you enjoyed this blog post. Be sure to check out our other blog posts on Next.js for more in-depth coverage of different features of this framework.

As the VP of Developer Relations at Block, she facilitates developer training and enablement, delivering tools for developer users and open source contributors. However, her educational work doesn’t end with her day job. She is also a contributor to multiple books examining the intersection of technology and career, including DevOps: Implementing Cultural Change, and 97 Things Every Java Programmer Should Know, and is an active speaker in the global developer conference circuit.

With the release of Block’s new open source AI agent “goose”, Angie drives conversations around AI’s role in developer productivity, ethical practices, and the application of intelligent tooling. We had the chance to talk with her about the evolution of DevRel, what makes a great leader, emergent data governance practices, women who are crushing it right now in the industry, and more:

Developer Advocacy is Mainstream

A decade ago, Developer Relations (DevRel) wasn’t the established field it is today. It was often called Developer Evangelism, and fewer companies saw the value in having engineers speak directly to other engineers.

“Developer Relations was more of a niche space. It’s become much more mainstream these days with pretty much every developer-focused company realizing that the best way to reach developers is with their peers.”

That shift has opened up more opportunities for engineers who enjoy teaching, community-building, and breaking down complex technical concepts. But because DevRel straddles multiple functions, its place within an organization remains up for debate—should it sit within Engineering, Product, Marketing, or even its own department? There’s no single answer, but its cross-functional nature makes it a crucial bridge between technical teams and the developers they serve.

Leadership Is Not an Extension of Engineering Excellence

Most engineers assume that excelling as an IC is enough to prepare them for leadership, but Angie warns that this is a common misconception.

She’s seen firsthand how technical skills don’t always equate to strong leadership abilities—we’ve all worked under leaders who made us wonder how they got there. When she was promoted into leadership, Angie was determined not to become one of those leaders:

“This required humility. Acknowledging that while I was an expert in one area, I was a novice in another.”

Instead of assuming leadership would come naturally, she took a deliberate approach to learning—taking courses, reading books, and working with executive coaches to build leadership skills the right way.

Goose: An Open Source AI Assistant That Works for You

At Block, Angie is working on a tool called goose, an open-source AI agent that runs locally on your machine. Unlike many AI assistants that are locked into specific platforms, goose is designed to be fully customizable:

“You can use your LLM of choice and integrate it with any API through the Model Context Protocol (MCP).”

That flexibility means goose can be tailored to fit developers’ workflows. Angie gives an example of what this looks like in action:

“Goose, take this Figma file and build out all of the components for it. Check them into a new GitHub repo called @org/design-components and send a message to the #design channel in Slack informing them of the changes.”

And just like that, it’s done— no manual intervention required.

The Future of Data Governance

As AI adoption accelerates, data governance has become a top priority for companies. Strong governance requires clear policies, security measures, and accountability. Angie points out that organizations are already making moves in this space:

“Cisco recently launched a product called AI Defense to help organizations enhance their data governance frameworks and ensure that AI deployments align with established data policies and compliance requirements.”

According to Angie, in the next five years, we can expect more structured frameworks around AI data usage, especially as businesses navigate privacy concerns and regulatory compliance.

Bias in AI Career Tools: Helping or Hurting?

AI-powered resume screeners and promotion predictors are becoming more common in hiring, but are they helping or hurting underrepresented groups? Angie’s own experience with AI bias was eye-opening:

“I use ChatGPT every day. It knows me pretty well. I asked it to draw a picture of what it thinks my current life looks like, and it drew me as a white male (with a man bun).”

When she called it out, the AI responded:

“No, I don’t picture you that way at all, but it sounds like the illustration might’ve leaned into the tech stereotype aesthetic a little too much.”

This illustrates a bigger problem— AI often reflects human biases at scale. However, there are emerging solutions, such as identity masking, which removes names, race, and gender markers so that only skills are evaluated.

“In scenarios like this, minorities are given a fairer shot.”

It’s a step toward a more equitable hiring process, but it also surfaces the need for constant vigilance in AI development to prevent harmful biases.

Women at the Forefront of AI Innovation

While AI is reshaping nearly every industry, women are playing a leading role in its development. Angie highlights several technologists:

“I’m so proud to see women are already at the forefront of AI innovation. I see amazing women leading AI research, training, and development such as Mira Murati, Timnit Gebru, Joelle Pineau, Meredith Whittaker, and even Block’s own VP of Data & AI, Jackie Brosamer.”

These women are influencing not just the technical advancements in AI but also the ethical considerations that come with it.

Connect with Angie

Angie Jones is an undeniable pillar of the online JavaScript community, and it isn’t hard to connect with her!

You can find Angie on X (Twitter), Linkedin, or on her personal site (where you can also access her free Linkedin Courses).

Learn more about goose by Block.

Sticker Illustration by Jacob Ashley

In the three years since graduating from a university program in Business Administration, she biked across the U.S., studied Kung Fu in China, learned Mandarin just for fun, and completed the #100DaysOfCode challenge after deciding she wanted a career switch.

That same sense of curiosity and willingness to jump into the unknown now fuels her work as a Developer Advocate at Pieces, where she leads product launches, mentors job seekers, and helps developers learn how to best leverage Pieces’ Long-Term Memory Agent.

Her journey into tech was guided not just by a want to learn how to code and break into the industry, but by a fascination with the structure of language itself.

“There are so many parallels between human languages and programming languages,” she says. “That realization really made me fall in love with software.”

We spoke with Ellie about launching a #1 Product Hunt release, her predictions for AI agents, and why conferences don’t have to break your budget.

Launching LTM-2 to the Top of Product Hunt

Recently, Ellie led the launch of Pieces’ Long-Term Memory Agent (LTM-2), which took the top spot on Product Hunt—a major win for the team and their community.

“I’m super competitive,” she admits. “So I really wanted us to win.”

The launch was fully organic—no paid promotions, just coordinated team efforts, a well-prepared content pipeline, and an ambassador program that brought in authentic engagement across X, Discord, and Reddit.

She documented their entire strategy in this blog post, and credits the success not just to good planning but to a passionate developer community that believed in the product.

Following a successful performance at Product Hunt, Ellie is committed to keeping Pieces’ user community engaged and contributing to its technological ecosystem.

“Although I’m still fairly new to DevRel (coming up on a year at Pieces!), I think success comes down to a few things: developer adoption and retention, user feedback, community engagement, and maintaining communication with engineering.”

Why AI Agents Are the Next Big Thing

Ellie sees a major shift on the horizon: AI that doesn’t wait for a prompt.

“The biggest trend of 2025 seems to be AI agents,” she explains, “or AI that acts proactively instead of reactively.”

Until now, most of us have had to tell AI exactly what to do—whether that’s drafting emails, debugging code, or generating images.

But Ellie imagines a near future where AI tools act more like intelligent teammates than assistants—running locally, deeply personalized, and working in the background to handle the repetitive stuff.

“Imagine something that knows how you work and quietly handles your busy work while you focus on the creative parts,” she says. “It sounds a little dystopian, but also kind of amazing.”

Whether we hit that level of autonomy in 2025 or (likely) have to wait until 2026, she believes the move toward agentic AI is inevitable—and it’s changing how developers think about productivity, ownership, and trust.

You can read more of Ellie’s 2025 LLM predictions here!

The Secret to Free Conferences (and Winning the GitHub Claw Machine)

Ellie will be the first to tell you: attending a tech conference can be a total game-changer.

“Attending my first tech conference completely changed my career trajectory,” she says. “It honestly changed my life.”

And the best part? You might not even need to pay for a ticket.

“Most conferences offer scholarship tickets,” Ellie explains. “And if you’re active in dev communities, there are always giveaways. You just have to know where to look.”

In her early days of job hunting, Ellie made it to multiple conferences for free (minus travel and lodging)—which she recommends to anyone trying to break into tech.

Also, she lives for conference swag. One of her all-time favorite moments? Winning a GitHub Octocat from the claw machine at RenderATL.

“She’s one of my prized possessions,” Ellie laughs. Proof here. 🐙

Her advice: if you’re even a little curious about going to a conference—go. Show up. Say hi to someone new. You never know what connection might shape your next step.

Ellie’s Journeys Away from her Desk

Earlier this year, Ellie took a break from product launches and developer events to visit China for Chinese New Year with her boyfriend’s family—and turned the trip into a mix of sightseeing, food adventures, and a personal mission: document every cat she met. (You can follow the full feline thread here 🐱)

The trip took them through Beijing, Nanjing, Taiyuan, Yuci, Zhùmǎdiàn, and Yangzhou, where they explored palaces, museums, and even soaked in a hot spring once reserved for emperors.

“Fancy, right?” Ellie jokes.

But the real highlight? The food.

“China has some of the best food in the world,” she says. “And lucky for me, my boyfriend’s dad is an amazing cook—every meal felt like a five-star experience.”

What’s Next?

With a YouTube series on the way, thousands of developers reached through her workshops, and an eye on the next generation of AI tooling, Ellie Zubrowski is loving her experience as a developer advocate.

Follow @elliezub on X to stay in the loop on her work, travels, tech experiments, and the occasional Octocat sighting. She’s building in public, cheering on other devs, and always down to share what she’s learning along the way.

Learn more about Pieces, the long-term LLM agent.

Sticker Illustration by Jacob Ashley

Some time ago, I wrote a post about SSR finally becoming a first-class citizen in Angular. It turns out that the Angular team really treats SSR as a priority, and they have been working tirelessly to make SSR even better.

As the previous blog post mentioned, full-page hydration was launched in Angular 16 and made stable in Angular 17, providing a great way to improve your Core Web Vitals. Another feature aimed to help you improve your INP and other Core Web Vitals was introduced in Angular 17: deferrable views. Using the @defer blocks allows you to reduce the initial bundle size and defer the loading of heavy components based on certain triggers, such as the section entering the viewport.

Then, in September 2024, the smart folks at Angular figured out that they could build upon those two features, allowing you to mark parts of your application to be server-rendered dehydrated and then hydrate them incrementally when needed - hence incremental hydration.

I’m sure you know what hydration is. In short, the server sends fully formed HTML to the client, ensuring that the user sees meaningful content as quickly as possible and once JavaScript is loaded on the client side, the framework will reconcile the rendered DOM with component logic, event handlers, and state - effectively hydrating the server-rendered content.

But what exactly does "dehydrated" mean, you might ask? Here's what will happen when you mark a part of your application to be incrementally hydrated:

1. Server-Side Rendering (SSR): The content marked for incremental hydration is rendered on the server.
2. Skipped During Client-Side Bootstrapping: The dehydrated content is not initially hydrated or bootstrapped on the client, reducing initial load time.
3. Dehydrated State: The code for the dehydrated components is excluded from the initial client-side bundle, optimizing performance.
4. Hydration Triggers: The application listens for specified hydration conditions (e.g., on interaction, on viewport), defined with a hydrate trigger in the @defer block.
5. On-Demand Hydration: Once the hydration conditions are met, Angular downloads the necessary code and hydrates the components, allowing them to become interactive without layout shifts.

How to Use Incremental Hydration

Thanks to Mark Thompson, who recently hosted a feature showcase on incremental hydration, we can show some code.

The first step is to enable incremental hydration in your Angular application's appConfig using the provideClientHydration provider function:

// app/app.config.ts
export const appConfig: ApplicationConfig = {
  providers: [provideClientHydration(withPartialHydration())],
};

Then, you can mark the components you want to be incrementally hydrated using the @defer block with a hydrate trigger:

// Trigger the @defer block immediately after non-deferred content has finished rendering
// and start hydrating once the component enters the viewport
@defer (on immediate; hydrate on viewport) {
<app-incremental-hydrated-component></app-incremental-hydrated-component>
}

And that's it! You now have a component that will be server-rendered dehydrated and hydrated incrementally when it becomes visible to the user.

But what if you want to hydrate the component on interaction or some other trigger? Or maybe you don't want to hydrate the component at all?

The same triggers already supported in @defer blocks are available for hydration:

• idle: Hydrate once the browser reaches an idle state.
• viewport: Hydrate once the component enters the viewport.
• interaction: Hydrate once the user interacts with the component through click or keydown triggers.
• hover: Hydrate once the user hovers over the component.
• immediate: Hydrate immediately when the component is rendered.
• timer: Hydrate after a specified time delay.
• when: Hydrate when a provided conditional expression is met.

And on top of that, there's a new trigger available for hydration:

• never: When used, the component will remain static and not hydrated.

The never trigger is handy when you want to exclude a component from hydration altogether, making it a completely static part of the page.

Personally, I'm very excited about this feature and can't wait to try it out. How about you?

The Department of Government Efficiency (DOGE) launched a new website, doge.gov. Within days, it was defaced with messages from hackers.

The culprit? A misconfigured database was left open, letting anyone edit content. Reports suggest the site was built on Cloudflare Pages, possibly with a Next.js frontend pulling data dynamically. While we don’t have the tech stack confirmed, we are confident that Next.js was used from early reporting around the website.

Let’s dive into what went wrong—and how you can secure your own Next.js projects.

What Happened to DOGE.gov?

The hack was a classic case of security 101 gone wrong. The database—likely hosted in the cloud—was accessible without authentication. No passwords, no API keys, no nothing. Hackers simply connected to it and started scribbling their graffiti. Hosted on Cloudflare Pages (not government servers), the site might have been rushed, skipping critical security checks. For a .gov domain, this is surprising—but it’s a reminder that even big names can miss best practices.

It’s easy to imagine how this happened: an unsecured server action is being used on the client side, a serverless function or API route fetching data from an unsecured database, no middleware enforcing access control, and a deployment that didn’t double-check cloud configs. Let’s break down how to avoid this in your own Next.js app.

Securing Your Next.js Website: 5 Key Steps

Next.js is a powerhouse for building fast, scalable websites, but its flexibility means you’re responsible for locking the doors. Here’s how to keep your site safe.

1. Double-check your Server Actions

If Next.js 13 or later was used, Server Actions might’ve been part of the mix—think form submissions or dynamic updates straight from the frontend. These are slick for handling server-side logic without a separate API, but they’re a security risk if not handled right. An unsecured Server Action could’ve been how hackers slipped into the database.

Why?

Next.js generates a public endpoint for each Server Action. If these Server Actions lack proper authentication and authorization measures, they become vulnerable to unauthorized data access.

Example:

• Restrict Access: Always validate the user’s session or token before executing sensitive operations.
• Limit Scope: Only allow Server Actions to perform specific, safe tasks—don’t let them run wild with full database access.
• Don’t use server action on the client side without authorization and authentication checks

2. Lock Down Your Database Access

Another incident happened in 2020. A hacker used an automated script to scan for misconfigured MongoDB databases, wiping the content of 23 thousand databases that have been left wide open, and leaving a ransom note behind asking for money.

So whether you’re using MongoDB, PostgreSQL, or Cloudflare’s D1, never leave it publicly accessible. Here’s what to do:

• Set Authentication: Always require credentials (username/password or API keys) to connect. Store these in environment variables (e.g., .env.local for Next.js) and access them via process.env.
• Whitelist IPs: If your database is cloud-hosted, restrict access to your Next.js app’s server or Vercel deployment IP range.
• Use VPCs: For extra security, put your database in a Virtual Private Cloud (VPC) so it’s not even exposed to the public internet. If you are using Vercel, you can create private connections between Vercel Functions and your backend cloud, like databases or other private infrastructure, using Vercel Secure Compute

Example: In a Next.js API route (/app/api/data.js):

import { MongoClient } from 'mongodb';
export default async function handler(req, res) {
  const client = new MongoClient(process.env.MONGO_URI); // Secure URI from .env

  try {
    await client.connect();
    const db = client.db('myDatabase');
    const data = await db.collection('myCollection').find().toArray();
    res.status(200).json(data);
  } catch (error) {
    res.status(500).json({ message: 'Database error' });
  } finally {
    await client.close();
  }
}

Tip: Don’t hardcode MONGO_URI—keep it in .env and add .env to .gitignore.

3. Secure Your API Routes

Next.js API routes are awesome for server-side logic, but they’re a potential entry point if left unchecked. The site might’ve had an API endpoint feeding its database updates without protection.

• Add Authentication: Use a library like next-auth or JSON Web Tokens (JWT) to secure routes.
• Rate Limit: Prevent abuse with something like rate-limiter-flexible.

Example:

import { getSession } from 'next-auth/react';

export default async function handler(req, res) {

  const session = await getSession({ req });

  if (!session) {

    return res.status(401).json({ message: 'Unauthorized' });

  }

  // Proceed with database operations

  res.status(200).json({ message: 'Secure data' });

}

4. Double-Check Your Cloud Config

A misconfigured cloud setup may have exposed the database. If you’re deploying on Vercel, Netlify, or Cloudflare:

• Environment Variables: Store secrets in your hosting platform’s dashboard, not in code.
• Serverless Functions: Ensure they’re not leaking sensitive data in responses. Log errors, not secrets.
• Access Controls: Verify your database firewall rules only allow connections from your app.

5. Sanitize and Validate Inputs

Hackers love injecting junk into forms or APIs. If your app lets users submit data (e.g., feedback forms), unvalidated inputs could’ve been a vector. In Next.js:

• Sanitize: Use libraries like sanitize-html for user inputs.
• Validate: Check data types and lengths before hitting your database.

Example:

import sanitizeHtml from 'sanitize-html';

export default async function handler(req, res) {

  if (req.method === 'POST') {
    const { input } = req.body;
    const cleanInput = sanitizeHtml(input, {
      allowedTags: [],
      allowedAttributes: {},
    });

    // Save cleanInput to database

    res.status(200).json({ message: 'Success' });

  }
}

Summary

The DOGE website hack serves as a reminder of the ever-present need for robust security measures in web development. By following the outlined steps–double-checking Server Actions, locking down database access, securing API routes, verifying cloud configurations, and sanitizing/validating inputs–you can enhance the security posture of your Next.js applications and protect them from potential threats. Remember, a proactive approach to security is always the best defense.

Usually, workflows configure Playwright to run against a project running on the GitHub action worker itself, maybe with dependencies in Docker containers as well, however, why bother setting that all up and configuring yet another environment for your app to run in when there’s a working preview right there? Not only that, the Vercel preview will be more similar to production as it’s running on the same infrastructure, allowing you to be more confident about the accuracy of your tests.

In this article, I’ll show you how you can run Playwright against the Vercel preview associated with a PR.

Setting up the Vercel Project

To set up a project in Vercel, we first need to have a codebase. I’m going to use the Next.js starter, but you can use whatever you like. What technology stack you use for this project won’t matter, as integrating Playwright with it will be the same experience.

You can create a Next.js project with the following command:

npx create-next-app@latest

If you’ve selected all of the defaults, you should be able to run npm run dev and navigate to the app at http://localhost:3000.

Setting up Playwright

We will set up Playwright the standard way and make a few small changes to the configuration and the example test so that they run against our site and not the Playwright site. Setup Playwright in our existing project by running the following command:

npm init playwright@latest

Install all browsers when prompted, and for the workflow question, say no since the one we’re going to use will work differently than the default one. The default workflow doesn’t set up a development server by default, and if that is enabled, it will run on the GitHub action virtual machine instead of against our Vercel deployment.

To make Playwright run tests against the Vercel deployment, we’ll need to define a baseUrl in playwright.config.ts and send an additional header called X-Vercel-Protection-Bypass where we'll pass the bypass secret that we generated earlier so that we don’t get blocked from making requests to the deployment. I’ll cover how to add this environment variable to GitHub later.

export default defineConfig({
    ...

  use: {
    /* Base URL to use in actions like `await page.goto('/')`. */
    baseURL: process.env.DEPLOYMENT_URL ?? "http://127.0.0.1:3000",
    extraHTTPHeaders: {
      "X-Vercel-Protection-Bypass":
        process.env.VERCEL_AUTOMATION_BYPASS_SECRET ?? "",
    },

    /* Collect trace when retrying the failed test. See https://playwright.dev/docs/trace-viewer */
    trace: "on-first-retry",
  },

    ...
}

Our GitHub workflow will set the DEPLOYMENT_URL environment variable automatically.

Now, in tests/example.spec.ts let’s rewrite the tests to work against the Next.js starter that we generated earlier:

import { test, expect } from "@playwright/test";

test("has title", async ({ page }) => {
  await page.goto("/");
  await expect(page).toHaveTitle(/Create Next App/);
});

test("has deploy button", async ({ page }) => {
  await page.goto("/");
  await expect(page.getByRole("link", { name: "Deploy now" })).toBeVisible();
});

This is similar to the default test provided by Playwright. The main difference is we’re loading pages relative to baseURL instead of Playwright’s website. With that done and your Next.js dev server running, you should be able to run npx playwright test and see 6 passing tests against your local server. Now that the boilerplate is handled let’s get to the interesting part.

The Workflow

There is a lot going on in the workflow that we’ll be using, so we’ll go through it step by step, starting from the top. At the top of the file, we name the workflow and specify when it will run.

name: E2E Tests (Playwright)

on:
  pull_request:
    branches:
      - main
  push:
    branches:
      - main

This workflow will run against new PRs against the default branch and whenever new commits are merged against it. If you only want the workflow to run against PRs, you can remove the push object.

Be careful about running workflows against your main branch if the deployment associated with it in Vercel is the production deployment. Some tests might not be safe to run against production such as destructive tests or those that modify customer data. In our simple example, however, this isn’t something to worry about.

Installing Playwright in the Virtual Machine

Workflows have jobs associated with them, and each job has multiple steps. Our test job takes a few steps to set up our project and install Playwright.

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'npm'

      - name: Install npm dependencies
        run: npm ci

      - name: Install system dependencies needed by Playwright
        run: sudo npx playwright install-deps

      - name: Install all supported Playwright browsers
        run: npx playwright install

The actions/checkout@v4 step clones our code since it isn’t available straight out of the gate. After that, we install Node v22 with actions/setup-node@v4, which, at the time of writing this article, is the latest LTS available. The latest LTS version of Node should always work with Playwright. With the project cloned and Node installed, we can install dependencies now. We run npm ci to install packages using the versions specified in the lock file.

After our JS dependencies are installed, we have to install dependencies for Playwright now. sudo npx playwright install-deps installs all system dependencies that Playwright needs to work using apt, which is the package manager used by Ubuntu. This command needs to be run as the administrative user since higher privilege is needed to install system packages. Playwright’s dependencies aren’t all available in npm because the browser engines are native code that has native library dependencies that aren’t in the registry.

Vercel Preview URL and GitHub Action Await Vercel

The next couple of steps is where the magic happens. We need two things to happen to run our tests against the deployment. First, we need the URL of the deployment we want to test. Second, we want to wait until the deployment is ready to go before we run our tests. We have written about this topic before on our blog if you want more information about this step, but we’ll reiterate some of that here.

Thankfully, the community has created GitHub actions that allow us to do this called zentered/vercel-preview-url and UnlyEd/github-action-await-vercel. Here is how you can use these actions:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
        ...

      - name: Get the Vercel preview url
        id: vercel_preview_url
        uses: zentered/vercel-preview-url@v1.4.0
        env:
          VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
        with:
          vercel_app: 'playwright-vercel-preview-demo'

      - uses: UnlyEd/github-action-await-vercel@v2.0.0
        env:
          VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
        with:
          deployment-url: ${{ format('https://{0}', steps.vercel_preview_url.outputs.preview_url) }}
          timeout: 420
          poll-interval: 15

There are a few things to take note of here. Firstly, some variables need to be set that will differ from project to project. vercel_app in the zentered/vercel-preview-url step needs to be set to the name of your project in Vercel that was created earlier.

The other variable that you need is the VERCEL_TOKEN environment variable. You can get this by going to Vercel > Account Settings > Tokens and creating a token in the form that appears. For the scope, select the account that has your project.

To put VERCEL_TOKEN into GitHub, navigate to your repo, go to Settings > Secrets and variables > Actions and add it to Repository secrets.

We should also add VERCEL_AUTOMATION_BYPASS_SECRETl. In Vercel, go to your project then navigate to Settings > Deployment Protection > Protection Bypass for Automation. From here you can add the secret, copy it to your clipboard, and put it in your GitHub action environment variables just like we did with VERCEL_TOKEN.

With the variables taken care of, let’s take a look at how these two steps work together. You will notice that the zentered/vercel-preview-url step has an ID set to vercel_preview_url. We need this so we can pass the URL we receive to the UnlyEd/github-action-await-vercel action, as it needs a URL to know which deployment to wait on.

Running Playwright

After the last steps we just added, our deployment should be ready to go, and we can run our tests! The following steps will run the Playwright tests against the deployment and save the results to GitHub:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
        ...

      - name: Run E2E tests
        run:
          npx playwright test
        env:
          DEPLOYMENT_URL: ${{ format('https://{0}', steps.vercel_preview_url.outputs.preview_url) }}
          VERCEL_AUTOMATION_BYPASS_SECRET: ${{ secrets.VERCEL_AUTOMATION_BYPASS_SECRET }}

      - name: Upload the Playwright report
        uses: actions/upload-artifact@v4
        if: always() # Always run regardless if the tests pass or fail
        with:
          name: playwright-report
          path: ${{ format('{0}/playwright-report/', github.workspace) }}
          retention-days: 30

In the first step, where we run the tests, we pass in the environment variables needed by our Playwright configuration that’s stored in playwright.config.ts. DEPLOYMENT_URL uses the Vercel deployment URL we got in an earlier step, and VERCEL_AUTOMATION_BYPASS_SECRET gets passed the secret with the same name directly from the GitHub secret store.

The second step uploads a report of how the tests did to GitHub, regardless of whether they’ve passed or failed. If you need to access these reports, you can find them in the GitHub action log. There will be a link in the last step that will allow you to download a zip file.

Once this workflow is in the default branch, it should start working for all new PRs! It’s important to note that this won’t work for forked PRs unless they are explicitly approved, as that’s a potential security hazard that can lead to secrets being leaked. You can read more about this in the GitHub documentation.

One Caveat

There’s one caveat that is worth mentioning with this approach, which is latency. Since your application is being served by Vercel and not locally on the GitHub action instance itself, there will be longer round-trips to it. This could result in your tests taking longer to execute. How much latency there is can vary based on what region your runner ends up being hosted in and whether the pages you’re loading are served from the edge or not.

Conclusion

Running your Playwright tests against Vercel preview deployments provides a robust way of running your tests against new code in an environment that more closely aligns with production. Doing this also eliminates the need to create and maintain a 2nd test environment under which your project needs to work.

Intro

Media queries have always been crucial to building web applications. They help make our apps more accessible and easier to use and ensure we reach most of our audience. Media queries have been essential in frontend development to create unique user interfaces.

But now, there’s something new: Container queries.

In this blog post, we’ll explore what Container queries are, how they differ from media queries, and why they’re so amazing.

So, let’s get started!

Refresh on Media queries

Media queries have been available in browsers for a long time, but they didn’t become popular until around 2010 when mobile devices started to take off.

Media queries let us add specific styles based on the type of device, like screens or printers. This is especially helpful for creating modern, responsive apps.

A simple use of Media queries would be changing, for example, a paragraph's font size when the screen width is less than a specific number.

p {
  font-size: 12px
}

// Media query
@media screen and (min-width: 400px) {
 p {
   font-size: 8px
 }
}

In this simple example, when the browser’s viewport width is less or equal to 400px, the font size changes to 8px.

Notice how straightforward the syntax is: we start with the keyword @media, followed by the type of device it should apply to. In this case, we use screen so it doesn’t affect users who print the page—if you don’t add anything, then it falls back to the default, which is “all” including both print and screen. Then we specify a media feature, in this case, the width.

Container queries

Container queries are similar to Media queries. Their main function is to apply styles under certain conditions. The difference is that instead of listening to the viewport of the browser, it listens to a container size. Let’s see this example:

In the above layout, we have a layout with a sidebar and three cards as the content. Using Media queries we could listen to the viewport width and change the layout depending on a specific width. Like so:

@media (max-width: 768px) {
  .layout {
    flex-direction: column;
  }

  .sidebar {
    width: 100%;
    border-right: none;
    border-bottom: 1px solid #333;
  }

  .card-inner {
    flex-direction: column;
  }

  .card-left {
    border-right: none;
    border-bottom: 1px solid #333;
  }
}

That’s acceptable, but it requires us to constantly monitor the layout. For example, if we added another sidebar on the right (really weird, but let’s imagine that this is a typical case), our layout would become more condensed:

We would need to change our media queries and adjust their range in this situation. Wouldn’t it be better to check the card container’s width and update its styles based on that? That way, we wouldn’t need to worry about if the layout changes, and that’s precisely what container queries are made for!

First, to define the container we are going to listen to, we are going to add a new property to our styles:

// cards container
.container {
  display: flex;
  flex-wrap: wrap;
  gap: 20px;
  justify-content: flex-start;
  // new property to define our container
  container-type: inline-size;
}

The .container class is the one in which our cards reside. By adding the property `container-type, ' we now define this class as a container we want to listen to. We said inline-size as the value to query based on the inline dimensions of the container because we just want to listen to the element's width.

The value of container-type will depend on your use case. If you want to listen to both width and height, then size will be a better fit for you.

You can also have normal as your container-type value, which means the element won’t act as a query container at all. This is handy if you need to revert to the default behavior.

Next, to define our query, we use the new @container CSS at-rule:

@container (max-width: 400px) {
  .card-inner {
    flex-direction: column;
  }

  .card-left {
    border-right: none;
    border-bottom: 1px solid #333;
  }
}

Notice that it is really similar to how we define our Media queries. Now, if we look at the same screen, we will see the following:

This is very powerful because we can now style each component with its own rules without changing the rules based on the layout changes.

The @container will affect all the defined containers in the scope; we might not want that. We can define the name of our container to specify that we only want to listen to that in specific:

.container {
  display: flex;
  flex-wrap: wrap;
  gap: 20px;
  justify-content: flex-start;
  container-type: inline-size;
  // New property to define the name of our container
  container-name: cards-container;
}

//We now specify which container we are listening to
@container cards-container (max-width: 400px) {
  .card-inner {
    flex-direction: column;
  }

  .card-left {
    border-right: none;
    border-bottom: 1px solid #333;
  }
}

We can also have a shorthand to define our container and its name:

.container {
  display: flex;
  flex-wrap: wrap;
  gap: 20px;
  justify-content: flex-start;
  // name of our container / its type
  container: cards-container / inline-size;
}

Container query length units

Container query lengths are similar to the viewport-percentage length units like vh or vw units, but instead of being relative to the viewport, they are to the dimensions of the query container. We have different units, each relative to different dimensions of the container:

• cqw: 1% of a query container's width
• cqh: 1% of a query container's height
• cqi: 1% of a query container's inline size
• cqb: 1% of a query container's block size
• cqmin: The smaller value of either cqi or cqb
• cqmax: The larger value of either cqi or cqb

In our example, we could use them to define the font size of our cards:

.card p {
  // Pick the maximum value.
  font-size: max(16px, 1cqi);
}

Using these units alone isn’t recommended because they’re percentage-based and can have a value we don’t want. Instead, it’s better to use a dynamic range. Using the max function, we can set 2 values and always pick the highest one.

Conclusion

Container queries bring a fresh and powerful approach to web design but are not meant to replace Media queries. I think their real power shines when used together.

Media queries often require constant adjustments as your layout evolves. Container queries, however, let you style individual components based on their dimensions, making the designs more flexible and easier to manage.

Adding a new component or rearranging elements won’t force us to rewrite our media queries. Instead, each component handles its styling, leading to cleaner and more organized code.

Please note that, as of writing this blog post, they aren’t compatible with all browsers yet. Take a look at this table from caniuse.com:

A good fallback strategy for this, when hitting an unsupported browser would be the use of the @support rule, which allows you to apply styles only if the browser supports the CSS feature. For example:

/* Fallback for browsers that don't support container queries */
@supports not (container-type: inline-size) {
  @media screen and (max-width: 1024px) {
    .card-inner {
      flex-direction: column;
    }

    .card-left {
      border-right: none;
      border-bottom: 1px solid #333;
    }
  }
}

@container cards-container (max-width: 400px) {
  .card-inner {
    flex-direction: column;
  }

  .card-left {
    border-right: none;
    border-bottom: 1px solid #333;
  }
}

Ensure your media queries are good enough to keep everything responsive and user-friendly when the condition is unmet.

Thank you for reading! Enjoy the extra flexibility that container queries bring to your web designs. Check out a live demo to see it in action. Happy styling!

In 2025, we're seeing the largest number of JavaScript build tools being actively maintained and used in history. Over the past few years, we've seen the trend of many build tools being rewritten or forked to use a faster and more efficient language like Rust and Go. In the last year, new companies have emerged, even with venture capital funding, with the goal of working on specific sets of build tools. Void Zero is one such recent example.

With so many build tools around, it can be difficult to get your head around and understand which one is for what. Hopefully, with this blog post, things will become a bit clearer. But first, let's explain some concepts.

Concepts

When it comes to build tools, there is no one-size-fits-all solution. Each tool typically focuses on one or two primary features, and often relies on other tools as dependencies to accomplish more. While it might be difficult to explain here all of the possible functionalities a build tool might have, we've attempted to explain some of the most common ones so that you can easily understand how tools compare.

Minification

The concept of minification has been in the JavaScript ecosystem for a long time, and not without reason. JavaScript is typically delivered from the server to the user's browser through a network whose speed can vary. Thus, there was a need very early in the web development era to compress the source code as much as possible while still making it executable by the browser. This is done through the process of minification, which removes unnecessary whitespace, comments, and uses shorter variable names, reducing the total size of the file.

This is what an unminified JavaScript looks like:

function greetUser(name) {
    if (name) {
        console.log("Hello, " + name + "!");
    } else {
        console.log("Hello, stranger!");
    }
}

function addNumbers(a, b) {
    return a + b;
}

console.log(greetUser("Alice"));
console.log(addNumbers(5, 7));

This is the same file, minified:

function greetUser(e){e?console.log("Hello, "+e+"!"):console.log("Hello, stranger!")}function addNumbers(e,o){return e+o}console.log(greetUser("Alice")),console.log(addNumbers(5,7));

Closely related to minimizing is the concept of source maps, which goes hand in hand with minimizing - source maps are essentially mappings between the minified file and the original source code. Why is that needed? Well, primarily for debugging minified code. Without source maps, understanding errors in minified code is nearly impossible because variable names are shortened, and all formatting is removed. With source maps, browser developer tools can help you debug minified code.

Tree-Shaking

Tree-shaking was the next-level upgrade from minification that became possible when ES modules were introduced into the JavaScript language. While a minified file is smaller than the original source code, it can still get quite large for larger apps, especially if it contains parts that are effectively not used. Tree shaking helps eliminate this by performing a static analysis of all your code, building a dependency graph of the modules and how they relate to each other, which allows the bundler to determine which exports are used and which are not. Once unused exports are found, the build tool will remove them entirely. This is also called dead code elimination.

Bundling

Development in JavaScript and TypeScript rarely involves a single file. Typically, we're talking about tens or hundreds of files, each containing a specific part of the application. If we were to deliver all those files to the browser, we would overwhelm both the browser and the network with many small requests. Bundling is the process of combining multiple JS/TS files (and often other assets like CSS, images, etc.) into one or more larger files.

A bundler will typically start with an entry file and then recursively include every module or file that the entry file depends on, before outputting one or more files containing all the necessary code to deliver to the browser. As you might expect, a bundler will typically also involve minification and tree-shaking, as explained previously, in the process to deliver only the minimum amount of code necessary for the app to function.

Transpiling

Once TypeScript arrived on the scene, it became necessary to translate it to JavaScript, as browsers did not natively understand TypeScript. Generally speaking, the purpose of a transpiler is to transform one language into another. In the JavaScript ecosystem, it's most often used to transpile TypeScript code to JavaScript, optionally targeting a specific version of JavaScript that's supported by older browsers. However, it can also be used to transpile newer JavaScript to older versions. For example, arrow functions, which are specified in ES6, are converted into regular function declarations if the target language is ES5.

Additionally, a transpiler can also be used by modern frameworks such as React to transpile JSX syntax (used in React) into plain JavaScript. Typically, with transpilers, the goal is to maintain similar abstractions in the target code. For example, transpiling TypeScript into JavaScript might preserve constructs like loops, conditionals, or function declarations that look natural in both languages.

Compiling

While a transpiler's purpose is to transform from one language to another without or with little optimization, the purpose of a compiler is to perform more extensive transformations and optimizations, or translate code from a high-level programming language into a lower-level one such as bytecode. The focus here is on optimizing for performance or resource efficiency. Unlike transpiling, compiling will often transform abstractions so that they suit the low-level representation, which can then run faster.

Hot-Module Reloading (HMR)

Hot-module reloading (HMR) is an important feature of modern build tools that drastically improves the developer experience while developing apps. In the early days of the web, whenever you'd make a change in your source code, you would need to hit that refresh button on the browser to see the change. This would become quite tedious over time, especially because with a full-page reload, you lose all the application state, such as the state of form inputs or other UI components.

With HMR, we can update modules in real-time without requiring a full-page reload, speeding up the feedback loop for any changes made by developers. Not only that, but the full application state is typically preserved, making it easier to test and iterate on code.

Development Server

When developing web applications, you need to have a locally running development server set up on something like http://localhost:3000. A development server typically serves unminified code to the browser, allowing you to easily debug your application. Additionally, a development server will typically have hot module replacement (HMR) so that you can see the results on the browser as you are developing your application.

The Tools

Now that you understand the most important features of build tools, let's take a closer look at some of the popular tools available. This is by no means a complete list, as there have been many build tools in the past that were effective and popular at the time. However, here we will focus on those used by the current popular frameworks. In the table below, you can see an overview of all the tools we'll cover, along with the features they primarily focus on and those they support secondarily or through plugins.

The tools are presented in alphabetical order below.

Babel

Babel, which celebrated its 10th anniversary since its initial release last year, is primarily a JavaScript transpiler used to convert modern JavaScript (ES6+) into backward-compatible JavaScript code that can run on older JavaScript engines. Traditionally, developers have used it to take advantage of the newer features of the JavaScript language without worrying about whether their code would run on older browsers.

esbuild

esbuild, created by Evan Wallace, the co-founder and former CTO of Figma, is primarily a bundler that advertises itself as being one of the fastest bundlers in the market. Unlike all the other tools on this list, esbuild is written in Go. When it was first released, it was unusual for a JavaScript bundler to be written in a language other than JavaScript. However, this choice has provided significant performance benefits.

esbuild supports ESM and CommonJS modules, as well as CSS, TypeScript, and JSX. Unlike traditional bundlers, esbuild creates a separate bundle for each entry point file. Nowadays, it is used by tools like Vite and frameworks such as Angular.

Metro

Unlike other build tools mentioned here, which are mostly web-focused, Metro's primary focus is React Native. It has been specifically optimized for bundling, transforming, and serving JavaScript and assets for React Native apps. Internally, it utilizes Babel as part of its transformation process. Metro is sponsored by Meta and actively maintained by the Meta team.

Oxc

The JavaScript Oxidation Compiler, or Oxc, is a collection of Rust-based tools. Although it is referred to as a compiler, it is essentially a toolchain that includes a parser, linter, formatter, transpiler, minifier, and resolver. Oxc is sponsored by Void Zero and is set to become the backbone of other Void Zero tools, like Vite.

Parcel

Feature-wise, Parcel covers a lot of ground (no pun intended). Largely created by Devon Govett, it is designed as a zero-configuration build tool that supports bundling, minification, tree-shaking, transpiling, compiling, HMR, and a development server. It can utilize all the necessary types of assets you will need, from JavaScript to HTML, CSS, and images. The core part of it is mostly written in JavaScript, with a CSS transformer written in Rust, whereas it delegates the JavaScript compilation to a SWC. Likewise, it also has a large collection of community-maintained plugins. Overall, it is a good tool for quick development without requiring extensive configuration.

Rolldown

Rolldown is the future bundler for Vite, written in Rust and built on top of Oxc, currently leveraging its parser and resolver. Inspired by Rollup (hence the name), it will provide Rollup-compatible APIs and plugin interface, but it will be more similar to esbuild in scope. Currently, it is still in heavy development and it is not ready for production, but we should definitely be hearing more about this bundler in 2025 and beyond.

Rollup

Rollup is the current bundler for Vite. Originally created by Rich Harris, the creator of Svelte, Rollup is slowly becoming a veteran (speaking in JavaScript years) compared to other build tools here. When it originally launched, it introduced novel ideas focused on ES modules and tree-shaking, at the time when Webpack as its competitor was becoming too complex due to its extensive feature set - Rollup promised a simpler way with a straightforward configuration process that is easy to understand. Rolldown, mentioned previously, is hoped to become a replacement for Rollup at some point.

Rsbuild

Rsbuild is a high-performance build tool written in Rust and built on top of Rspack. Feature-wise, it has many similiarities with Vite. Both Rsbuild and Rspack are sponsored by the Web Infrastructure Team at ByteDance, which is a division of ByteDance, the parent company of TikTok. Rsbuild is built as a high-level tool on top of Rspack that has many additional features that Rspack itself doesn't provide, such as a better development server, image compression, and type checking.

Rspack

Rspack, as the name suggests, is a Rust-based alternative to Webpack. It offers a Webpack-compatible API, which is helpful if you are familiar with setting up Webpack configurations. However, if you are not, it might have a steep learning curve. To address this, the same team that built Rspack also developed Rsbuild, which helps you achieve a lot with out-of-the-box configuration.

Under the hood, Rspack uses SWC for compiling and transpiling. Feature-wise, it’s quite robust. It includes built-in support for TypeScript, JSX, Sass, Less, CSS modules, Wasm, and more, as well as features like module federation, PostCSS, Lightning CSS, and others.

Snowpack

Snowpack was created around the same time as Vite, with both aiming to address similar needs in modern web development. Their primary focus was on faster build times and leveraging ES modules. Both Snowpack and Vite introduced a novel idea at the time: instead of bundling files while running a local development server, like traditional bundlers, they served the app unbundled. Each file was built only once and then cached indefinitely. When a file changed, only that specific file was rebuilt. For production builds, Snowpack relied on external bundlers such as Webpack, Rollup, or esbuild.

Unfortunately, Snowpack is a tool you’re likely to hear less and less about in the future. It is no longer actively developed, and Vite has become the recommended alternative.

SWC

SWC, which stands for Speedy Web Compiler, can be used for both compilation and bundling (with the help of SWCpack), although compilation is its primary feature. And it really is speedy, thanks to being written in Rust, as are many other tools on this list. Primarily advertised as an alternative to Babel, its SWC is roughly 20x faster than Babel on a single thread. SWC compiles TypeScript to JavaScript, JSX to JavaScript, and more. It is used by tools such as Parcel and Rspack and by frameworks such as Next.js, which are used for transpiling and minification.

SWCpack is the bundling part of SWC. However, active development within the SWC ecosystem is not currently a priority. The main author of SWC now works for Turbopack by Vercel, and the documentation states that SWCpack is presently not in active development.

Terser

Terser has the smallest scope compared to other tools from this list, but considering that it's used in many of those tools, it's worth separating it into its own section. Terser's primary role is minification. It is the successor to the older UglifyJS, but with better performance and ES6+ support.

Vite

Vite is a somewhat of a special beast. It's primarily a development server, but calling it just that would be an understatement, as it combines the features of a fast development server with modern build capabilities.

Vite shines in different ways depending on how it's used. During development, it provides a fast server that doesn't bundle code like traditional bundlers (e.g., Webpack). Instead, it uses native ES modules, serving them directly to the browser. Since the code isn't bundled, Vite also delivers fast HMR, so any updates you make are nearly instant.

Vite uses two bundlers under the hood. During development, it uses esbuild, which also allows it to act as a TypeScript transpiler. For each file you work on, it creates a file for the browser, allowing an easy separation between files which helps HMR. For production, it uses Rollup, which generates a single file for the browser. However, Rollup is not as fast as esbuild, so production builds can be a bit slower than you might expect. (This is why Rollup is being rewritten in Rust as Rolldown. Once complete, you'll have the same bundler for both development and production.)

Traditionally, Vite has been used for client-side apps, but with the new Environment API released in Vite 6.0, it bridges the gap between client-side and server-rendered apps.

Turbopack

Turbopack is a bundler, written in Rust by the creators of webpack and Next.js at Vercel. The idea behind Turbopack was to do a complete rewrite of Webpack from scratch and try to keep a Webpack compatible API as much as possible. This is not an easy feat, and this task is still not over.

The enormous popularity of Next.js is also helping Turbopack gain traction in the developer community. Right now, Turbopack is being used as an opt-in feature in Next.js's dev server. Production builds are not yet supported but are planned for future releases.

Webpack

And finally we arrive at Webpack, the legend among bundlers which has had a dominant position as the primary bundler for a long time. Despite the fact that there are so many alternatives to Webpack now (as we've seen in this blog post), it is still widely used, and some modern frameworks such as Next.js still have it as a default bundler. Initially released back in 2012, its development is still going strong. Its primary features are bundling, code splitting, and HMR, but other features are available as well thanks to its popular plugin system. Configuring Webpack has traditionally been challenging, and since it's written in JavaScript rather than a lower-level language like Rust, its performance lags behind compared to newer tools. As a result, many developers are gradually moving away from it.

Conclusion

With so many build tools in today's JavaScript ecosystem, many of which are similarly named, it's easy to get lost. Hopefully, this blog post was a useful overview of the tools that are most likely to continue being relevant in 2025. Although, with the speed of development, it may as well be that we will be seeing a completely different picture in 2026!

This article is aimed at those who aren’t very familiar with Laravel yet.

Prerequisites

There are many ways to set up Laravel, and which is the best method may depend on your operating system or preference. I have found Laravel Herd to be very easy to use if you’re using Windows or macOS. Herd is a Laravel development environment that has everything you need with minimal configuration required. Command-line tools are installed and added to your path, and background services are configured automatically.

If you’re developing on Linux then Herd is not an option. However, Laravel Sail works for all major operating systems and uses a Docker based environment instead. You can find a full list of supported installation methods in the Laravel documentation. To keep things simpl,e this article assumes the use of Herd, though this won’t make a difference when it comes to implementation.

You will also need a text editor or IDE that has good PHP support. PhpStorm is a great editor that works great with Laravel, but you can also use VSCode with the Phpactor language server, and I’ve found Phpactor to work quite well.

Project Setup

With a development environment setup, you can create a new Laravel project using composer, which is the most popular package manager for PHP. Herd installs composer for you. composer installs dependencies and lets you run scripts. Let’s create a Laravel project using it:

composer create-project laravel/laravel laravel-video-converter

Once that is done you can navigate into the project directory and start the server with artisan:

php artisan serve

Awesome! You can now navigate to http://localhost:8000/ and see the Laravel starter application’s welcome page. Artisan is the command-line interface for Laravel. It comes with other utilities as well such as a database migration tool, scripts for generating classes, and other useful things.

Uploading Videos Using Livewire

Livewire is a library that allows you to add dynamic functionality to your Laravel application without having to add a frontend framework. For this guide we’ll be using Livewire to upload files to our server and update the status of the video conversion without requiring any page reloads.

Livewire can be installed with composer like so.

composer require livewire/livewire

With it installed we need to make a Livewire component now. This component will act as the controller of our video upload page.

php artisan make:livewire video-uploader

With that done you should see two new files were created according to the output of the command, one being a PHP file and the other being a Blade file. Laravel has its own HTML template syntax for views that allow you to make your pages render dynamically.

For this demo we’ll make the video conversion page render at the root of the site. You can do this by going to routes/web.php and editing the root route definition to point to our new component.

<?php

use App\Livewire\VideoUploader;
use Illuminate\Support\Facades\Route;

Route::get('/', VideoUploader::class);

However, if we visit our website now it will return an error. This is due to the app template being missing, which is the view that encapsulates all page components and contains elements such as the document head, header, footer, etc.

Create a file at resources/views/components/layouts/app.blade.php and put the following contents inside. This will give you a basic layout that we can render our page component inside of.

<!DOCTYPE html>
<html lang="{{ str_replace('_', '-', app()->getLocale()) }}">
    <head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <title>WebM Video Converter</title>

        <style>
            html {
                font-family: sans-serif;
                background-color: #eaeaea;
            }

            main {
                max-width: 1000px;
                margin: 100px auto 0 auto;
                padding: 32px;
                border-radius: 24px;
                background-color: white;
            }

            h1 {
                margin-top: 0;
            }

            a {
                text-decoration: none;
            }
        </style>
    </head>
    <body>
        <main>
            {{ $slot }}

            <footer>
                Laravel v{{ Illuminate\Foundation\Application::VERSION }} (PHP v{{ PHP_VERSION }})
            </footer>
        </main>
    </body>
</html>

The {{ $slot }} string in the main tag is a Blade echo statement. That is where our Livewire component will be injected when loading it.

Now, let’s edit the Livewire component’s template so it has something meaningful in it that will allow us to verify that it renders correctly. Edit resources/views/livewire/video-uploader.blade.php and put in the following:

<div>
    <h1>Hello, Laravel!</h1>
</div>

With that done you can go to the root of the site and see this hello message rendered inside of a box. Seeing that means everything is working as it should. We may as well delete the welcome template since we’re not using it anymore. This file is located at resources/views/welcome.blade.php.

Now, let’s go ahead and add uploading functionality. For now we’ll just upload the file into storage and do nothing with it. Go ahead and edit app/Livewire/VideoUploader.php with the following:

<?php

namespace App\Livewire;

use Illuminate\Contracts\View\View;
use Livewire\Attributes\Validate;
use Livewire\Component;
use Livewire\Features\SupportFileUploads\TemporaryUploadedFile;
use Livewire\WithFileUploads;

class VideoUploader extends Component
{
    use WithFileUploads;

    /**
     * @var TemporaryUploadedFile
     */
    #[Validate('mimetypes:video/avi,video/mpeg,video/quicktime')]
    public $video;

    public function save(): void
    {
        $videoFilename = $this->video->store();
    }

    public function render(): View
    {
        return view('livewire.video-uploader');
    }
}

This will only allow uploading files with video file MIME types. The $video class variable can be wired inside of the component’s blade template using a form.

Create a form in resources/views/livewire/video-uploader.blade.php like so:

<div>
    <h1>WebM Video Converter</h1>

    <form wire:submit="save">
        <input type="file" wire:model="video">

        @error('video') <span class="error">{{ $message }}</span> @enderror

        <button type="submit">Convert Video</button>
    </form>
</div>

You will note a wire:submit attribute attached to the form. This will prevent the form submission from reloading the page and will result in Livewire calling the component’s save method using the video as a parameter. The $video property is wired with wire:model="video".

Now you can upload videos, and they will be stored into persistent storage in the storage/app/private directory. Awesome!

Increase the Filesize Limit

If you tried to upload a larger video you may have gotten an error. This is because the default upload size limit enforced by Livewire and PHP is very small. We can adjust these to accommodate our use-case.

Let’s start with adjusting the Livewire limit. To do that, we need to generate a configuration file for Livewire.

php artisan livewire:publish --config

All values in the generated file are the defaults we have been using already. Now edit config/livewire.php and make sure the temporary_file_upload looks like this:

...

'temporary_file_upload' => [
    'disk' => null,    	// Example: 'local', 's3'          	| Default: 'default'
    'rules' => null,   	// Example: ['file', 'mimes:png,jpg']  | Default: ['required', 'file', 'max:12288'] (12MB)
    'directory' => null,   // Example: 'tmp'                  	| Default: 'livewire-tmp'
    'middleware' => null,  // Example: 'throttle:5,1'         	| Default: 'throttle:60,1'
    'preview_mimes' => [   // Supported file types for temporary pre-signed file URLs...
        'png', 'gif', 'bmp', 'svg', 'wav', 'mp4',
        'mov', 'avi', 'wmv', 'mp3', 'm4a',
        'jpg', 'jpeg', 'mpga', 'webp', 'wma',
    ],
    'max_upload_time' => 5, // Max duration (in minutes) before an upload is invalidated...
    'cleanup' => true, // Should cleanup temporary uploads older than 24 hrs...
    'rules' => 'max:102400', // NEW: Override default so we can upload long videos.
],

...

The rules key allows us to change the maximum file size, which in this case is 100 megabytes.

This alone isn’t good enough though as the PHP runtime also has a limit of its own. We can configure this by editing the php.ini file. Since this article assumes the use of Herd, I will show how that is done with it.

Go to Herd > Settings > PHP > Max File Upload Size > and set it to 100. Once done you need to stop all Herd services in order for the changes to take effect. Also make sure to close any background PHP processes with task manager in-case any are lingering, as this happened with me. Once you’ve confirmed everything is shut off, turn on all the services again.

If you’re not using Herd, you can add the following keys to your php.ini file to get the same effect:

upload_max_filesize=100M
post_max_size=100M

Creating a Background Job

Now, let’s get to the more interesting part that is creating a background job to run on an asynchronous queue. First off, we need a library that will allow us to convert videos. We’ll be using php-ffmpeg. It should be noted that FFmpeg needs to be installed and accessible in the system path. There are instructions on their website that tell you how to install it for all major platforms. On macOS this is automatic if you install it with homebrew. On Windows you can use winget.

On macOS and Linux you can confirm that ffmpeg is in your path like so:

which ffmpeg

If a file path to ffmpeg is returned then it’s installed correctly. Now with FFmpeg installed you can install the PHP library adapter with composer like so:

composer require php-ffmpeg/php-ffmpeg

Now that we have everything we need to convert videos, let’s make a job class that will use it:

php artisan make:job ProcessVideo

Edit app/Jobs/ProcessVideo.php and add the following:

<?php

namespace App\Jobs;

use FFMpeg\FFMpeg;
use FFMpeg\Format\Video\WebM;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Queue\Queueable;
use Illuminate\Support\Facades\File;

class ProcessVideo implements ShouldQueue
{
    use Queueable;

    private string $videoPath;

    private string $outputPath;

    public function __construct(string $videoPath, string $outputPath)
    {
        $this->videoPath = $videoPath;
        $this->outputPath = $outputPath;
    }

    public function handle(): void
    {
        $tempOutputPath = "{$this->outputPath}.tmp";

        // Convert the video to the WebM container format (SLOW).
        $video = FFMpeg::create()->open($this->videoPath);
        $video->save(new WebM, $tempOutputPath);
        File::move($tempOutputPath, $this->outputPath);
    }
}

To create a job we need to make a class that implements the ShouldQueue interface and uses the Queueable trait. The handle method is called when the job is executed. Converting videos with php-ffmpeg is done by passing in an input video path and calling the save method on the returned object. In this case we’re going to convert videos to the WebM container format. Additional options can be specified here as well, but for this example we’ll keep things simple.

One important thing to note with this implementation is that the converted video is moved to a file path known by the livewire component. Later and to keep things simple we’re going to modify the component to check this file path until the file appears, and while for demo purposes this is fine, in an app deployed at a larger scale with multiple instances it is not. In that scenario it would be better to write to a cache like Redis instead with a URL to the file (if uploaded to something like S3) that can be checked instead.

Now let’s use this job! Edit app/Livewire/VideoUploader.php and let’s add some new properties and expand on our save method.

use App\Jobs\ProcessVideo;
use Illuminate\Contracts\View\View;
use Illuminate\Support\Facades\Storage;
use Livewire\Attributes\Validate;
use Livewire\Component;
use Livewire\Features\SupportFileUploads\TemporaryUploadedFile;
use Livewire\WithFileUploads;

class VideoUploader extends Component
{
    use WithFileUploads;

        /**
         * @var TemporaryUploadedFile
         */
        #[Validate('mimetypes:video/avi,video/mpeg,video/quicktime')]
        public $video;

        public ?string $jobStatus = 'Inactive';

        public ?string $outputVideoLink = null;

        public ?string $outputPath = null;

        public ?string $outputFilename = null;

        public function save(): void
        {
            $this->jobStatus = 'In Progress';
            $this->outputVideoLink = null;
            $this->outputPath = null;
            $this->outputFilename = null;

            // Store the uploaded file and generate the input and output paths of
            // the video to be converted for the job.
            $videoFilename = $this->video->store();
            $videoPath = Storage::disk('local')->path($videoFilename);
            $videoPathInfo = pathinfo($videoPath);
            $this->outputFilename = "{$videoPathInfo['filename']}.webm";
            $this->outputPath = "{$videoPathInfo['dirname']}/{$this->outputFilename}";

            // Add the long-running job onto the queue to be processed when possible.
            ProcessVideo::dispatch($videoPath, $this->outputPath);
        }

        ...
}

How this works is we tell the job where it can find the video and tell it where it should output the converted video when it’s done. We have to make the output filename be the same as the original with just the extension changed, so we use pathinfo to extract that for us.

The ProcessVideo::dispatch method is fire and forget. We aren’t given a handle of any kind to be able to check the status of a job out of the box. For this example we’ll be waiting for the video to appear at the output location.

To process jobs on the queue you need to start a queue worker as jobs are not processed in the same process as the server that we are currently running. You can start the queue with artisan:

php artisan queue:work

Now the queue is running and ready to process jobs! Technically you can upload videos for conversion right now and have them be processed by the job, but you won’t be able to download the file in the browser yet.

Generating a Temporary URL and Sending it with Livewire

To download the file we need to generate a temporary URL. Traditionally this feature has only been available for S3, but as of Laravel v11.24.0 this is also usable with the local filesystem, which is really useful for development.

Let’s add a place to render the download link and the status of the job. Edit resources/views/livewire/video-uploader.blade.php and add a new section under the form:

<div>
    <h1>WebM Video Converter</h1>

    <form wire:submit="save">
        <input type="file" wire:model="video">

        @error('video') <span class="error">{{ $message }}</span> @enderror

        <button type="submit">Convert Video</button>
    </form>

    <div wire:poll>
        <p>Job Status: {{ $jobStatus }}</p>
        @if ($outputVideoLink != null)
            <a href="{{ $outputVideoLink }}" download>Download Converted File</a>
        @endif
    </div>
</div>

Note the wire:poll attribute. This will cause the Blade echo statements inside of the div to refresh occasionally and will re-render if any of them changed. By default, it will re-render every 2.5 seconds. Let’s edit app/Livewire/VideoUploader.php to check the status of the conversion, and generate a download URL.

use App\Jobs\ProcessVideo;
use Illuminate\Contracts\View\View;
use Illuminate\Support\Facades\Storage;
use Illuminate\Support\Facades\File;
use Livewire\Attributes\Validate;
use Livewire\Component;
use Livewire\Features\SupportFileUploads\TemporaryUploadedFile;
use Livewire\WithFileUploads;

class VideoUploader extends Component
{
    use WithFileUploads;

        ...

        public function render(): View
        {
            if ($this->outputPath != null && File::exists($this->outputPath)) {
                // Create a temporary URL that lasts for 10 minutes and allows the
                // user to download the processed video file.
                $this->outputVideoLink = Storage::temporaryUrl(
                    $this->outputFilename, now()->addMinutes(10)
                );

                $this->jobStatus = 'Done';
                $this->outputPath = null;
                $this->outputFilename = null;
            }

            return view('livewire.video-uploader', [
                'jobStatus' => $this->jobStatus,
                'outputVideoLink' => $this->outputVideoLink,
            ]);
        }
}

Every time the page polls we check if the video has appeared at the output path. Once it’s there we generate the link, store it to state, and pass it to the view. Temporary URLs are customizable as well. You can change the expiration time to any duration you want, and if you’re using S3, you can also pass S3 request parameters using the optional 3rd argument.

Now you should be able to upload videos and download them with a link when they’re done processing!

Limitations

Although this setup works fine in a development environment with a small application, there are some changes you might need to make if you plan on scaling beyond that.

If your application is being served by multiple nodes then you will need to use a remote storage driver such as the S3 driver, which works with any S3 compatible file storage service. The same Laravel API calls are used regardless of the driver you use. You would only have to update the driver passed into the Storage facade methods from local to s3, or whichever driver you choose.

You also wouldn’t be able to rely on the same local filesystem being shared between your job workers and your app server either and would have to use a storage driver or database to pass files between them. This demo uses the database driver for simplicity’s sake, but it's also worth noting that by default, queues and jobs use the database driver, but SQS, Redis, and Beanstalkd can also be used. Consider using these other drives instead of depending on how much traffic you need to process.

Conclusion

In this article, we explored how to utilize queues and temporary URLs to implement a video conversion site. Laravel queues allow for efficient processing of long-running tasks like video conversion in a way that won’t bog down your backend servers that are processing web requests.

While this setup works fine for development, some changes would need to be made for scaling this such as using remote storage drivers for passing data between the web server and queue workers. By effectively leveraging Laravel’s features, developers can create robust and scalable applications with relative ease.

Cascade layers are really easy to get started with. I think the best way to understand how and when they are useful is by walking through some practical examples.

In this post, we’ll cover:

• What CSS cascade layers are and how they work
• Real-world examples of using layers to manage style priorities
• How Tailwind CSS leverages cascade layers

What are CSS Cascade Layers?

Imagine CSS cascade layers as drawers in a filing cabinet, each holding a set of styles. The drawer at the top represents the highest priority, so when you open the cabinet, you first access the styles in that drawer. If a style isn't found there, you move down to the next drawer until you find what you need.

Traditionally, CSS styles cascade by specificity (i.e., more specific selectors win) and source order (styles declared later in the file override earlier ones). Cascade layers add a new, structured way to manage styles within a single origin—giving you control over which layer takes precedence without worrying about specificity.

This is useful when you need to control the order of styles from different sources, like:

• Resets (e.g., Normalize)
• Third-party libraries (e.g., Tailwind CSS)
• Themes and overrides

You define cascade layers using the @layer rule, assigning styles to a specific layer. The order in which layers are defined determines their priority in the cascade. Styles in later layers override those in earlier layers, regardless of specificity or order within the file.

Here’s a quick example:

@layer base {
  p { color: blue; }
}

@layer theme {
  p { color: darkblue; }
}

In this example, since the theme layer comes after base, it overrides the paragraph text color to dark blue—even though both declarations have the same specificity.

How Do CSS Layers Work?

Cascade layers allow you to assign rules to specific named layers, and then control the order of those layers. This means that:

• Layers declared later take priority over earlier ones.
• You don’t need to increase selector specificity to override styles from another layer—just place it in a higher-priority layer.
• Styles outside of any layer will always take precedence over layered styles unless explicitly ordered.

Let’s break it down with a more detailed example.

audio {
  display: flex;
}

@layer reset {
  audio[controls] {
    display: block;
  }
}

In this example:

• The unlayered audio rule takes precedence because it’s not part of the reset layer, even though the audio[controls] rule has higher specificity.
• Without the cascade layers feature, specificity and order-of-appearance would normally decide the winner, but now, we have clear control by defining styles in or outside of a layer.

Use Case: Overriding Styles with Layers

Cascade layers become especially useful when working with frameworks and third-party libraries. Say you’re using a CSS framework that defines a keyframe animation, but you want to override it in your custom styles. Normally, you might have to rely on specificity or carefully place your custom rules at the end. With layers, this is simplified:

@layer framework, custom;

@layer framework {
  @keyframes slide-left {
    from { margin-left: 0; }
    to { margin-left: -100%; }
  }
}

@layer custom {
  @keyframes slide-left {
    from { translate: 0; }
    to { translate: -100% 0; }
  }
}

There’s some new syntax in this example. Multiple layers can be defined at once. This declares up front the order of the layers. With the first line defined, we could even switch the order of the framework and custom layers to achieve the same result.

Here, the custom layer comes after framework, so the translate animation takes precedence, no matter where these rules appear in the file.

Cascade Layers in Tailwind CSS

Tailwind CSS, a utility-first CSS framework, uses cascade layers starting with version 3. Tailwind organizes its layers in a way that gives you flexibility and control over third-party utilities, customizations, and overrides.

In Tailwind, the framework styles are divided into distinct layers like base, components, and utilities. These layers can be reordered or combined with your custom layers.

Here's an example:

@layer base {
  /* Base styles like resets or typography */
  h1 { font-size: 2rem; }
}

@layer components {
  /* Component-level styles */
  .btn { background-color: blue; }
}

@layer utilities {
  /* Utility classes (e.g., margin, padding) */
  .mt-4 { margin-top: 1rem; }
}

Tailwind assigns these layers in a way that utilities take precedence over components, and components override base styles. You can use Tailwind’s @layer directive to extend or override any of these layers with your custom rules.

For example, if you want to add a custom button style that overrides Tailwind’s built-in btn component, you can do it like this:

@layer components {
  .btn { background-color: green; }
}

Practical Example: Layering Resets and Overrides

Let’s say you’re building a design system with both Tailwind and your own custom styles. You want a reset layer, some basic framework styles, and custom overrides.

@layer reset {
  * { box-sizing: border-box; }
}

@layer framework {
  p { color: gray; }
}

@layer custom {
  p { color: black; }
}

In this setup:

• The reset layer applies basic resets (like box-sizing).
• The framework layer provides default styles for elements like paragraphs.
• Your custom layer overrides the paragraph color to black.

By controlling the layer order, you ensure that your custom styles override both the framework and reset layers, without messing with specificity.

Conclusion

CSS cascade layers are a powerful tool that helps you organize your styles in a way that’s scalable, easy to manage, and doesn’t rely on specificity hacks or the appearance order of rules. When used with frameworks like Tailwind CSS, you can create clean, structured styles that are easy to override and customize, giving you full control of your project’s styling hierarchy. It really shines for managing complex projects and integrating with third-party CSS libraries.

Today, I will write about something very dear to me - science. But not about science as a field of study but rather as a way of thinking.

It's easy nowadays to get lost in the sea of information, fall for marketing hype, or even be trolled by a hallucinating LLM. A scientific mindset can be a powerful tool for navigating the complex modern world and the world of software engineering in particular.

Not only is it a powerful tool, but I'll argue that it's a must nowadays if you want to make informed decisions, solve problems effectively, and become a better engineer.

As software engineers, we are constantly confronted with an overwhelming array of frameworks, technologies, and infrastructure choices. Sometimes, it feels like there's a new tool or platform every day, each accompanied by its own wave of hype and marketing. It's easy to feel lost in the myriad of information or even suffer from FOMO and insecurity about not jumping on the latest bandwagon.

But it's not only about the abundance of information and making technological decisions. As engineers, we often write documentation, blog posts, talks, or even books. We need to be able to communicate our ideas clearly and effectively. Furthermore, we have to master the art of debugging code, which is essentially a scientific process where we form hypotheses, test them, and iterate until we find the root cause of the problem.

Therefore, here's my hot take: engineering is a science; hence, to deserve an engineer title, one needs to think like a scientist.

So, let's review (pun intended) what it means to think like a scientist in the context of software engineering.

Systematic Review

In science, systematic review is not only an essential means to understand a topic and map the current state of knowledge in the field, but it also has a well-defined methodology. You can't just google whatever supports your hypothesis and call it a day. You must define your research question, choose the databases you will search, set your inclusion and exclusion criteria, systematically search for relevant studies, evaluate their quality, and synthesize the results. Most importantly, you must be transparent about and describe your methodology in detail.

The general process of systematic review can be summarized in the following steps:

1. Define your research question(s)

2. Choose databases and other sources to search

3. Define keywords and search terms

4. Define inclusion and exclusion criteria

   a. Define practical criteria such as publication date, language, etc.

   b. Define methodological criteria such as study design, sample size, etc.

5. Search for relevant studies

6. Evaluate the quality of the studies

7. Synthesize the results

Source: Conducting Research Literature Reviews: From the Internet to Paper by Dr. Fink

I'm pretty sure you can see where I'm going with this. There are many use cases in software engineering where a process similar to systematic review can be applied. Whether you're evaluating a new technology, choosing a tech stack for a new project, or researching for a blog post or a conference talk, it's important to be systematic in your approach, transparent about your methodology, and honest about the limitations of your research.

Of course, when choosing a tech stack to learn or researching for a blog post, you don't have to be as rigorous as in a scientific study. But a few of these steps will always be worth following. Let's focus on those and see how we can apply them in the context of software engineering.

Defining Your Research Question(s)

Before you start researching, it's important to define your research questions. What are you trying to find out? What problem are you trying to solve? What are the goals of your research? These questions will help you stay focused and avoid focusing on irrelevant information.

A practical example: If you're evaluating, say, whether to use bundler A or bundler B without a clear research question, you might end up focusing on marketing claims about how bundler A is faster than bundler B or how bundler B is more popular than bundler A, even though such aspects may have minimal impact on your project. With a clear research question, you can focus on what really matters for your project, like how well each bundler integrates with your existing tools, how well they handle your specific use case, or how well they are maintained.

A research question is not a hypothesis - you don't have to have a clear idea of the answer. It's more about defining the scope of your research and setting clear goals. It can be as simple and general as "What are the pros and cons of using React vs. Angular for a particular project?" but also more specific and focused, like "What are the legal implications of using open-source library X for purpose Y in project Z?". You can have multiple research questions, but keeping them focused and relevant to your goals is essential.

In my personal opinion, part of the scientific mindset is automatically having at least a vague idea of a research question in your head whenever you're facing a problem or a decision, and that alone can make you a more confident and effective engineer.

Choosing Databases and Other Sources to Search

In engineering, some information (especially when researching rare bugs) can be scarce, and you have to search wherever and take what you can get. Hence, this step is arguably much easier in science, where you can include well-established databases and publications in your search. Information in science is simply more standardized and easier to find.

There are, however, still some decisions to be made about where to search. Do you want to include community websites like StackOverflow or Reddit? Do you want to include marketing materials from the companies behind the technologies you're evaluating? These can all be valid sources of information, but they have their limitations and biases, and it's important to be aware of them.

Or do you want to ask a LLM? I hadn't included LLMs in the list of valid sources of information on purpose as they are not literature databases in the traditional sense, and I wouldn't consider them a search source for literature research. And for a very good reason - they are essentially a black box, and therefore, you cannot reliably describe a reproducible methodology of your search.

That doesn't mean you shouldn't ask an LLM for inspiration or a TL;DR, but you should always verify the information you get from them and be aware of their limitations.

Defining Keywords and Search Terms

This section will be short, as most of you are familiar with the concept of keywords and search terms and how to use search engines. However, I still wanted to highlight the importance of knowing how to search effectively for a software engineer. It's not just about typing in a few keywords and hoping for the best. It's about learning how to use advanced search operators, filter out irrelevant results, and find the information you need quickly and efficiently.

If you're not familiar with advanced search operators, I highly recommend you take some time to learn them, for example, at FreeCodeCamp. Please note, however, that the article is specific to Google and different search engines may have different operators and syntax. This is especially true for scientific databases, which often have their own search syntax and operators. So, if you're doing more formal research, familiarize yourself with the database's search syntax. The underlying principles, however, are pretty much the same everywhere; just the syntax and UI might differ.

With a solid search strategy in place, the next critical step is to assess the quality of the information we find.

Methodological Criteria and Evaluation of Sources

This is where things get interesting. In science, evaluating the quality of the studies is a crucial step in the systematic review process. You can't just take the results of a study at face value - you need to critically evaluate its design, the sample size, the methodology, and the conclusions - and you need to be aware of the limitations of the study and the potential biases that may have influenced the results.

In science, there is a pretty straightforward yet helpful categorization of sources that my students surprisingly needed help understanding because no one ever explained it to them. So let me lay out and explain the three categories to you now:

1. Primary sources

Primary sources represent original research. You can find them in studies, conference papers, etc. In science, this is what you generally want to cite in your own research.

However, remember that only some of what you find in an original research paper is a primary source. Only the parts that present the original research are primary sources. For example, the introduction can contain citations to other studies, which are not primary, but secondary sources.

While primary sources can sometimes be perceived as hard to read and understand, in many cases, they can actually be easier to reach and understand as the methods and results are usually presented in a condensed form in the abstract, and often you can only skim the introduction and discussion to get a good idea of the study.

In software engineering, primary sources can sometimes be papers, but more often, they are original documentation, case studies, or even blog posts that present original research or data. For example, if you're evaluating a new technology, the official documentation, case studies, and blog posts from its developers can be considered primary sources.

2. Secondary sources

Secondary sources are typically reviews, meta-analyses, and other sources that summarize, analyze, or reference the primary sources. A good way to identify a source as secondary is to look for citations to other studies. If a claim has a citation, it's likely a secondary source. On the other hand, something is likely wrong if it doesn't have a citation and doesn't seem to present original research.

Secondary sources can be very useful for getting an overview of a topic, understanding the current state of knowledge, and finding relevant primary sources. Meta-analyses, in particular, can provide a beneficial point of view on a subject by combining the results of multiple studies and looking for patterns and trends.

The downside of secondary sources is that they can introduce information noise, as they are basically introducing another layer of interpretation and analysis. So, it's always a good idea to go back to the primary sources and verify the information you get from secondary sources.

Secondary sources in software engineering include blog posts, talks, or articles that summarize, analyze, or reference primary sources. For example, if you're researching a new technology, a blog post that compares different technologies based on their documentation and/or studies made by their authors can be considered a secondary source.

3. Tertiary sources

Tertiary sources represent a further level of abstraction. They are typically textbooks, encyclopedias, and other sources that summarize, analyze, or reference secondary sources. They are useful for getting a broad overview of a topic, understanding the basic concepts, and finding relevant secondary sources.

One example I see as a tertiary source is Wikipedia, and while you shouldn't ever cite Wikipedia in academic research, it can be a good starting point for getting an overview of a topic and finding relevant primary and secondary sources as you can easily click through the references.

Note: It's fine to reference Wikipedia in a blog post or a talk to give your audience a convenient explanation of a term or concept. I'm even doing it in this post. However, you should always verify that the article is up to date and that the information is correct.

The distinction between primary, secondary, and tertiary sources in software engineering is not as clear-cut as in science, but the general idea still applies. When researching a topic, knowing the different types of sources and their limitations is essential. Primary sources are generally the most reliable and should be your go-to when seeking evidence to support your claims. Secondary sources can help get an overview of a topic, but they should be used cautiously, as they can introduce bias and noise. Tertiary sources are good for getting a broad overview of a topic but should not be used as evidence in academic research.

Evaluating Sources

Now that we have the categories laid out let's talk about evaluating the quality of the sources because, realistically, not all sources are created equal.

In science, we have some well-established criteria for evaluating the quality of a source. Some focus on the general credibility of the source, like the reputation of the journal or the author. In contrast, others focus on the quality of the study itself, like the study design, the sample size, and the methodology.

First, we usually look at the number of citations and the impact factor of the journal in which the study was published. These numbers can give us an idea of how well the scientific community received the study and how much other researchers have cited it.

In software engineering, we don't have the concept of impact factor when it comes to researching a concept or a technology, but we can still look at how many people are sharing the particular piece of information and how well the professional community receives it and how reputable the person sharing the information is.

Second, we look at the study design and the methodology. Does the study have a clear research question? Is the study design appropriate for the research question? Are the methods well-described and reproducible? Are the results presented clearly and honestly? Do the data support the conclusions?

Arguably, in software engineering, the honest and clear presentation of the method and results can be even more important than in science, given the amounts of money circulating in the industry and the potential for conflicts of interest. Therefore, it's important to understand where the data is coming from, how it was collected, and how it was analyzed.

If a company (or their DevRel person) is presenting data that show their product is the best (fastest, most secure...), it's important to be aware of the potential biases and conflicts of interest that may have influenced the results.

The ways in which the results can be skewed may include:

• Missing, incomplete, or inappropriate methodology. Often, the methodology is not described in enough detail to be reproducible, or the whole experiment is designed in a way that doesn't actually answer the research question properly. For example, the methodology can omit important details, such as the environment in which the experiment was conducted or even the way the data was collected (e.g., to hide selection bias).

• Selection bias can be a common issue in software engineering experiments. For example, if someone is comparing two technologies, they might choose a dataset that they expect to perform better with one of the technologies or a metric that they expect to show a difference. Selection bias can lead to skewed results that don't reflect the technologies' real-world performance.

• Publication bias is a common issue in science, where studies that show a positive result are more likely to be published than studies that show a negative outcome. In software engineering, this can manifest as a bias towards publishing success stories and case studies, while ignoring failures and negative results.

• Confirmation bias is a problem in science and software engineering alike. It's the tendency to look for evidence that confirms your hypothesis and ignore evidence that contradicts it. Confirmation bias can lead to cherry-picking data, misinterpreting results, and drawing incorrect conclusions.

• Conflict of interest. While less common in academic research, conflicts of interest can be a big issue in industry research. If a company is funding a study that shows its product in a positive light, it's important to be aware of the potential biases that may have influenced the results.

Another thing we look at is the conclusions. Do the data support the conclusions? Are they reasonable and justified? Are they overstated or exaggerated? Are the limitations of the study acknowledged? Are the implications of the study discussed? It all goes back to honesty and transparency, which is crucial for evaluating the quality of the source.

Last but not least, we should look at the citations and references included in the source. In the same way we apply the systematic review process to our research, we should also apply it to the sources we use. I would argue that this is even more important in software engineering, where the information is often less standardized, and you come across many unsupported claims. If a source doesn't provide citations or references to back up their claims, it's a red flag that the information may not be reliable.

This brings us to something called anecdotal evidence. Anecdotal evidence is a personal story or experience used to support a claim. While anecdotal evidence can be compelling and persuasive, it is generally considered a weak form of evidence, as it is based on personal experience rather than empirical data. So when someone tells you that X is better than Y because they tried it and it worked for them, or that Z is true because they heard it from someone, take it with a massive grain of salt and look for more reliable sources of information.

That, of course, doesn't mean you should ask for a source under every post on social media, but it's important to recognize what's a personal opinion and what's a claim based on evidence.

Synthesizing the Results

Once you have gathered all the relevant information, it's time to synthesize the results. This is where you combine all the evidence you have collected, analyze it, and draw conclusions.

In science, this is often done as part of a meta-analysis, where the results of multiple studies are combined and analyzed to look for patterns and trends using statistical methods. A meta-analysis is a powerful tool for synthesizing the results of multiple studies and drawing more robust conclusions than can be drawn from any single study.

You might not be doing a formal meta-analysis in software engineering, but you can still apply the same principles to your research. Look for common themes and trends in the information you have gathered, compare and contrast different sources, and draw conclusions based on the evidence.

Conclusion

Adopting a scientific way of thinking isn't just a nice-to-have in software engineering - it's essential to make informed decisions, solve problems effectively, and navigate the vast amount of information around you with confidence. Applying systematic review principles to your research allows you to gather reliable information, evaluate it critically, and draw sound conclusions based on evidence.

Let's summarize what such a systematic research approach can look like:

• Define Clear Research Questions:
  • Start every project or decision-making process by clearly stating what you aim to achieve or understand.
  • Example: "What factors should influence our choice between Cloud Service A and Cloud Service B for our application's specific needs?"
• Critically Evaluate Sources:
  • Identify the type of sources (primary, secondary, tertiary) and assess their credibility.
  • Be wary of biases and seek out multiple perspectives for a well-rounded understanding.
• Be Aware of Biases:
  • Recognize common biases that can cloud judgment, such as confirmation or selection bias.
  • Actively counteract these biases by seeking disconfirming evidence and questioning assumptions.
• Systematically Synthesize Information:
  • Organize your findings and analyze them methodically.
  • Use tools and frameworks to compare options based on defined criteria relevant to your project's goals.

I encourage you to embrace this scientific approach in your daily work. The next time you're facing a critical decision - be it selecting a technology stack, debugging complex code, or planning a project - apply these principles:

• Start with a Question: Clearly define what you need to find out.
• Gather and Evaluate Information: Seek out reliable sources and scrutinize them.
• Analyze Systematically: Organize your findings and look for patterns or insights.
• Make Informed Decisions: Choose the path supported by evidence and sound reasoning.

By doing so, you will enhance your problem-solving skills and contribute to a culture of thoughtful, evidence-based practice in the software engineering community.

The best part is that once you start applying a critical and systematic approach to your sources of information, it becomes second nature. You'll automatically start asking questions like, "Where did this information come from?" "Is it reliable?" and "Can I reproduce the results?" Doing so will make you much less susceptible to hype, marketing, and new shiny things, ultimately making you happier and more confident.

In the next part of this series, we'll look at applying the scientific mindset to debugging and using hypothesis testing and experimentation principles to solve problems more effectively.

In the previous post we defined our database schema, got up and running with migrations, and loaded some seed data into our database. In this post we will be working with our new database and seed data. If you want to participate, make sure to follow the steps in the first post.

We’ve been taking a minimal approach so far by using only wrangler and sql scripts for our workflow. The D1 Client API has a small surface area. Thanks to the power of SQL, we will have everything we need to construct all types of queries. Before we start writing our queries, let's touch on some important concepts.

Prepared statements and parameter binding

This is the first section of the docs and it highlights two different ways to write our SQL statements using the client API: prepared and static statements. Best practice is to use prepared statements because they are more performant and prevent SQL injection attacks. So we will write our queries using prepared statements.

We need to use parameter binding to build our queries with prepared statements. This is pretty straightforward and there are two variations.

By default we add ? ’s to our statement to represent a value to be filled in. The bind method will bind the parameters to each question mark by their index. The first ? is tied to the first parameter in bind, 2nd, etc. I would stick with this most of the time to avoid any confusion.

const stmt = db.prepare('SELECT * FROM users WHERE name = ? AND age = ?').bind( 'John Doe', 41 );

I like this second method less as it feels like something I can imagine messing up very innocently. You can add a number directly after a question mark to indicate which number parameter it should be bound to. In this exampl, we reverse the previous binding.

const stmt = db.prepare('SELECT * FROM users WHERE name = ?2 AND age = ?1').bind( 41, 'John Doe' );

Reusing prepared statements

If we take the first example above and not bind any values we have a statement that can be reused:

const stmt = db.prepare('SELECT * FROM users WHERE name = ? AND age = ?')

const results = stmt.bind('John Doe', 41).all()
const results = stmt.bind('Jane Doe', 38).all()

Querying

For the purposes of this post we will just build example queries by writing them out directly in our Worker fetch handler. If you are building an app I would recommend building functions or some other abstraction around your queries.

select queries

Let's write our first query against our data set to get our feet wet.

Here’s the initial worker code and a query for all authors:

import * as Schema from './schema';

export default {
    async fetch(request, env, ctx): Promise<Response> {
        let results = await env.DB.prepare('SELECT * FROM authors').all<Schema.Author[]>();

        return new Response(JSON.stringify(results.results), {
            headers: { 'content-type': 'application/json' },
        });
    },
} satisfies ExportedHandler<Env>;

We pass our SQL statement into prepare and use the all method to get all the rows. Notice that we are able to pass our types to a generic parameter in all. This allows us to get a fully typed response from our query.

We can run our worker with npm run dev and access it at http://localhost:8787 by default. We’ll keep this simple workflow of writing queries and passing them as a json response for inspection in the browser. Opening the page we get our author results.

joins

Not using an ORM means we have full control over our own destiny. Like anything else though, this has tradeoffs. Let’s look at a query to fetch the list of posts that includes author and tags information.

type PostsWithAuthorsAndTags = Schema.Post & {
    author_name: string;
    tags: string;
};

let results = await env.DB.prepare(
        `
SELECT
  posts.*,
    authors.name AS author_name,
    COALESCE(
        JSON_GROUP_ARRAY(tags.name),
        '[]'
    ) AS tags
FROM
    posts
JOIN
    authors ON posts.author_id = authors.id
LEFT JOIN
    posts_tags ON posts.id = posts_tags.post_id
LEFT JOIN
    tags ON posts_tags.tag_id = tags.id
GROUP BY
posts.id
            `
).all<PostsWithAuthorsAndTags[]>();

Let’s walk through each part of the query and highlight some pros and cons.

SELECT
  posts.*,
    authors.name AS author_name,
    COALESCE(
        JSON_GROUP_ARRAY(tags.name),
        '[]'
    ) AS tags

• The query selects all columns from the posts table.
• It also selects the name column from the authors table and renames it to author_name.
• It aggregates the name column from the tags table into a JSON array. If there are no tags, it returns an empty JSON array. This aggregated result is renamed to tags.

FROM
    posts
JOIN
    authors ON posts.author_id = authors.id
LEFT JOIN
    posts_tags ON posts.id = posts_tags.post_id
LEFT JOIN
    tags ON posts_tags.tag_id = tags.id
GROUP BY
    posts.id

• The query starts by selecting data from the posts table.
• It then joins the authors table to include author information for each post, matching posts to authors using the author_id column in posts and the id column in authors.
• Next, it left joins the posts_tags table to include tag associations for each post, ensuring that all posts are included even if they have no tags.
• Next, it left joins the tags table to include tag names, matching tags to posts using the tag_id column in posts_tags and the id column in tags.
• Finally, group the results by the post id so that all rows with the same post id are combined in a single row

SQL provides a lot of power to query our data in interesting ways. JOIN ’s will typically be more performant than performing additional queries.You could just as easily write a simpler version of this query that uses subqueries to fetch post tags and join all the data by hand with JavaScript. This is the nice thing about writing SQL, you’re free to fetch and handle your data how you please.

Our results should look similar to this:

[
  {
    "id": 1,
    "author_id": 1,
    "title": "Exploring the Alps",
    "content": "Content about exploring the Alps...",
    "published_at": "2024-07-31 18:37:21",
    "author_name": "Alice Smith",
    "tags": "[\\"Travel\\",\\"Photography\\"]"
  },
  ...
]

This brings us to our next topic.

Marshaling / coercing result data

A couple of things we notice about the format of the result data our query provides:

Rows are flat. We join the author directly onto the post and prefix its column names with author.

"author_name": "Alice Smith"

Using an ORM we might get the data back as a child object:

{
  "id": 1,
  "title": "Exploring the Alps",
  "author": {
    "name": "Alice Smith"
  },
  ...
 }

Another thing is that our tags data is a JSON string and not a JavaScript array. This means that we will need to parse it ourselves.

result.tags = JSON.parse(result.tags)

This isn’t the end of the world but it is some more work on our end to coerce the result data into the format that we actually want.

This problem is handled in most ORM’s and is their main selling point in my opinion.

insert / update / delete

Next, let’s write a function that will add a new post to our database.

async function createNewPost(env: Env, newPostData: NewPostData): Promise<{ id: number }> {
    // Insert the new post into the posts table
    const postResult = await env.DB.prepare(
        `
INSERT INTO posts (author_id, title, content)
VALUES (?, ?, ?)
RETURNING id
                    `
    )
        .bind(newPostData.authorId, newPostData.title, newPostData.content)
        .first<{ id: number }>();

    if (!postResult) {
        throw new Error('Failed to insert new post');
    }

    const postId = postResult.id;

    // Insert tags into the tags table if they don't already exist and get their IDs
    const tagIds = await Promise.all(
        newPostData.tags
            .map(async (tag) => {
                await env.DB.prepare(
                    `
INSERT OR IGNORE INTO tags (name)
VALUES (?)
                                    `
                )
                    .bind(tag)
                    .run();

                const tagResult = await env.DB.prepare(
                    `
SELECT id FROM tags WHERE name = ?
                                    `
                )
                    .bind(tag)
                    .first<{ id: number }>();

                return tagResult?.id;
            })
            .filter(Boolean)
    );

    // Link tags to the new post in the posts_tags table
    for (const tagId of tagIds) {
        await env.DB.prepare(
            `
INSERT INTO posts_tags (post_id, tag_id)
VALUES (?, ?)
                            `
        )
            .bind(postId, tagId)
            .run();
    }

    return { id: postId };
}

There’s a few queries involved in our create post function:

• first we create the new post
• next we run through the tags and either create or return an existing tag
• finally, we add entries to our post_tags join table to associate our new post with the tags assigned

We can test our new function by providing post content in query params on our index page and formatting them for our function.

const newPostData: NewPostData = {
    authorId: Number(url.searchParams.get('authorId')),
    tags: url.searchParams.get('tags')?.split(',') ?? [],
    title: url.searchParams.get('title') ?? '',
    content: url.searchParams.get('content') ?? '',
};
if (!newPostData.authorId || !newPostData.title || !newPostData.content) {
    return new Response('Missing required fields', { status: 400 });
}

const newPost = await createNewPost(env, newPostData);

I gave it a run like this: http://localhost:8787authorId=1&tags=Food%2CReview&title=A+review+of+my+favorite+Italian+restaurant&content=I+got+the+sausage+orchette+and+it+was+amazing.+I+wish+that+instead+of+baby+broccoli+they+used+rapini.+Otherwise+it+was+a+perfect+dish+and+the+vibes+were+great

And got a new post with the id 11.

UPDATE and DELETE operations are pretty similar to what we’ve seen so far. Most complexity in your queries will be similar to what we’ve seen in the posts query where we want to JOIN or GROUP BY data in various ways.

To update the post we can write a query that looks like this:

await env.DB.prepare(
`
UPDATE posts
SET
author_id = COALESCE(?, author_id),
title = COALESCE(?, title),
content = COALESCE(?, content)
WHERE id = ?
`
)
.bind(updatedPostData.authorId, updatedPostData.title, updatedPostData.content, postId)
.run();

COALESCE acts similarly to if we had written a ?? b in JavaScript. If the binded value that we provide is null it will fall back to the default.

We can delete our new post with a simple DELETE query:

await env.DB.prepare(
`
DELETE posts WHERE id = ?
`
)
.bind(postId)
.run();

Transactions / Batching

One thing to note with D1 is that I don’t think the traditional style of SQLite transactions are supported. You can use the db.batch API to achieve similar functionality though.

According to the docs:

Batched statements are SQL transactions ↗. If a statement in the sequence fails, then an error is returned for that specific statement, and it aborts or rolls back the entire sequence.

await db.batch([
    db.prepare("UPDATE users SET name = ?1 WHERE id = ?2").bind( "John", 17 ),
    db.prepare("UPDATE users SET age = ?1 WHERE id = ?2").bind( 35, 19 ),
]);

Summary

In this post, we've taken a hands-on approach to exploring the D1 Client API, starting with defining our database schema and loading seed data. We then dove into writing queries, covering the basics of prepared statements and parameter binding, before moving on to more complex topics like joins and transactions. We saw how to construct and execute queries to fetch data from our database, including how to handle relationships between tables and marshal result data into a usable format. We also touched on inserting, updating, and deleting data, and how to use transactions to ensure data consistency. By working through these examples, we've gained a solid understanding of how to use the D1 Client API to interact with our database and build robust, data-driven applications.

Why Build a Stripe App?

I recently participated in an audio space with the Stripe team, and something they said really stuck with me: the Stripe app store is a growing area that isn't overly saturated yet. There's a lot of potential for new apps, and companies can use this opportunity to grow.

I work at a company called This Dot Labs, and we've created several Stripe apps and even own one. After looking at the data, I can confirm that the Stripe team was right!

Creating a QR Code Generator App

For this tutorial, we'll build a QR code app that can take a URL and generate a code for it. This is a good use case to help you understand the ins and outs of Stripe's developer tools.

Why QR Codes?

QR codes are useful tools that have become common in e-commerce, restaurants, and other industries. While Stripe already has a QR code tool, we'll make our own to familiarize ourselves with their syntax and problem-solving approaches.

Project Structure

Before we dive into the implementation, let's look at the structure of our Stripe App QR Code project:

• .vscode: Contains settings for Visual Studio Code
• source/views: Holds the main application views
• .gitignore: Specifies files to ignore in version control
• stripe-app.json: Defines the Stripe app configuration
• ui-extensions.d.ts: TypeScript declaration file for UI extensions
• .build: this is where the built Stripe app gets placed.

Step-by-Step Implementation

1. Install Stripe Locally

First, you need to install Stripe on your local machine. The documentation provides great instructions for this:

• For Mac users: Use Brew to install
• For Windows users: Download the package and add it to your environment variables

You can find the details here in the stripe docs to install the Stripe CLI https://docs.stripe.com/stripe-cli

When using Windows, you must do stripe login from Powershell, NOT from Git bash or any other tool. After the server is up, then you can continue using git bash for everything else. After stripe login, you need to enter stripe apps start. Once you do that, the server is up and running and you can go back to using git bash or any other tool.

2. Install Dependencies

We'll be using an extra package for QR code generation. Install it using npm:

npm install qrcode

3. Set Up the Main Component

Let's look at the home.tsx file, where we'll use Stripe's UI components:

import { Box, ContextView, Button, TextField, Banner } from 
'@stripe/ui-extension-sdk/ui';

These components are similar to other UI libraries like Bootstrap or Tailwind CSS.

4. Create the UI Structure

Our app will have:

• An input field for the URL
• Validation using a regex pattern
• Error handling for invalid URLs
• QR code generation and display

Here is the Home.tsx file that is located in the src/views folder

import {
  Box,
  ContextView,
  Button,
  TextField,
  Img,
  Banner,
} from "@stripe/ui-extension-sdk/ui";
import { useState } from 'react';
import QRCode from 'qrcode';
const Home = () => {
  const [url, setUrl] = useState('');
  const [qrCode, setQrCode] = useState('');
  const [error, setError] = useState('');
  const generateQRCode = async () => {
    try {
      if (!url) {
        setError("Please enter a URL.");
        return;
      }
//basic regex pattern for URL validation
      const urlPattern = new RegExp(
        '^(https?:\\/\\/)?' +
        '((([a-z\\d]([a-z\\d-]*[a-z\\d])*)\\.)+[a-z]{2,}|' +
        '((\\d{1,3}\\.){3}\\d{1,3}))' +
        '(\\:\\d+)?(\\/[-a-z\\d%_.~+]*)*' +
        '(\\?[;&a-z\\d%_.~+=-]*)?' +
        '(\\#[-a-z\\d_]*)?', 'i'
      );
      if (!urlPattern.test(url)) {
        setError("Please enter a valid URL (e.g., https://example.com)");
        return;
      }
      const qrCodeDataUrl = await QRCode.toDataURL(url, {
        width: 200,
        margin: 2,
      });
      setQrCode(qrCodeDataUrl);
      setError('');
    } catch (error) {
      console.error("Error generating QR code", error);
      setError("Failed to generate QR Code. Please try again.");
    }
  };
  return (
    <ContextView
      title="URL QR Code Generator"
      brandColor="#635bff"
      externalLink={{
        label: "Stripe Docs",
        href: "https://stripe.com/docs",
      }}
    >
      <Box css={{ stack: "y", rowGap: "large", padding: "medium" }}>
        <Box css={{ font: "heading", marginBottom: "medium" }}>
          Generate User Payment QR Code
        </Box>
        <TextField
          label="Enter URL"
          placeholder="https://example.com"
          value={url}
          onChange={(e) => setUrl(e.target.value)}
          type="url"
        />
        {error && (
          <Banner
            type="critical"
            title="Error"
            description={error}
          />
        )}
        <Button
          type="primary"
          onPress={() => generateQRCode()}
          disabled={!url}
        >
          Generate QR Code
        </Button>
        {qrCode && (
          <Box css={{
            stack: "y",
            rowGap: "medium",
            alignSelfY: "center",
            marginTop: "large"
          }}>
            <Box css={{ font: "heading" }}>Your QR Code</Box>
            <Img
              src={qrCode}
              alt="Generated QR Code"
            />
            <Button
              type="secondary"
              onPress={() => {
                window.open(qrCode, '_blank');
              }}
            >
              Download QR Code
            </Button>
          </Box>
        )}
      </Box>
    </ContextView>
  );
};
export default Home;

• ContextView` is at the top level of the app where we see the Title and the link to the Stripe Docs that we placed in our Context View.
• Box is how you use Divs.
• Banners can be used to show notification errors or any other item you wish to display.
• Textfields are input fields.
• Everything else is pretty self-explanatory.

5. Handle Content Security Policy

One problem I personally ran into was when I tried to redirect users, the Stripe policies would block it since I did not express that I knew what it was doing. I had to go into the stripe-app.json file and mention the specific security policies. For this particular exercise, I kept these as null.

This is my stripe-app.json file.

{
    "id": "com.example.my-stripe-app",
    "version": "0.0.1",
    "name": "My Stripe App",
    "icon": "",
    "permissions": [],
    "stripe_api_access_type": "platform",
    "ui_extension": {
        "views": [
            {
                "viewport": "stripe.dashboard.home.overview",
                "component": "Home"
            },
            {
                "viewport": "stripe.dashboard.invoice.detail",
                "component": "Invoice"
            }
        ],
        "content_security_policy": {
            "connect-src": null,
            "image-src": null,
            "purpose": ""
        }
    }
}

6. Configure App Views

As you can see here, the stripe-app.json file shows the views for each file I have. The Home.tsx file and the Invoice.tsx are also included This is our way of saying that for each view we have, show the app functionality on that page. Our stripe-app.json file will show it but also, the manifest.js file in our .build folder will also show the same. Any view that doesn't have a file will not show the application's functionality. So, if I were to go to transactions, the app would not show the same logic as the home or invoices page.

By following these steps, you'll have a fully functional QR code generator app for Stripe. This is just a simple example, but the potential for Stripe apps is massive, especially for businesses serving e-commerce customers.

If you need help or get stuck, don't hesitate to reach out, danny.thompson@thisdot.co. The Stripe team is also very active in answering questions, so leverage them as a resource. Happy coding!

Here are the chapter titles with timestamps:

1: Setting the Stage – The Importance of Practical Skills in Engineering (00:00) 2: Engineering Management and Leadership Culture (04:36) 3: Extreme Ownership – A Leadership Superpower (09:12) 4: Confidence and the Developer's Journey (13:37) 5: Hiring Smarter and Building Stronger Teams (18:27) 6: Problem-Solving and Technology's Real-World Impact (23:13) 7: Leadership, Humility, and Long-Term Success (30:20) 8: Wrapping Up – Final Thoughts on Leadership and Ego (41:58)

Follow Nate Emerson on Social Media Twitter: https://x.com/nateemerson Linkedin: https://www.linkedin.com/in/nate-emerson YouTube: https://www.youtube.com/channel/UC0K8hu90G3iV6327ymEViNw

Sponsored by This Dot

Chapters

1. Introduction – [00:00:00]
2. Early Career & Transition into Tech – [00:00:58]
3. The Evolution of Technology Stacks – [00:03:15]
4. Learning Through Play & Empathy – [00:04:52]
5. Agile Development & Challenges – [00:18:51]
6. Value-Driven Software Development – [00:21:23]
7. Avoiding Burnout in Tech Careers – [00:25:42]
8. Conclusion – [00:36:17]

Follow Paul McCollum on Social Media Paul McCollum Linkedin: https://www.linkedin.com/in/realpaulmccollum/ Paul McCollum Twitter: https://x.com/uxaholic

Chapters

Introduction and Opening Remarks - 00:00 Gant's Background and Journey in Tech - 02:05 Transitioning to Leadership at Infinite Red - 05:08 Defining Innovation at an Agency - 07:28 The Role of AI in React Native - 09:39 Navigating the Hype and Troughs of Technology - 11:35 The Challenges of Middle Management - 15:12 Building Trust and Managing Upwards - 16:25 Empowering Teams and Passing the Torch - 19:40 Developing Courage and Taking Risks - 22:30 Why Leadership is Worth It - 30:28 Final Thoughts and Wrap-Up - 31:53

Follow Gant Laborde on Social Media Twitter: https://x.com/GantLaborde Github: https://github.com/GantMan Linkedin: https://www.linkedin.com/in/gant-laborde/ Mastodon: https://mastodon.social/@gantlaborde

Chapters:

1. Introduction to the Episode (00:00:03)
2. Overview of Llama 3.1 and Setup (00:02:14)
3. Setting Up the Next.js Application (00:04:40)
4. Recording Audio with MediaRecorder API (00:11:37)
5. Integrating OpenAI's Whisper for Speech-to-Text (00:36:46)
6. Generating Responses with Llama 3.1 (00:48:24)
7. Implementing Text-to-Speech with OpenAI's TTS (01:03:26)
8. Final Testing and Demonstration (01:06:37)
9. Summary and Next Steps (01:09:01)
10. Closing Remarks (01:14:19)

Follow Jesus on Social Media Twitter: https://x.com/padron4497 Github: https://github.com/padron4497

00:00 - Meet Shashi Loh 02:25 - The Gridiron Survivor Project 05:02 - The Importance of Code Reviews 07:25 - Teaching the Basics of Project Communication 09:47 - Code Reviews as a Learning Tool 12:06 - Why Shashi Mentors: Giving Back to the Community 14:26 - The Importance of De-Risking Junior Candidates 16:41 - Building in Public: Transparency and Learning 19:00 - Assessing Candidates for the Gridiron Survivor Project 21:25 - The Power of Simple Coding Tests 23:45 - Scaling Up Skills: From Small Tasks to Big Projects 26:07 - Should Companies Be Doing This? 28:25 - Finding Hidden Gems in the Job Market 30:47 - The Challenges of Filtering Candidates 33:02 - Where to Find Shashi Online 34:38 - Closing Remarks

Follow Shashi Lo on Social Media Twitter: https://x.com/shashiwhocodes Linkedin: https://www.linkedin.com/in/shashilo/ Github: https://github.com/shashilo

Sponsored by This Dot.

Chapters 1: Introductions (00:00 – 02:40) 2: What is Docker and Why It Matters (02:41 – 06:30) 3: Docker Files and Containers 101 (06:31 – 11:00) 4: Challenges of Environment Setup & Dev Containers (11:01 – 15:00) 5: The Power of Layer Caching in Docker (15:01 – 20:30) 6: Introduction to Depot and Cloud-Based Builds (20:31 – 25:00) 7: Optimizing Docker Builds with Depot (25:01 – 30:00) 8: Docker in the Modern Web Stack (30:01 – 35:00) 9: The Future of Cloud Builds and CI/CD Pipelines (35:01 – 40:00) 10: Final Thoughts and Where to Find More (40:01 – End)

Follow Kyle Tryon on Social Media Twitter: https://x.com/TechSquidTV Linkedin: https://www.linkedin.com/in/kyle-tryon/ Github: https://github.com/techsquidtv

Sponsored by This Dot: thisdot.co

00:00 - Introduction of the episode and guest Dr. Mike Saylor
00:41 - Dr. Saylor's journey to becoming CEO of Black Swan Cybersecurity
03:17 - Early entrepreneurial ventures and building his own computer company
04:57 - Challenges in selling cybersecurity services
06:53 - Building reputation and generating leads through various methods
07:50 - Navigating different business models for growth
09:24 - Managing client relationships and the importance of business development 11:17 - Exploring different partner models in the business
13:57 - Working with partners to grow opportunities and manage risks
15:24 - The referral business model and subcontracting challenges
16:20 - Complacency and the need for diversification in sales channels
17:24 - The importance of knowing your business and finding the right partner strategy
18:38 - Developing strong partnerships and managing conflicts
20:38 - Recognizing when a partner has different priorities
22:48 - Risks of over-reliance on partners and how to hedge bets
25:41 - Managing long-term relationships with partners
27:28 - Closing remarks and where to find more information about Black Swan Cybersecurity

Follow Dr. Mike Saylor on Social Media Linkedin: https://www.linkedin.com/in/misaylor/

The panel also discusses the evolution of TypeScript, its widespread adoption, and its role in shaping the modern web development landscape. They explore the nuances between JavaScript and TypeScript, the friction that developers sometimes face when working with types, and how TypeScript has grown into a default tool for many projects.

Chapters

00:00 - Introduction and Co-Host Introductions 00:47 - Guest Introduction: Nick Taylor 01:37 - The Current State of Open Source 02:50 - Funding Challenges in Open Source 03:54 - Open Source Success Stories and Funding Examples 05:35 - Open Source Burnout and Quiet Quitting in Tech 06:43 - Challenges for Open Source Maintainers 07:26 - Motivation and Incentives for Contributing to Open Source 08:35 - Career Benefits of Open Source Contributions 10:11 - Nick’s Journey into Open Source Contributions 12:38 - The Burden of Managing Popular Open Source Projects 14:27 - Hacktoberfest and Low-Quality Contributions 16:14 - Challenges for Beginners Contributing to Open Source 18:01 - The Impact of Hacktoberfest and Mitigating Spam PRs 20:12 - TypeScript's Rise in Popularity 23:16 - Why TypeScript Became Popular in Open Source
25:45 - The Debate Around Static Typing in JavaScript
27:08 - TypeScript vs. JavaScript: Future Considerations 30:21 - The Role of Build Steps in Modern Development Frameworks
33:35 - The Complexity of TypeScript for Different Developer Levels
36:12 - Enum Usage and TypeScript's Type System 38:53 - TypeScript’s Structural Typing and Its Implications
39:47 - Nick’s Contact Information and Closing Remarks

Follow Nick Taylor on Social Media Twitter: https://x.com/nickytonline Linkedin: https://www.linkedin.com/in/nickytonline/ Github: https://github.com/nickytonline

Chapters 00:00 - Introduction 01:00 - Transition from CTO to CPO 03:00 - Understanding Users in Product Development 06:00 - Role of Personas in Building for Users 09:00 - The Balance of Serving Current and Future Users 11:30 - Challenges of Startups and Growing with Users 14:00 - Product vs. Engineering: The What and the How 17:00 - Blending Product and Engineering Roles 21:00 - Encouraging Product Mindedness in Engineers 24:00 - The Importance of Understanding Users in Tech 28:00 - Industry-Specific Challenges for Technologists 31:00 - Closing Remarks

Follow Stacie Frederick on Social Media: Linkedin: https://www.linkedin.com/in/stacie-frederick/

Sponsored by This Dot

Chapters

1. Shivay’s Journey into Machine Learning (00:00 - 03:30)
2. The Power of TensorFlow.js and Web AI (03:31 - 07:00)
3. Challenges in Hackathons: Using Pre-trained Models (07:01 - 10:00)
4. Navigating the AI Ecosystem: Python vs. JavaScript (10:01 - 13:30)
5. LLMs and Their Growing Popularity (13:31 - 17:00)
6. The Importance of Core Machine Learning Knowledge (17:01 - 20:00)
7. AI Ethics & Challenges in Scaling Models (20:01 - 23:00)
8. Shivay’s Content & Community Involvement (23:01 - 25:00)
9. Conclusion & Final Thoughts (25:01 - End)

Follow Shivay on Social Media Twitter: https://x.com/HowDevelop Github: https://github.com/shivaylamba

Sponsored by This Dot: thisdot.co

Chapters

1. Introduction and Tech Career Journeys (00:00 - 02:30)
2. The Struggles of Breaking Into Tech (02:31 - 06:00)
3. Jason’s Career Pivot from Film to Tech (06:01 - 10:30)
4. The Importance of Networking and Community (10:31 - 15:00)
5. Specializing vs. Being a Generalist in Tech (15:01 - 20:00)
6. Finding Your Path in Tech (20:01 - 25:30)
7. Dealing with Imposter Syndrome and Belonging (25:31 - 30:00)
8. Final Thoughts and Tips for Breaking Into Tech (30:01 - 33:00)
9. Closing Remarks and Tech Talk Humor (33:01 - End)

Follow Jason Torres on Social Media Twitter: https://x.com/TasonJorres Linkeidn: https://www.linkedin.com/in/thejasontorres/

Sponsored by Wix Studio: https://www.wix.com/studio

Chapters

00:00 - Introduction and Episode Overview 02:59 - The Importance of Unit Testing 10:03 - Best Practices for Implementing Unit Tests 17:15 - TypeScript’s Role in Code Safety and Productivity 2:30 - AI in Software Development: Automating Tasks 29:16 - Balancing AI Automation with Developer Expertise 32:07 - Final Thoughts and Closing Remarks

Sponsored by This Dot: thisdot.co

Baptiste takes over with a live demo, showcasing how to create a website from scratch using Nuxt Studio. He demonstrates the platform’s powerful content management features, showing how Nuxt Content integrates to manage and edit website content easily. Baptiste highlights Nuxt UI components and how they simplify coding by providing ready-to-use elements. The demo also features live editing and previews, making collaboration easier for both technical and non-technical users. Ferdinand wraps up by emphasizing Nuxt Studio’s user-friendly design and hints at exciting future updates, including branch management and internationalization support. This session highlights Nuxt Labs' commitment to enhancing the Vue.js ecosystem with versatile, user-focused tools.

Follow Baptiste Leproux and Ferdinand Coumau:

Baptiste Twitter: https://x.com/larbish Ferdinand Twitter: https://x.com/CoumauFerdinand Baptiste Linkedin: https://www.linkedin.com/in/baptiste-leproux-618842b0/ Ferdinand Linkedin: https://www.linkedin.com/in/ferdinand-coumau-nuxt/

Sponsored by This Dot

Chapters

• 00:00 - Introduction
• 00:57 - The Angular Renaissance
• 02:24 - Signals in Angular
• 03:27 - Transitioning to Signals
• 04:19 - Signals in Utility Development
• 05:09 - RxJS and Signals
• 07:52 - Signals vs Other State Management Solutions
• 09:34 - Testing Signals
• 10:29 - Control Flow and Standalone Components in Angular
• 12:02 - Angular's Evolution and Accessibility
• 13:28 - Angular’s Framework Governance
• 17:10 - Hiring in the Age of AI
• 19:15 - Pair Programming and Real-Time Problem Solving
• 22:24 - The Role of AI in Interviews
• 27:58 - Wrapping Up

Follow Braydon Coyer Twitter: https://x.com/BraydonCoyer Linkedin: https://www.linkedin.com/in/braydon-coyer/ Github: https://github.com/braydoncoyer

Chapters

• 00:00 - Introduction
• 01:00 - Brian on GenAI in the Java Community
• 01:47 - Java’s Safe Evolution Path
• 02:17 - Teresa on Project Valhalla
• 03:54 - Value Classes and Performance
• 04:33 - Brian on Semantic Caching
• 06:54 - Challenges of Rewording Prompts
• 09:15 - What is RAG Architecture?
• 11:34 - Java’s Role in AI
• 13:57 - Cost of LLMs and Caching Strategies
• 15:57 - Teresa on Java’s Future
• 18:22 - Learning Resources for Java Developers
• 20:44 - Addressing Misconceptions About Java
• 22:39 - Final Thoughts

Follow Theresa Mammarella & Brian Sam on Social Media Theresa Mammarella Twitter: https://x.com/t_mammarella Brian Sam-Bodden Twitter: https://x.com/bsbodden Theresa Mammarella Linkedin: https://www.linkedin.com/in/tmammarella/ Brian Sam-Bodden Linkedin: https://www.linkedin.com/in/sambodden/

Chapters

• 00:00 - Introduction
• 01:00 - The Origins of Netlify
• 02:30 - Netlify’s Growth Journey
• 04:00 - Impact of Netlify on the Web Ecosystem
• 05:30 - Building the Right Team
• 07:45 - From Developer to CEO: Evolving as a Leader
• 10:00 - The Balance Between Vision and Operations
• 12:00 - Delegating vs. Staying Hands-On
• 15:30 - Hiring Experienced Leaders
• 18:00 - Building Diverse Teams
• 20:00 - Intuition in Leadership
• 22:30 - Simplifying Goals and Objectives
• 25:00 - The Shift in Tech Leadership
• 28:00 - Changing Expectations for Engineers
• 30:00 - Advice for Startup Founders
• 32:00 - Where to Find Matt Online
• 33:00 - Conclusion

Follow Matt Biilmann on Social Media Twitter: https://x.com/biilmann Linkedin: https://www.linkedin.com/in/mathias-biilmann-christensen-a5a3805/ Github: https://github.com/biilmann

Sponsored by This Dot: thisdot.co

Chapters

• 00:00 - Introduction and Guest Welcome
• 00:48 - Jeremy’s Background and Career Journey
• 01:51 - Introduction to DeVos and Its Founders
• 02:30 - Throwback: Reddit Meetups and "Chad Berg" Chanting
• 03:05 - Rebuilding the Reddit Engineering Team
• 05:16 - Challenges of Scaling and Maintaining Reddit's Culture
• 07:08 - The Role of Code in Driving Team Culture
• 08:14 - Differences in Team Dynamics at Reddit and Netflix
• 09:07 - Working at Netflix vs. Cloudflare
• 09:38 - The "Sports Team, Not a Family" Philosophy at Netflix
• 11:21 - Understanding the Keeper Test at Netflix
• 14:27 - Evolving Netflix's Culture to Support Diversity and Inclusion
• 16:05 - Misconceptions About Netflix's Work Environment
• 17:17 - Work-Life Balance at Netflix: High Performance in a Chill Setting
• 20:28 - Key Elements of a Good Engineering Culture
• 23:09 - How Jeremy's Leadership Style Has Evolved
• 24:34 - Advice for Building Successful Engineering Teams
• 25:26 - Closing Remarks and Sponsor Thanks
• 26:13 - Where to Follow Jeremy Online

Follow Jeremy Edberg Twitter: https://x.com/jedberg Linkedin: https://www.linkedin.com/in/jedberg/

Sponsored by Wix Studio: wix.com/studio

Chapters

• 00:00 - Introduction and Guest Welcome
• 01:30 - Talking Weather and Life in the Midwest
• 03:00 - Exploring Generative AI and Practical Applications
• 06:45 - Navigating Cloud Costs and Scalability Considerations
• 08:30 - Maintaining Creativity and Customization with AI
• 11:00 - Managed Services vs. On-Prem Infrastructure Debate
• 15:30 - Choosing a Tech Stack for Side Projects and Startups
• 18:45 - Learning Cloud: Paths for Full-Stack Cloud Development
• 22:30 - The Role of Cloud Certifications in Today's Market
• 26:00 - Preview of Michael’s Upcoming Talks at AWS re:Invent
• 32:00 - Where to Find Michael Online

Follow Michael Liendo on Social Media Twitter: https://x.com/focusotter Linkedin: https://www.linkedin.com/in/focusotter/

Sponsored by Wix Studio

Chapters

• [00:00 - 00:25] Introduction
• [00:26 - 01:11] Challenging the Healthcare Status Quo
• [01:12 - 03:17] The Evolution of Healthcare Delivery Models
• [03:18 - 06:30] Technology’s Role in Revolutionizing Healthcare
• [06:31 - 10:19] Breaking Free from Outdated Coding Systems
• [10:20 - 12:16] AI and Risk Prediction in Healthcare
• [12:17 - 15:36] Enhancing Care Through Technology and Telemedicine
• [15:37 - 19:02] The Future of Telemedicine and Sustainable Models
• [19:03 - 22:37] Innovating Healthcare Accessibility and Affordability
• [22:38 - 26:56] People Problems: The Biggest Barrier to Healthcare Innovation
• [26:57 - End] Final Thoughts and Closing Remarks

Follow Anita Ballaney on Social Media Linkedin: https://www.linkedin.com/in/anitab/ MyHealthQ: https://myhealthq.com/about-us/

Sponsored by This Dot

Chapters

• [00:00 - 00:25] Introduction and Welcome
• [00:26 - 01:07] Guest Introduction: John Crichton
• [01:08 - 02:21] The Lack of Standardization in EMRs
• [02:22 - 02:52] Challenges in Clinical Trials and EMR Data
• [02:53 - 04:28] Balancing Innovation and Compliance in Healthcare
• [04:29 - 06:51] The Impact of Shifting Compliance and Privacy Concerns
• [06:52 - 07:10] The AI and Data Privacy Challenge in Healthcare
• [07:11 - 09:43] Integrating AI While Ensuring Data Security
• [09:44 - 12:33] Leveraging AI for Developer Productivity and Clinical Efficiency
• [12:34 - 15:13] AI in Enhancing Patient Care: Lightning Intelligent Assistant
• [15:14 - 16:41] Ethical Considerations Around AI in Healthcare
• [16:42 - 19:00] Comparing Regulatory Challenges: Financial Services vs. Healthcare
• [19:01 - 21:22] Healthcare Records and Financial Records: Privacy and Security
• [21:23 - 24:00] The Role of AI in Agile Development Processes
• [24:01 - 26:21] Leadership Lessons: Mentorship and Servant Leadership
• [26:22 - 29:12] Building a High-Performing Team Through Culture and Leadership
• [29:13 - End] Closing Remarks and Where to Find John Crighton

Find John Crighton on Social Media Linkedin: ⁠https://www.linkedin.com/in/johncrighton/ Lightning Step Technologies: ⁠https://lightningstep.com/

Sponsored by This Dot.

Chapters

-

• Introduction & Tanner’s Background (00:00)
• Going Full-Time on TanStack (01:00)
• The Birth of TanStack Router (02:21)
• Why Build Another Framework? (04:00)
• React Server Components: Potential & Limitations (07:05)
• Fine-Grained Cache Invalidation & UX (09:02)
• Parallel Data Fetching in Routing (13:39)
• TanStack Start: Alpha & Future Plans (16:41)
• Where to Learn More About TanStack (18:48)

Find Tanner Linsley on Social Media Twitter: https://x.com/tannerlinsley Linkedin: https://www.linkedin.com/in/tannerlinsley/ Github: https://github.com/tannerlinsley TanStack: https://tanstack.com/

Sponsored by Wix Studio

Chapters

• 00:00 - 01:32 — Introduction to Leadership and Product Management
• 01:33 - 04:16 — The Early Days: From Georgia Tech to Startup Success
• 04:17 - 08:03 — Product Strategy and Roadmap Essentials
• 08:04 - 12:23 — The Power of Adaptable Roadmaps
• 12:24 - 16:30 — Managing Tech Debt and Security in Roadmaps
• 16:31 - 19:52 — The Commercial Lens: Monetizing Features and Value Creation
• 19:53 - 23:23 — Balancing Innovation and Maintenance
• 23:24 - 27:29 — Aligning Product Teams with Company Goals
• 27:30 - End — Final Thoughts: Roadmap Wisdom and Career Advice

Follow Ty Allen on Social Media Linkedin: https://www.linkedin.com/in/tylerallen/

Sponsored by This Dot: thisdot.co

Chapters

Here are the timestamped chapters for the episode:

• 00:00 - Introduction and Technical Setup Issues
• 01:05 - Guest Introduction: Kevin Powell
• 02:00 - Kevin's Journey into CSS and Content Creation
• 03:21 - Evolution of CSS: From CSS3 to Modern Features
• 05:46 - The Role of JavaScript in CSS and New Features
• 08:08 - Popovers, Anchor Positioning, and Progressive Enhancement in CSS
• 10:26 - Discussion on SAS, Tailwind, and CSS Tools
• 12:35 - Challenges with Tailwind and Over-Componentization
• 14:57 - The Importance of Learning Core CSS Principles
• 16:56 - The "CSS is Hard" Memes and Overcoming CSS Frustration
• 19:12 - Formatting Contexts and Advanced CSS Concepts
• 21:31 - Opportunities for Junior Developers to Master CSS
• 23:54 - Browser Discrepancies and the Future of Web Standards
• 26:14 - Refactoring CSS for Performance and Best Practices
• 27:50 - Favorite CSS Resources and Conferences
• 28:26 - Imposter Syndrome and Kevin's Speaking Journey
• 29:55 - Closing Remarks and Where to Find Kevin Powell Online

Follow Kevin Powell on Social Media Twitter: https://x.com/KevinJPowell Github: https://github.com/kevin-powell YouTube: https://www.youtube.com/kevinpowell

Sponsored by This Dot.

Chapters:

• 00:00 - 01:32 Introduction to the Modern Web Podcast and Guests
• 01:33 - 04:00 Overview of Fly.io and Annie’s Role as Developer Advocate
• 04:01 - 06:35 What Makes Fly.io Stand Out Among Cloud Platforms
• 06:36 - 08:57 Distributed Applications: Benefits and Use Cases
• 08:58 - 11:28 Understanding Distributed Web Servers and Private Networking
• 11:29 - 13:49 Challenges in Distributed Data and Replication Techniques
• 13:50 - 16:12 Fly.io’s Unique Solutions for Data Consistency
• 16:13 - 18:34 When to Consider a Distributed Setup for Your Application
• 18:35 - 20:35 Tools and Tips for Evaluating Geographical Distribution Needs
• 20:36 - 22:22 Simplifying Global Deployment with Fly.io’s Command Features
• 22:23 - 24:18 Considerations for Latency and Performance Optimization
• 24:19 - 26:45 Balancing Simplicity with Advanced Control for Developers
• 26:46 - 29:04 Easy Deployment for Hobbyists and Smaller Projects
• 29:05 - 31:27 Getting Started on Fly.io with Fly Launch
• 31:28 - 33:48 Developer Advocacy and Meeting Diverse Needs in the Cloud
• 33:49 - 36:15 Catering to Beginners and Experienced Developers Alike
• 36:16 - End Closing Remarks and Where to Find Fly.io and the Hosts

Follow Annie Sexton on Social Media Linkedin: ⁠https://www.linkedin.com/in/annie-sexton-11472a46/⁠ Github: ⁠https://github.com/anniebabannie⁠

Sponsored by This Dot: thisdot.co

Chapters

• Introduction to the Leadership Exchange (00:00 - 00:23)
• Scott’s Journey to CTO (00:23 - 02:15)
• Cyclical Trends in Tech (02:15 - 03:27)
• The Challenges of Leadership (03:27 - 06:07)
• The Purpose of Process (11:43 - 14:09)
• Process vs. Output: What Really Matters (14:09 - 17:20)
• Building vs. Buying Process Frameworks (17:28 - 20:57)
• The Role of Adaptation in Process Improvement (20:57 - 24:08)
• Navigating ‘Religious’ Arguments in Process (24:08 - 27:02)
• Defining a Team’s Unique Process (27:02 - 29:41)
• Wrapping Up and Final Thoughts (29:41 - 30:40)
• Thank You to Sponsors (30:40 - End)

Follow Scott Roehrenbeck on Social Media Linkedin: https://www.linkedin.com/in/scott-roehrenbeck-5a573431/

Chapters

• 0:32 Project Overview – Jack explains the AI-powered character recognition project
• 2:17 Setting Up the Project – Overview of how the application is structured and initial setup
• 3:04 Client-Side AI – How face detection and character recognition work on the client side
• 5:12 Switching to Server Side – Jack demonstrates server-side AI and setting up API endpoints
• 8:20 Explaining AI Tooling – How tools and prompts are used to give context to the AI
• 10:01 Detailed Prompt Structure – Breaking down the prompt and character context for AI responses
• 12:40 Client-Server Interaction – Using the Versal AI library to manage streaming responses
• 15:09 Handling Character Data – Training the AI on specific character images and details
• 18:15 Practical Use Cases – Discussing potential real-world applications for the face recognition tool
• 21:34 Challenges and Lessons Learned – Jack shares obstacles he faced and how he overcame them
• 25:45 Building the API – Tips and considerations for creating reliable API endpoints
• 28:40 Handling User Inputs – Testing unexpected questions and how the AI responds
• 32:00 Using Advanced AI Models – Jack talks about choosing GPT-4 and issues with smaller models
• 35:47 Introducing ProNextJS.dev – Jack discusses his new Next.js course, covering advanced topics
• 37:20 Closing Thoughts – Danny and Jack wrap up with final thoughts and a link to the GitHub repo

Follow Jack Herrington on Social Media Twitter: https://x.com/jherr Linkedin: https://www.linkedin.com/in/jherr/ YouTube: https://www.youtube.com/@jherr

Sponsored by This Dot: thisdot.co

Chapters

• Introduction to the Podcast and Guests 00:01
• Meet Ankita Kulkarni, Tech Educator 00:26
• Ankita's Transition to Full-Time Education 01:41
• Teaching Practical Knowledge in Next.js 03:19
• Effective Methods for Teaching Next.js 05:27
• Challenges of Being a Full-Time Educator 07:48
• Balancing Broad and Specific Examples 09:54
• Embracing Mistakes as a Teaching Tool 12:13
• Pair Programming and Mentorship 14:00
• Discussion on Next.js and Framework Adoption 16:48
• Advantages and Challenges of Next.js 18:12
• Choosing the Right Framework for Your Needs 20:35
• Impact of Next.js in React Documentation 22:26
• Learning Paths for New Developers 23:24
• The Rise of Full-Stack Web Development 25:09
• Benefits of Frameworks Abstracting Complexity 26:27
• OpenNext and Deployment Flexibility 28:06
• Ankita's Excitement for New Next.js Features 30:35
• The Future of Next.js Without Vercel 32:16
• Final Thoughts and Where to Find Everyone Online 34:21

Follow Ankita Kulkarni on Social Media Twitter: https://x.com/kulkarniankita9 YouTube: https://www.youtube.com/@kulkarniankita

Sponsored by This Dot: thisdot.co

In this Video, Nina reviews the setup process, discussing the critical roles of API keys and service accounts. API keys secure access to Google Drive, while service accounts facilitate interactions with Astra DB. This setup ensures seamless data access and processing, establishing a robust foundation for Unstructured's operations. She explains how to set up an efficient notebook environment, focusing on library installations, Google Drive connectivity, and security configurations.

Emphasizing collaboration, this setup ensures seamless teamwork, enabling Unstructured to efficiently structure and analyze data. During setup, viewers learn to execute code in Google Colab, a cloud-based platform. Troubleshooting API keys underscores the importance of proper configuration for smooth data processing.

Chapters 00:00 – Introduction
00:31 – Jerry’s Leadership Journey
02:01 – Discussing AI in Leadership
03:59 – Experimenting with AI Tools
06:24 – Overcoming Analysis Paralysis
09:18 – Importance of Early AI Adoption
13:12 – AI’s Impact on Efficiency
14:30 – Sponsor Message
16:26 – Setting Realistic Goals for AI
19:41 – Data Management and AI
23:09 – Is AI Just a Fad?
27:22 – Testing New Technologies
29:56 – Final Thoughts on AI
30:25 – Connect with Jerry
30:44 – Closing Remarks
31:20 – Outro

Follow Jerry on Social Media Linkedin: https://www.linkedin.com/in/jerrymannel/

Sponsored by This Dot: thisdot.co

Ferdinand and Baptiste share how Nuxt Studio bridges the gap between developer customization and user-friendly content management. Built to empower agencies, freelancers, and their clients, Nuxt Studio combines powerful features like live previews, Vue component integration, and schema-driven forms to make managing content seamless.

The conversation also explores the broader mission of Nuxt Labs—building sustainable open-source tools that enhance developer experience and meet real-world needs. With insights into the future of Nuxt Studio and its potential to scale for larger organizations, this episode is a must-listen for anyone passionate about innovation in web development.

Chapters

1. Introduction and Setting the Stage (00:00:00)
2. The Vision Behind Nuxt Studio (00:03:10)
3. Nuxt Studio’s Core Features (00:08:45)
4. Challenges in Building Nuxt Studio (00:16:20)
5. Target Audience and Use Cases (00:22:35)
6. Sustainability in Open Source (00:29:00)
7. The Future of Nuxt Studio (00:35:10)
8. Nuxt Studio’s Role in the Nuxt Ecosystem (00:42:30)
9. Closing Thoughts and What’s Next (00:48:00)
10. Sponsor Shoutout and Wrap-Up (00:53:20)

Follow Baptiste Leproux and Ferdinand Coumau Baptiste Twitter: https://x.com/_larbish Ferdinand Twitter: https://x.com/CoumauFerdinand Baptiste Linkedin: https://www.linkedin.com/in/baptiste-leproux-618842b0/ Ferdinand Linkedin: https://www.linkedin.com/in/ferdinand-coumau-nuxt/

Sponsored by This Dot: thisdot.co

Chapters 00:00:04 Welcome & Introductions
00:00:34 Reflections on Transformation & Innovation
00:01:28 Synergies & Organizational Transformation
00:02:19 Measuring Success in Cultural Transformation
00:05:07 Empowering Individuals & Leadership Growth
00:08:07 Emerging Innovations: Generative AI in Fraud & Risk
00:10:15 Security Investments & AI's Industry Impact
00:12:28 The Future of Privacy-Enhancing Technologies
00:15:30 Sustaining Momentum in Transformation
00:18:28 The Industry’s Pragmatic Shift
00:20:39 Inclusive Innovation & Cultural Change
00:23:12 Advocating for Yourself & Your Ideas
00:25:27 Leaders as Coaches: The Power of Feedback
00:28:56 Sponsor Spotlight: This Dot
00:29:53 Where to Connect with Dondi
00:30:39 Closing Remarks

Follow Dondi Black on Social Media Linkedin: https://www.linkedin.com/in/dondi-black/

Sponsored by This Dot: thisdot.co

Chapters 00:00:13 - Introduction to Marketing This Dot 00:01:00 - Asking for Help Effectively 00:02:21 - Reducing On-Call Fatigue 00:04:42 - Observability Best Practices 00:07:07 - Balancing Alerts and On-Call Efficiency 00:09:30 - The Role of On-Call in Modern Engineering 00:11:29 - Insights from the Grace Hopper Celebration 00:13:56 - Mentorship and Team Dynamics 00:16:14 - Rapid Changes in Technology and Adaptation 00:18:39 - Automation, Observability, and Debugging Challenges 00:21:04 - Addressing the Talent Gap and Junior Engineer Growth 00:24:00 - Closing Thoughts and Where to Learn More

Follow Dr. Sally Wahba on Social Media Twitter: https://x.com/sallyky Linkedin: https://linkedin.com/in/sallywahba/

Sponsored by This Dot: thisdot.co

Chapters [00:00:00] Introduction to JS Drop [00:02:30] Tejas Kumar’s AI Presentation Overview [00:05:00] Demo: Traditional Keyword Search vs. AI Search [00:09:30] Building AI-Driven Search with DataStax Astra and Vercel AI SDK [00:16:00] Generating React Components with AI [00:24:30] Exploring Advanced AI Tools: WebSim and Beyond [00:32:00] Connecting DataStax Astra with AI Models [00:39:00] Best Practices for AI-Powered Development [00:45:00] Q&A and Final Thoughts

Follow Tejas on Social Media Twitter: https://x.com/TejasKumar_ Linkedin: https://www.linkedin.com/in/tejasq/ Github: https://www.linkedin.com/in/tejasq/ ConTejas Podcast: https://www.youtube.com/playlist?list=PLEJpU2pV0Lie1VWU1unMg_7FRQ1gqFmAZ

Chapters

• 00:00 - Introduction and Guest Introduction
• 01:30 - Balancing Work and Parenthood
• 03:20 - Family-Friendly Conferences and THAT Conference Experience
• 05:45 - Overview of Sarah's Presentation on Color Theory
• 07:00 - Understanding Additive and Subtractive Color Models
• 09:00 - RGB to Hex Conversion Explained
• 11:45 - Importance of Color Theory in Web Development
• 14:00 - Accessibility and Color Luminescence
• 16:00 - Tools and Resources for Color Accessibility
• 18:30 - Sarah’s Experience with Vue and Other Frameworks
• 21:00 - Discussion on Framework Deployment and Tooling
• 23:15 - The Challenges and Benefits of Learning Multiple Frameworks
• 25:00 - Tailwind, TypeScript, and Framework Preferences
• 27:00 - Vue Community and Tooling Insights
• 29:00 - Advanced JavaScript and TypeScript Content with DropJS
• 31:00 - Sarah’s Color Utility Project and Where to Find Her
• 32:30 - Closing Thoughts and Outro

Follow Sarah Shook on Social Media Twitter: https://x.com/shookcodes Linkedin: https://www.linkedin.com/in/sarahshook/ Github: https://github.com/shookcodes

Sponsored by Wix Studio

Chapters Introduction and Overview - 00:00 Introduction to the React Compiler - 02:27 Manual Optimization with useMemo and useCallback - 09:27 Setting Up the React Compiler - 26:00 Analyzing Compiler Output - 44:50 Exploring the Playground and Generated Code - 50:47 Handling Skipped Components and Memoization - 58:18 Discussion on React's Future and Best Practices - 01:03:28 Q&A and Audience Interaction - 01:10:53 Conclusion and Final Thoughts - 01:15:38

Follow Jesse Tomchak on Social Media Twitter: https://x.com/jtomchak Linkedin: https://www.linkedin.com/in/jtomchak/ Mastodon: https://moth.social/@jtomchak Github: https://github.com/jtomchak

Ivan stresses the importance of adaptability in the evolving field of QA. He highlights the need for QA professionals to stay updated with the latest trends and technologies and to be willing to adapt their strategies accordingly. Ivan also emphasizes the effective utilization of available resources, such as automation tools, to streamline QA processes and improve efficiency. He believes automation can significantly reduce manual effort and allow QA teams to focus on more critical aspects of testing.

Along with host Rob Ocel, he also discusses the limitations of AI in understanding user experiences. While AI can be a powerful tool in automating certain aspects of testing, Ivan emphasizes the need for human intervention to ensure accurate results. He believes that AI should be seen as a complement to human testers, rather than a replacement. Ivan also shares his vision for the future, where AI will play a more significant role in augmenting testing processes, but human expertise will remain crucial for ensuring quality.

Download this episode here

Both Jimmy and Tracy stress the importance of a flat team structure, which fosters professional development and encourages collaboration among team members. As technology continues to evolve, so do business practices. It is crucial for engineering leaders to adapt and embrace new technologies and methodologies.

Tracy Lee and Jimmy Jacobson's podcast provides valuable insights into the world of engineering leadership, technology, and business. From the importance of hiring experienced engineers and product managers to the evolution of business practices, their discussions shed light on the strategies and approaches that drive success.

Download this episode here.

By adopting a systematic approach, businesses can effectively identify and address customer needs. Design thinking, on the other hand, encourages a human-centered approach to innovation, ensuring that technology solutions are not only functional but also user-friendly. Ankur insights remind us that successful technology implementation requires a deep understanding of customer pain points and a commitment to delivering effective solutions.

In an era where data is abundant, Ankur emphasizes the value of making data-driven decisions. However, he cautions against relying on biased data, which can lead to flawed conclusions. He advises businesses to carefully analyze and interpret data, ensuring that it aligns with the goals and objectives of the organization. By leveraging data effectively, businesses can gain valuable insights, make informed decisions, and drive growth.

Ankur highlights the significance of ensuring product-market fit by closely collaborating with early customers. By actively involving customers in the development process, businesses can gain valuable feedback and insights, ensuring that their products or services meet the needs of the target market. Ankur's emphasis on customer collaboration serves as a reminder that successful technology implementation requires a customer-centric approach, where the end-users' needs and preferences are at the forefront of decision-making.

Ankur advocates for mentorship and continuous learning in leadership roles. He emphasizes the value of seeking guidance from experienced professionals and gradually growing within organizations. His insights remind us that leadership is a journey of growth and development, and that embracing mentorship and continuous learning can help individuals navigate the complexities of technology leadership more effectively.

Download this episode here.

Chapters

00:00 Introduction and Background 02:41 Preparing for a 90-Minute Keynote 05:37 Writing a Book and Other Projects 08:04 Surrounded by Ambitious People 09:01 Personal Stories and Balance 10:22 Lessons from Domo and Joe Eames 11:21 Learning from Experienced Engineers 12:41 The Importance of Surroundings 13:33 Choosing the Right People to Associate With 14:46 Kent's Organizational Skills 15:41 Balancing Work and Family 17:06 Committing to Big Things 18:04 Avoiding Burnout and Assessing Priorities 19:26 Sharing Personal Stories in Talks 20:21 Finding Effectiveness and Efficiency 21:17 Dealing with Burnout and Overwhelm 22:46 The Entrepreneurial Mentality 23:15 Running to the Top and Figuring It Out 24:14 Kent's Various Projects 25:41 Transitioning from Angular to React

Follow Kent C Dodds on Social Media Twitter: https://x.com/kentcdodds Linkedin: https://www.linkedin.com/in/kentcdodds/ Bluesky: https://bsky.app/profile/kentcdodds.com GitHub: https://github.com/kentcdodds

EpicWeb.dev: https://www.epicweb.dev/ EpicReact.dev: https://www.epicreact.dev/

Learn More About THAT Conference Wisconsin 2024: https://thatconference.com/wi/2024/

Listen to this episode here.

Sponsored by Wix Studio

A significant portion of the discussion is devoted to Mark's motto of "Do what matters with who matters while it matters." This practical approach encourages listeners to focus on meaningful work, prioritize important relationships, and make the most of their time. Mark also reflects on the challenges of maintaining resilience in the face of personal adversity, offering a candid look at how to balance personal and professional life effectively.

Listeners will find actionable advice on how to take control of their career trajectory, foster a positive work culture, and navigate the complexities of leadership, all while staying true to themselves.

Chapters [00:00] Introduction [02:19] Personal Branding and Online Presence [06:36] Navigating Workplace Culture [08:56] The Story Behind 'Well Dressed Wednesdays' [11:12] Developing the "Do What Matters" Framework [13:29] Balancing Public and Private Life [18:10] Overcoming Personal Challenges [20:28] Taking Control of Your Career [22:49] Practical Takeaways for Listeners

Follow Mark on Social Media Twitter Linkedin Github Bluesky

Sponsored by Wix Studio.

Angela emphasizes that customer service and a positive work culture form the foundation of company success. By fostering humility and transparency, leaders create environments where employees feel valued and motivated to deliver outstanding service. Angela stresses the importance of building collaborative teams, nurturing healthy relationships, and addressing toxic cultures promptly, ensuring organizations thrive on trust and respect.

In this conversation, Angela believes that trust is a cornerstone of successful company culture. Building trust among team members and leaders encourages innovation and growth. Investing in employee development, both personally and professionally, fosters a motivated, engaged workforce committed to the organization's success, and helps retain great talent.

Throughout the episode, Angela emphasizes that effective communication and shared vision are paramount in leadership. Promoting transparency and open dialogue cultivates trust and collaboration. By embracing failures as opportunities for growth and openly discussing lessons learned, leaders foster environments where employees feel empowered to take risks and learn. Shared vision ensures alignment with the company's goals and values throughout the organization.

Download this episode here.

Lee stresses the significance of optimizing the content supply chain and user testing to ensure a seamless user experience. In an arena where scientific information holds paramount importance, presenting it in an easily accessible and comprehensible manner for healthcare professionals is essential. By integrating user feedback and conducting thorough testing, pharmaceutical companies can refine their digital platforms to meet the diverse needs of stakeholders, encompassing medical science liaisons, patients, researchers, and physicians.

A notable takeaway from the dialogue is the necessity for customized solutions tailored to the distinct requirements of various stakeholders within the pharmaceutical industry. Each faction possesses unique needs and preferences concerning the access and utilization of scientific content. By comprehending these specific needs, pharmaceutical entities can develop user-friendly interfaces that resonate with the preferences of each stakeholder group. This approach not only enhances user experience but also bolsters the overall efficacy of digital platforms.

Lee Dash shares the significance of assembling a versatile development team equipped with multifaceted skills. In an industry characterized by rapid evolution, having a team capable of adapting to shifting technologies and user expectations is imperative. Additionally, Lee talks about the importance of infusing technical acumen into leadership teams. By cultivating leaders well-versed in the technical intricacies of digital innovation, pharmaceutical companies can drive efficient and effective development processes.

Download this episode here.

Firstly, Leon emphasizes the need for organizations to cultivate a blame-free atmosphere, encouraging team members to take risks and glean insights through failure. By reframing mistakes as learning opportunities, teams foster a culture that fuels growth and innovation. This approach not only instills a sense of ownership among individuals but also nurtures psychological safety, paving the way for enhanced idea-sharing and collaboration.

Secondly, Tracy and Leon underscore the pivotal role of transparent communication within teams. Through fostering honest dialogue, organizations can strengthen trust and deepen connections among team members. Such open communication fosters collective accountability, where each member bears responsibility for the team's triumphs. Empowering individuals to voice their thoughts and concerns fosters an environment where diverse perspectives are valued, ultimately enhancing decision-making and problem-solving.

Moreover, Leon offers examples of how organizations can drive continuous improvement by empowering their teams. Providing individuals with the autonomy to make decisions and take ownership not only spurs personal growth but also bolsters team success. By nurturing a growth mindset and facilitating skill development, organizations foster a culture that embraces learning and adapts to change.

The interview touches on the evolving technology landscape and its implications for team collaboration. With the emergence of artificial intelligence and automation, Revill stresses the importance of aligning development processes with these advancements. Collaboration becomes imperative in this scenario, as teams must collaborate to grasp and implement these technologies effectively. Through cultivating a culture of trust and collaboration, organizations can navigate technological shifts and remain at the forefront of innovation.

Download this episode here.

Contenda's current product focus is Brain Story, an app that utilizes AI to help people brainstorm ideas.

Rob and Cassidy highlight the importance of having "bad ideas" and normalizing them. Cassidy shares her team’s Slack channel called “bad ideas”. This channel allows team members to freely share and discuss ideas without fear of judgment. It fosters a culture of creativity and encourages everyone to contribute their thoughts, even if they may not initially seem like the best ideas.

Adaptability and the ability to pivot are emphasized throughout the episode as Cassidy highlights the importance of being able to adapt and pivot in both life and career.

Cassidy's experiences and advice serve as a reminder that success often comes from embracing new ideas, collaborating with others, and being willing to adapt.

Listen to the full episode here: https://engineeringleadership.podbean.com/e/bad-ideas-are-good-ideas-with-cassidy-williams-cto-of-contenda/

Central to effective leadership is a comprehensive understanding of the company's overarching strategy. Leaders must expand their influence beyond their immediate team and align their efforts with the organization's goals. Transparent decision-making and communication are paramount. Adrianna stresses the need for leaders to make trade-offs openly and ensure team alignment through effective communication channels. Being receptive to feedback, willing to reassess decisions, and prioritizing ongoing learning and collaboration are all integral facets of this process.

Finally, Adrianna discusses the art of delegating tasks and the importance of leaders focusing on activities that leverage their unique skills and delegating others effectively. She advocates for a mentorship approach that involves asking questions rather than providing direct answers, empowering team members to develop their problem-solving abilities.

Download this episode here.

Along with Tracy Lee, Revathi discussed the delicate balance between developing new features and maintaining existing products. By managing cost reduction projects and considering technical debt, engineering leaders can ensure that their products remain robust and efficient in the long run.

Revathi also emphasized the role of efficient processes and hiring individuals with the right mindset in driving cultural change within an organization. By implementing streamlined workflows and fostering a collaborative environment, engineering teams can minimize chaos and create a smoother work experience.

Lastly, they talked about the benefits of leveraging artificial intelligence in operations. By harnessing the power of AI, engineering teams can automate repetitive tasks, optimize workflows, and improve overall efficiency. Revathi’s perspective underscores the potential of AI in transforming the way engineering teams operate, enabling them to focus on more strategic and impactful work.

Download this episode here.

Beyond technical skills, empathetic leaders prioritize diverse perspectives and individual strengths in hiring practices, fostering collaboration and inclusivity within teams. The conversation highlighted the shift towards empathy in tech leadership. While traditionally task-oriented, leaders now recognize empathy's positive impact on team morale, creativity, and performance.

How do you prioritize empathy to create a work environment where team members feel valued, understood, and motivated to excel?

Download this podcast episode here.

One of the key points emphasized by Dan Gigangi is the significance of adapting communication styles to cater to different skill levels. Effective communication is essential for fostering collaboration and ensuring that complex technical concepts are understood by all team members. By tailoring their communication approaches, engineering leaders can bridge the gap between varying levels of expertise, creating a cohesive and productive work environment.

Dan highlights the need for senior engineers to make a broader impact beyond coding. While technical expertise is undoubtedly important, engineering leaders should encourage their team members to think beyond their immediate tasks and consider the larger organizational goals. By empowering senior engineers to take on leadership roles and contribute to strategic decision-making, leaders can foster a culture of innovation and drive long-term success.

The conversation between Dan Gigangi and Tracy Lee also emphasizes the importance of setting long-term visions and executing strategic plans for career progression. Engineering leaders should guide their team members in envisioning their professional goals and provide guidance on how to achieve them. By creating a roadmap, leaders can inspire their team members to continuously learn and grow, ultimately driving their own career advancement and contributing to the success of the organization.

Dan also discusses the challenges and pitfalls of transitioning from technical roles to leadership positions. While technical expertise is a solid foundation, engineering leaders must also develop non-technical skills such as communication, relationship-building, and strategic thinking. This transition requires a shift in mindset and the ability to navigate complex organizational dynamics. By recognizing and addressing these challenges, aspiring leaders can better prepare themselves for the demands of leadership roles.

Download this episode here.

To combat this, tighter security measures and continuous authentication are essential. By constantly verifying and validating user identities, organizations can stay one step ahead of potential fraudsters. Rod Boothby also highlighted the need for a developer-focused approach to identity verification. By providing developers with the tools and resources they need, companies like ID Partner Systems aim to streamline the verification process and enhance security. This approach not only ensures a more efficient experience for users but also allows for the integration of behavioral biometrics, which can further strengthen the verification process.

Download this episode here.

To illustrate this concept, Ronald provides examples such as ambassador programs and conferences, which offer useful content and networking opportunities for the community while directly impacting revenue generation. He emphasizes the importance of understanding revenue impact through metrics like conversion rates, retained members, influenced members, and expansion. By measuring these metrics, businesses can effectively gauge the success of their community initiatives and make informed decisions to enhance their strategies.

The presentation emphasizes the value of developer communities in various aspects. Data from the Developer Marketing Alliance supported the notion that developer communities are crucial for feedback gathering, creating ambassador programs, understanding the developer audience, and educating others about products. Ronald stresses the need for effective communication of the business value of community initiatives to stakeholders and advised refining existing programs to maximize value rather than starting from scratch. This approach allows businesses to build upon their current community initiatives and make them even more impactful.

By providing policy-compliant infrastructure and unique services tailored to their requirements, platform engineering teams can showcase their commitment to supporting the success of other teams within an organization. This approach not only fosters trust but also positions platform engineering as a strategic partner rather than just a service provider. By going beyond the basic infrastructure provisioning, the platform engineering team can offer services that help development and product teams streamline their processes and improve efficiency.

Shuchi shares her work at Fiserv where she implemented a chargeback system to track usage and costs effectively, incentivizing better development practices. This not only helped in managing costs but also encouraged teams to optimize their resource utilization, leading to improved overall efficiency and more easily scalable systems. Her platform engineering team recognized the importance of effectively managing financial aspects to secure upfront investment for product development. By implementing a billing system based on gigabyte hours, they aligned costs with usage, enabling teams to have a clear understanding of their resource consumption. This approach not only provided transparency but also incentivized teams to adopt cost-effective practices.

By strategically managing financial aspects, the platform engineering team gained the trust of stakeholders and secured the necessary resources to drive innovation and deliver value to the organization. Shuchi’s journey of platform engineering serves as a valuable example of how a team can transition from being a basic service provider to becoming an innovation partner within an organization. By building trust, offering value-added services, and strategically managing financial aspects, the platform engineering team successfully elevated their role and became a strategic enabler of innovation.

Download this episode here.

Maggie talks about design in the product role and emphasizes the significance of design beyond aesthetics. It's not just about making things look pretty; it's about understanding user needs and creating intuitive experiences. User research skills and customer engagement are becoming essential for engineers, as they need to build products that truly resonate with their target audience.

They talk about companies like Airbnb and Apple are leading the way in this regard and the successful integration of design thinking into their engineering processes, resulting in innovative and user-friendly products. By involving engineers in the entire product development lifecycle, from ideation to delivery, these companies are able to create seamless experiences that delight their customers.

Download this episode and listen now!

Chapters

00:00 Introduction and Guest Introduction 03:24 The Importance of Problem-Solving Process in Interviews 06:32 Guiding and Empowering Junior Engineers 10:20 Understanding Different Interview Processes 19:51 Tips for Success in Interviews 24:57 Collaborative Problem-Solving in Technical Interviews 26:26 The Effectiveness of Secret Questions 29:42 Defining the Interview Process 30:37 The Importance of Authenticity 32:30 Interviewer Training and Feedback 35:18 Selecting the Right Opportunity

Follow Anthony D. Mays Social Media

Twitter Linkedin Github Bluesky

Download this episode here.

Timestamps [00:00:00] Intro. [00:03:10] Refactored code, removed external libraries, streamlined. [00:04:35] Understanding web APIs requires deep knowledge. [00:05:19] Focus on problem solving, not memorization. [00:06:39] Many regions, new technologies, use cases. [00:10:03] React Docs collaboration inspires Angular. [00:12:17] Career advice and success stories.

Social Media Bluesky Instagram Twitter GitHub LinkedIn

Links CascadiaJS Rachel Nabors’ “Alice” Project

Sponsored by This Dot Download this episode here. Read more on our blog!

Jonan Scheffler’s Socials Twitter GitHub YouTube Linkedin

More Resources on DevRel Intro to DevRel: 5 Reasons Why DevRel Teams Fail This is the Worst Thing a DevRel Team Could Do How to Provide Value to Your Organization in a Developer Relations Role

Shownotes [00:00:01] Introduction [00:01:46] Engage developers in constant orbit. [00:03:10] Marketing drives brand awareness for organizations. [00:05:11] DevRel brand disconnect in marketing strategy. [00:08:01] Leverage DevRel to influence and innovate. [00:09:21] Feedback is key for growth. Trust, focus, collaboration. [00:12:19] DevRel measures success by developer engagement. [00:14:35] DevRel trend focused on business dollars. [00:15:39] High-level conferences attract top developers. [00:17:24] Marketing approach: swag and branding.

Listen to this episode on Spotify!

According to Sam, one of the key aspects of developer relations is the ability to bridge the gap between technical and marketing teams. This requires individuals who can effectively communicate the needs and challenges of developers to the marketing team, and vice versa. By fostering this collaboration, businesses can ensure that their products and services align with the expectations and requirements of their target audience.

One of the tools that Sam leverages in his role is AI. He highlights the productivity and efficiency that AI brings to his work, using tools like Writer, ChatGPT, and Co-Pilot for tasks such as content drafting and coding. This showcases the practical applications of AI in the developer relations space, where time is of the essence and accuracy is crucial. Sam emphasizes that while AI tools can greatly enhance productivity, it is important to ensure that they are used ethically and responsibly.

Sam also discusses the challenges faced in transitioning from prototyping to production in the AI space. He highlights the importance of considering ethical implications and democratizing access to AI technology globally. The conversation underscores the need for practical AI applications that deliver tangible value, ensuring that the technology is not only advanced but also accessible and ethical.

The conversation provides valuable insights into the evolving role of developer relations. It highlights the significance of individuals who can bridge the gap between technical and marketing teams and the practical applications of AI in this field. As businesses continue to embrace AI technology, it is crucial to prioritize ethical considerations and ensure that AI tools deliver tangible value. The complexities of AI engineering and the importance of continuous learning are also emphasized, showcasing the practical application of mastering AI technology in the developer relations space.

Download this episode here.

One crucial aspect of building reliable applications is ensuring data integrity. This is where schema validation libraries like Zod come into play. Zod allows developers to define complex data models and validate incoming data against these models. By leveraging Zod's expressive API, developers can easily define object schemas, conditional types, and literal types, ensuring that the data meets the expected structure and constraints. This not only helps catch errors early but also provides a clear and concise way to handle data validation and error handling.

TypeScript's type inference is a powerful feature that can save developers time and effort. By allowing TypeScript to infer types based on context, developers can write cleaner and more concise code. Additionally, leveraging generics can further enhance type inference. Generics enable developers to write reusable code that adapts to different types, making logic inference more flexible and efficient. Understanding how to effectively use generics and type inference can greatly improve code readability and maintainability.

While advanced TypeScript concepts can greatly enhance code quality, it is important to strike a balance between utilizing these features and maintaining code simplicity. It is crucial to understand TypeScript terminology and best practices to avoid overcomplicating code. Additionally, debugging techniques specific to TypeScript can help identify and resolve issues more efficiently. By carefully considering when and where to apply advanced TypeScript concepts, developers can create code that is both powerful and easy to understand.

The conversation begins with AI models and tool calling, emphasizing AI agents' abilities to self-reflect and collaborate. They highlighted Vercel's SDK for generating components, which simplifies the development process and makes AI engineering more accessible. Tejas discussed how AI is revolutionizing podcast production with automated transcription and content generation and transforming the music industry with AI-generated compositions pushing creative boundaries. He also clarifies the distinction between AI and machine learning. While machine learning is a subset of AI, AI encompasses a broader range of technologies and capabilities, enabling AI agents to reason, learn, and make decisions in various contexts.

They also addressed safety concerns and the need for regulations in AI development, advocating for human oversight to ensure ethical and responsible use. Tracy and Tejas noted that while AI has immense potential, it must be guided by human values and principles. The conversation concluded on an optimistic note, with Tracy and Tejas expressing excitement about AI's future. They highlighted its potential to drive innovation across industries, from healthcare and finance to transportation and entertainment. Continued research, collaboration, and investment in AI are essential to unlocking its full potential.

Download this episode here.

Tracy and Josh talk about the importance of using the right tools for better coding results. They discuss how the Gartner hype cycle can influence developers' choices and warn against adopting tools just because they’re trendy. Instead, they suggest carefully evaluating tools based on specific needs and project requirements. By picking the right tools, developers can simplify their workflows, improve code quality, and get better outcomes overall.

The conversation also touches on the impact of companies like Vercel and the unexpected consequences in tech development. While new tools and technologies can be super beneficial, they can also bring unexpected challenges. It’s important for developers to be aware of these potential issues and address them to ensure smooth development and successful projects. They also chat about the "trough of disillusionment" in tech adoption and mention upcoming typed linting tools which aim to further improve code quality and developer productivity.

Lastly, the two talk about the SquiggleConf conference, which focuses on web development tools. They explain the term "squiggle" in error indicators and why clear, informative error messages are important for helping developers debug and troubleshoot. The conference is a great place for developers to learn about the latest web development tools and share tips on improving the developer experience. Check it out on October 3-4, 2024 in Boston, MA!

Download this episode here.

Tracy and Jack's discussion highlights the lack of educational resources on advanced web development topics. This scarcity poses an opportunity for developers who want to showcase their expertise in areas like app router and React server components. By actively engaging in knowledge sharing, developers can demonstrate their deep understanding of these complex concepts and set themselves apart from the competition.

Jack emphasized Vercel's role in simplifying deployment with its easy commands and Next.js integration for seamless collaboration and performance. Next.js was highlighted for its advanced features and simplified development process, including efficient routing and SEO benefits. Deno Deploy, built on Deno, offers serverless deployment without traditional infrastructure management, focusing on code writing and scalability. Throughout, the importance of community and knowledge sharing in platforms like Vercel, Next.js, and Deno Deploy was underscored, enabling developers to share, receive feedback, and stay updated with advancements.

Download this episode here.

Adding observables to the browser will drastically affect RxJS. RxJS is a popular library for reactive programming, and integrating observables into browsers will enable developers to handle asynchronous events and data streams more efficiently. This integration opens up a world of possibilities for creating responsive and interactive web applications. This does not mean RxJS will go away, but it will become more like LoDash for events.

The incorporation of observables into browsers brings several benefits for web developers. Firstly, it simplifies complex APIs, making them more intuitive and easier to use. This allows developers to write cleaner and more maintainable code. Secondly, by leveraging observables, developers can handle asynchronous events and data streams more effectively, resulting in improved performance and responsiveness. Lastly, it will empower developers with a powerful toolset for reactive programming, enabling them to build more sophisticated and interactive web applications.

The conversation in the podcast highlights the collaborative nature of advancing web technologies. Dominic discusses the importance of setting deadlines, sharing updates, and working together to achieve their goals. He expresses optimism about the progress of the project, with positive feedback from WebKit and plans for a future release. This collaborative approach ensures that the enhancements made to web performance benefit developers and users alike.

Download this episode here.

React and Vercel: A Positive Change?

One of the key topics of conversation revolves around React and its relationship with Vercel. It's worth noting that high-profile React core team members have recently made the move to Vercel, which many see as a positive change. This move brings fresh perspectives and expertise to the project, potentially leading to exciting developments in the future.

However, the hosts also acknowledge the challenges of upgrading to React 18, as there are still many users on older versions. Upgrading can have a significant impact on tests and requires careful consideration. It's clear that React's evolution is an ongoing process, and the community plays a crucial role in shaping its future.

The Potential of Bun: A New Default Runtime for Node Development

Is there potential for the runtime called Bun to become the default for node development? Ben expresses skepticism about this possibility, highlighting the need for perfect execution and widespread community support. Switching to a new runtime involves extensive testing and potential risks, especially for critical financial services.

On the other hand, Adam presents a more optimistic view, emphasizing the advantages, such as its built-in TypeScript support and improved interop with node. He believes that as Bun continues to grow and improve, and could become a compelling option for new projects.

The Future of Front-End Development: Likability and AI

They also share their thoughts on the future of front-end development and various technologies. They highlight the importance of likability and the team behind a project, as these factors can greatly influence its success. Additionally, they discuss the potential impact of AI on framework development, raising interesting questions about the role of automation in shaping the future of web development.

While React is praised for its strengths, its perceived limitations compared to other frameworks are also mentioned. The advancements in state management in Angular are highlighted, showcasing the continuous evolution of front-end technologies and the need for developers to stay adaptable and open to new possibilities.

Listen to the full podcast here: https://modernweb.podbean.com/e/modern-web-podcast-s11e20-can-vercel-fix-react-a-conversation-with-tracy-lee-ben-lesh-adam-rackis/

Here are 5 essential tips that will help you navigate the path of adopting technology effectively.

Integrate Technology Into Your Core Mission: Mistake: Treating technology as a siloed entity, whether within your organization or outsourced. Solution: Embrace the idea of being a tech company, integrate tech into your overall strategy to get the best outcome.

Promote Technology Ownership: Mistake: Not encouraging active involvement in tech-related responsibilities or ownership beyond a single person or vendor. Solution: Embrace direct involvement with the technology strategy and implementation. Nurture transparency and accountability to increase informed decision-making within the team and among stakeholders.

Hiring Technologists Who Can Execute Your Vision: Mistake: Hiring tech experts who focus solely on technology, not the business strategy. Hiring without clear roles and alignment. Solution: Seek individuals who bridge the gap between tech and business. Make sure to clearly define business goals and objectives from day one.

Foster Curiosity and Stay Adaptable: Mistake: Thinking technology is too difficult to understand or grasp. Solution: Challenge your technical team to explain complex concepts. Trust that your insight and intuition adds more to the technical execution than you think. Ask questions to encourage innovative solutions.

Embrace Trial and Error: Mistake: Thinking plans won’t change. Solution: Understand that adopting technology and integrating it into your business is a learning process. Expect to make mistakes, and uncover new learnings along the way. Be open to adjustments and flexible with different paths.

These tips will make it easier for your organization to adopt a technology mindset and set your organization up for long-term success when adopting tech. Remember, it's not just about the adoption of technology; it's about creating a new culture that embraces learning, curiosity, and innovation in tech.

Listen to the full podcast episode here: https://engineeringleadership.podbean.com/e/5-tips-for-leaders-adopting-technology-with-rob-ocel-tracy-lee/