While the Model Context Protocol (MCP) provides a solution to exposes these capabilities without hard‑coding functions or rewriting integrations for each agent framework, it doesn’t tell you how agents should decide which tools to call or how those tools should be organized. Especially, when you need to combine tools from different MCP servers in your agents.

Anyone who has built APIs before will immediately feel nostalgic as these aren’t new problems. Just like backend engineers eventually created Backend‑for‑Frontends (BFFs) to cleanly expose functionality, and just like frontend teams adopted GraphQL to unify scattered data sources, developers building MCP servers need similar architectural layers.

This post is about how MCP server composition provides that missing layer using four patterns I keep seeing in real‑world agent systems for structuring, grouping, and orchestrating tools so that tool calling is no longer broken.

Why does tool calling often fail?

Tool calling doesn’t usually fail because "LLMs are bad at handling tools.” It fails because we overload the model with too many tools or badly designed tools. In my previous blog post (“Stop Converting OpenAPI Specs Into MCP Servers”), I explained why dumping an entire OpenAPI spec into MCP makes tools impossible for a model to handle. Let’s focus on the first problem: how having too many tools can break your agent.

Tools overload the context window

Every LLM has a fixed context window of let's say 8k, 32k, 128k, or even 1M tokens. That window must fit:

• The system prompt
• All tool definitions (their schemas, descriptions, examples)
• Conversation history (messages, tool calls, etc)
• The tokens the model is currently generating while reasoning

Every tool definition you add consumes space that the model cannot use for other tasks. In a recent blog post Anthropic showed how an agent is using ~72K tokens for the tool definitions of 50+ MCP tools, and another 5k tokens for the conversation history and system prompt. Altogether, this agent is consuming ~77K tokens before any reasoning has been done.

When the model starts with a 38.5% filled context window (Claude Opus 4.5's default context window size is 200k tokens), you'll leave your agent very little room to do subsequent tool calling and handle multi-step reasoning.

Attention dilution makes the model “compete with itself”

Even when context windows are huge (for example, Gemini 3 has a default context window of 1M tokens), attention mechanisms still struggle with irrelevant or overly verbose tool definitions.

The model has to attend to every token to decide what’s relevant. The more irrelevant or redundant tool definitions you include, the more “distracted” the model becomes.

This leads to:

• Confusion between similar tools
• Misfires (“wrong tool” calls)
• “lost in the middle” failures where the system prompt or earlier instructions are ignored

All of these are not context limit problems, they are an attention competition problem.

Because of these constraints, developers end up doing “context budgeting” as part of their context engineering. This requires them to manually select what tools to include, stripping down tool definition schemas to the bare minimum or avoiding large tool surfaces entirely. This is exactly why the four patterns that follow matter, especially when you need to combine tools from multiple MCP servers in your agent. MCP server composition gives the structure needed to group, layer, and orchestrate tools in a way the model can reliably use them.

Pattern 1: Tool selection inside the MCP client

By far the easiest way to limit the amount of tools passed to the LLM is to use tool selection within the MCP client, and most chat applications and IDEs already support this pattern directly. Applications like Claude Desktop, ChatGPT, Cursor, and various AI‑powered IDEs let you pick which MCP servers to load, and which tools inside those servers should be active for the current session. This gives you control over what the model can see and prevents the agent, in this case the chat application or IDE, from being overloaded by tools it doesn’t need.

This pattern is simple but effective: LLM performance goes up the moment you limit the amount of available tools. Explicitly enabling or disabling tools avoids the two biggest failure modes in tool calling: hallucinated tool calls and overloaded contexts. When the model sees just a handful of clearly defined tools instead of dozens of overlapping ones it’s far less likely to guess, misfire, or call the wrong tool.

Tool selection inside the client is the first layer of control before you start composing servers or building orchestration layers, but far from perfect. You still have to manage the selection manually, and it’s hard to share these configurations with colleagues or clients. And what to think of situations where the tools you need change during the course of your session?

Pattern 2: Composing MCP servers into virtual servers

One step up from using the MCP client to enable or disable tools is creating a new MCP server that exposes only the tools your agent actually needs. Instead of handing the model three or four MCP servers, with dozens of tools it will never use, you compose a virtual MCP server that contains just the relevant ones.

Imagine you're building an agent that needs to scrape a webpage and store the results in a (local) file. You might rely on three different MCP servers to do this (@playwright/mcp, @modelcontextprotocol/server-filesystem and mcp-server-time), but only a subset of their tools matter. By composing a new MCP server with just those tools, you avoid the above discussed problems related to context bloat and tool confusion that increases the chance of wrong tool calls. If not, these three MCP servers alone would have inserted 25+ tool definitions into the context of your agent.

This maps directly to the earlier mentioned Backend‑for‑Frontend (BFF) pattern in the API world. In a BFF, you create a custom API tailored for a single frontend. If a payment app needs to make several calls to process a transaction, the BFF provides a simplified API surface, sometimes even orchestrating multiple backend calls into one endpoint, that reduces business logic in the client.

MCP server composition works the same way, it becomes the layer that only exposes tool that the agent actually needs. There are two ways to compose MCP servers:

• Build a new server directly using one of the MCP SDKs or a meta‑framework.
• Use an MCP gateway to create a virtual, remote server that proxies and aggregates tools.

Personally, I prefer using a meta‑framework as it gives you the best of both worlds: you can compose servers easily using abstractions without the operational overhead that comes with a gateway (more on MCP gateways later). At IBM we built mcp-composer, which has a CLI to make composing your MCP servers as virtual endpoints easy. It lets developers combine multiple MCP servers (or specific tools from them) into domain‑specific servers without rewriting anything. You pick the tools, define the scope, and expose a single interface your agent can reliably use.

Pattern 3: Dynamic Tool Selection

With dynamic tool selection, you push the responsibility of choosing the right tool down into the server layer. Most tool‑calling mistakes happen because we force the LLM to choose directly from a long list of tool definitions. The model has to read every tool name, description, and schema in its context just to decide which one to call.

Dynamic tool selection lets the MCP server determine which tool should be called from which MCP server. This removes a big amount of overhead from the model and dramatically improves reliability, without giving away control over the available tools.

There are two emerging approaches to handle dynamic tool selection:

• Layered Tool Design
• RAG‑MCP (Retrieval‑Augmented Tool Selection)

Let's break down each of these solutions.

Layered Tool Design

With the layered tool design you "hide" the tool definitions behind layers. The LLM interacts only with a small set of high‑level tools (discovery, planning & execution), and those tools internally call lower‑level tools, bundle logic, or orchestrate multi‑step flows. This is the pattern that the engineering team at Block implemented for Square's payment MCP server, and since has been implemented in various MCP solutions.

The layers are designed like this:

• Discovery layer: Returns a short, simplified set of high‑level operations the LLM can choose from. Instead of exposing every tool and schema, this layer prevents the context window from being flooded with unnecessary details.
• Planning layer: Once the LLM selects a tool, the planning layer determines the exact inputs needed. It derives the correct parameters based on the underlying tool definitions, so the model only has to fill in these values.
• Execution layer: Executes the final tool call by routing it to the correct MCP server, along with the validated input parameters.

While a layered MCP server doesn’t technically choose the tool for the LLM, it gives the model a much smaller and more structured surface to choose from. It removes irrelevant information, reduces context bloat, and guides the model toward the correct tool without forcing it to understand every schema. This works especially well for MCP servers that were derived form existing APIs or multi-purpose MCP servers that contain lots of tools.

You can implement this layered tool design with mcp-composer, and even combine tool selection approaches: you can first compose a narrowed‑down tool set into a virtual MCP server, and then apply layered tool design on top of that server to make tool selection even more reliable and easier for the model to use.

RAG‑MCP (Retrieval‑Augmented Tool Selection)

Retrieval Augmented Generation (or RAG) helps LLMs to find the right context from a knowledge base, without bloating the context window with irrelevant information. Think of a situation where you are looking for the cancellation policy in a 34-page contract. Instread of shoving all these pages into the context, the RAG system will retreive only the relevant chunks of information to reduce the context bloat. With RAG-MCP,the knowledge base would be the tool definitions of all your MCP servers, and the MCP server would dynmically select the required tool.

Instead of loading all tools into the context, the server:

• Embeds each tool definition
• Ranks them by semantic similarity to the user request
• Loads only the most relevant tools into the model’s context

This means the model receives only the tools needed based on the prompt, not everything the MCP server(s) supports. According to the RAG-MCP research paper this approach decreases the amount of tokens spent on tool definitions by over 50% and, based on a benchmark across websearch tools, increases tool selection accuracy by 200%. You can find an example implementation of RAG-MCP on GitHub, based on a blog post by Writer.

Next to this example, you can also find a similar approach in Anthropic's new Tool Search capability. When you build an agent using the Anthropic API, you can pass all your MCP servers in a single request and include a flag that tells Claude whether to use regex or bm25 for tool selection. Instead of loading every tool definition into the prompt, Claude applies either regex matching (executed as Python code) or BM25 (a lightweight retrieval technique) to determine which tools are relevant based on the user’s message.

Pattern 4: Programmatic Tool Execution

The final pattern pushes MCP server composition one step further. Instead of asking the LLM or MCP server to select a tool, you let the model generate code that imports and executes the selected tools in a sandboxed environment. So far, this pattern has been implemented by Cloudflare (called "Code Mode") and Anthropic.

Programmatic tool execution makes use of a sandbox with a script generated by the model (usually in Python) to chain tool calls, iterate over results, applies filters, etc. The script is then executed in a runtime that:

• Enforces valid MCP tool schemas
• Prevents unsafe operations
• Returns only the final output back to the model

This pattern significantly decreases the amount of tokens in the context for the LLM as it only needs to call the tool surfacing the sandbox. It could be specially powerful for tasks that involve multiple tool calls that need to chained or require conditional logic, but depending on how you would implement this, there could be additional tokens needed (and added latency) to generate the tool execution script.

Also, the risk with programmatic tool execution is the lack of control developers have over how tools are being called, the possibility of side effects and all sorts of injections. As many developers are trying to tuns probabilistic LLMs into deterministic software, the last thing most them are willing to do is giving up more control.

What About MCP Gateways?

Every enterprise considering adopting MCP is looking at MCP gateways to secure, deploy, version, and route MCP servers in a centralized way, including tracking usage, enforcing usage limits, etc. Similar to API gateways, they are used as the single entry point for an enterprise's developers and clients to interact with their services. However, a lot of MCP gateways do more than proxying or aggregating MCP servers, making the line between a "tool layer" (like a BFF) and a gateway very fine.

That said, not every developer needs a gateway in the traditional sense. Most application developers (now called AI engineers) will get far more value by creating a clean tool layer the agent can rely on, very similar to how frontend developers relied on BFFs to simplify and shape complex backend systems. Gateways, on the other hand, solve operational problems, not design problems. If your tools are badly designed, unstructured, or confusing for the model to use, a gateway won’t fix that problem, but the patterns described in this blog post do.

This is why I believe the future “app layer” for agents won’t be a gateway. It will be a tool composition layer (like mcp-composer), built much closer to where application logic lives. Gateways will still play a role for organizations that need centralized control, but the majority of AI developers will be better served by curating and shaping the tools they expose to their agents first.

If you do end up needing an MCP gateway, check out Context Forge, an open-source MCP and A2A gateway built by a great team at IBM.

To conclude

MCP server composition gives agents the structure and focus they’ve been missing. Tool calling doesn’t break because LLMs can’t use tools, it breaks because we hand them too many tools, expose the wrong ones, or fail to design them properly. The four patterns in this post should give you an idea how to fix your broken agent, and as the MCP specification keeps evolving I'm interested in seeing how some of these patterns are getting incorporated. Not every team needs every pattern, and not everyone needs a gateway. What every team building agents does need is a thoughtful tool layer that mirrors the evolution we saw with APIs, BFFs, and GraphQL.

If you found this blog post helpful, don’t forget to share it with your network. For more content on AI and web development, subscribe to my YouTube channel and connect with me on LinkedIn, X, or Bluesky.

And that’s not surprising, as the majority of APIs built by developers are RESTful-ish, and OpenAPI is the dominant way to describe them. So when developers first try out MCP, the obvious move is to point at an OpenAPI spec file and turn every endpoint into a collection of tools.

But when you do that, you miss the whole point of MCP. Instead of creating better tools for agents, you just increase the risk of hallucinations and poor fault tolerance.

In this post, I’ll walk through some of the frustrations I’ve seen firsthand and explain why treating MCP like just another API spec doesn’t work.

Too many tools fill up the context window quickly

Most MCP servers today are used for tool calling. But that doesn’t mean they should expose hundreds of low-level API endpoints. An MCP server is a set of tools, prompts, and resources that each should represent something an agent can actually use.

The most common mistake I see is developers auto-converting OpenAPI specs into MCP servers without any curation. That usually produces dozens (or even hundreds) of very low-level tools, one for every single endpoint.

In theory, this might look powerful. In practice, it causes problems. The LLMs the agent will connect to have a limited context window, and every tool definition takes up space in that window. Too many tools lead to confusion, poor fault tolerance, and a higher risk of hallucinations.

Curation helps. By exposing only the endpoints that matter, you keep your MCP server focused and more reliable. Some clients like Cursor or Claude Desktop let users toggle tools on and off, but not every environment works that way. If someone connects directly from code, they’d have to curate the tools themselves if you haven’t already done it for them.

Agents are bad at taking multi-step actions

A good MCP server should feel like a well-designed API. One of the biggest problems with exposing every endpoint as a tool is that you push the complexity of multi-step actions onto the agent.

Take this example: “refund a customer by email.”

With a 1:1 OpenAPI conversion, the agent has to:

• Call get_customers with an email address to get the customer ID.
• Call get_customer_orders to fetch their orders.
• Call create_refund with the right order ID.

That’s three separate steps, and a lot can go wrong in the middle. The agent might pass the wrong email, pick the wrong order, or start calling tools like get_customer_by_id or get_order_by_id to collect information it doesn't need to get the job done. LLMs aren’t good at following exact step-by-step flows in a reliable, deterministic way.

If you design the MCP server directly, instead of just converting the OpenAPI spec, you can collapse this workflow into a single action. That makes the process deterministic, reduces hallucinations, and improves fault tolerance.

There are two ways to handle multi-step actions in MCP: prompts or better tool design.

MCP servers can return prompts that could help the agent create a plan on which tools to call, and in what order. In this example, a prompt might spell out the steps for refunding a customer by email. That’s better than leaving the agent to figure it out, but still error-prone.

The stronger approach is to design a higher-level tool that handles the entire workflow behind the scenes. The agent just calls refund_customer_by_email, and your server does the rest. That’s the kind of deterministic design that makes MCP servers actually usable.

Layered Tool Design can help

Another way to keep MCP servers that need to span a lot of tools usable is to design them in layers.

Block’s engineering team (the company behind Square) introduced this layered pattern with their own Square MCP server, and it’s a good example of how to structure tools so agents don’t get overwhelmed.

The idea is simple:

• Discovery tools help the agent understand what’s available.
• Planning tools guide it toward the right action.
• Execution tools perform the actual operation.

This layered approach makes servers easier to use and more fault tolerant. Instead of giving the agent a flat list of dozens of low-level tools, you organize them into progressive steps. The agent can start broad, narrow down, and then execute without getting lost in irrelevant options.

You don’t have to build this from scratch either. With libraries like mcp-composer, you can implement the layered tool pattern on top of existing OpenAPI specs. The documentation explains how to set up this pattern in a couple of steps, including how to add other capabilities like authentication to MCP servers (more about that in a later blog post).

The result is an MCP server that agents can reliably work with, one that is deterministic, less prone to hallucinations, and easier for users to understand.

Other Considerations

There are a few other points worth keeping in mind when building MCP servers based on your OpenAPI specification.

⚠️ Error messages: OpenAPI responses aren’t written for LLMs. A "404 not found" might make sense to a developer, but for an agent it’s ambiguous. Was the email wrong? The order missing? Or is the whole service unavailable? Consider normalizing errors into responses the agent can reason about.

⚠️ Irrevocable actions: Just because your API has a DELETE /orders endpoint doesn’t mean it should be exposed as an MCP tool. Agents don’t always understand the consequences of destructive actions. Ask yourself: should this action really be available to the agent, and is there a human in the loop to mitigate?

⚠️ Authentication: We didn’t even touch on auth and security in this post, but they’re critical pieces. From bearer tokens to OAuth delegation, authentication and authorization add another layer of complexity you’ll need to design for. I recommend reading the article The “S” in MCP Stands for Security to learn more about this topic.

These aren’t reasons to avoid MCP. They’re reminders that building good MCP servers means designing for agents, not just translating existing APIs.

If you found this tutorial helpful, don’t forget to share it with your network. For more content on AI and web development, subscribe to my YouTube channel and connect with me on LinkedIn, X, or Bluesky.

MCP helps by standardizing how your agent connects to these tools. But to your LLM, there’s no difference between “regular” tool calling and using a standard like MCP. It only sees a list of tool definitions, it doesn’t know or care what’s happening behind the scenes. And that’s a good thing.

By using MCP you get access to thousands of tools, without writing custom integration logic for each one. It heavily simplifies setting up an agentic loop that involves tool calling, often with almost zero development time. You, the developer, are responsible for calling the tools. The LLM only generates a snippet of what tool(s) to call and with which input parameters.

In this blog post, I’ll break down how tool calling works, what MCP actually does, and how both relate to context engineering.

Tool Calling

LLMs understand the concept of tool calling, sometimes also called tool use or function calling. You provide a list of tool definitions as part of your prompt. Each tool includes a name, description, and expected input parameters. Based on the question and available tools, the LLM may generate a call.

But here’s the important part: LLMs don’t know how to use tools. They don’t have native tool calling support. They just generate text that represents a function call.

In the diagram above, you can see what the LLM actually sees: a prompt made up of instructions, previous user messages, and a list of available tools. Based on that, the LLM generates a text response which might include a tool that your system should call. It doesn’t understand tools in a meaningful way, it’s just making a prediction.

Let's look at a more practical use case. For example, if you provide a tool called get_weather that takes a location as input, and then ask the model: "What’s the weather in San Jose, CA?" it might respond with:

{
  "name": "get_weather",
  "input": {
    "location": "San Jose, CA"
  }
}

The LLM is able to generate that snippet based on the context it was provided with, as you can see in the diagram below. The LLM doesn’t know how to call the get_weather tool, nor does it need to. Your agentic loop, or agentic application, is responsible for taking this output and making the actual API call or function invocation. It parses the generated tool name and inputs, runs the tool, and passes the result back to the LLM as a new message.

This separation of concerns is important. The LLM just generates predictions and your system handles the execution. And that brings us to where MCP fits in.

Model Context Protocol (MCP)

Model Context Protocol, or MCP, is a way to standardize how your agent connects to data sources like tools, prompts, resources, and samples. Right now, MCP is best known for simplifying the tools side of that equation. Instead of manually writing code for each tool in a custom format, MCP defines a consistent schema and communication pattern. Think of it as a universal adapter (like USB-C) for tooling.

MCP usually involves three components: a host application, an MCP client, and one or more MCP servers. The host might be a chat app or IDE (like Cursor) that includes an MCP client capable of connecting to different servers. These servers expose tools, prompts, samples, or resources.

The way you interact with the LLM doesn’t change. What changes is how the tools are surfaced to it. The agentic application talks to the MCP client, which talks to the right server. Tools are described in a format the LLM can use.

For the same question, "What’s the weather in San Jose, CA?", the LLM will still get the same list of tools. And based on that list it will tell you what tool to call, how that tool is called is up to the developer. When using MCP, that tool will be called using MCP.

The benefit here isn’t for the LLM, it’s for you as the developer. MCP helps manage complexity of working with many different tools as your agent grows. It makes it easier to reuse tools across projects, enforce consistent formats, and plug into new systems without rewriting everything.

But the LLM will never know you are using MCP, unless you are letting it know in the system prompt of tool definitions. You, the developer, is responsible for calling the tools. The LLM only generates a snippet of what tool(s) to call with which input parameters.

Next, let’s look at how this fits into the bigger picture of context engineering, and why abstraction layers like MCP make things easier for humans, not models.

Context Engineering

Context engineering is about giving your LLM the right inputs so it can generate useful outputs. That sounds simple, but it’s actually one of the most important parts of building effective AI systems.

When you ask a model a question, you’re really giving it a prompt -- a block of text it uses to predict the next block of text. The quality of that prompt directly affects the quality of the response.

This is where tools come in. Sometimes the model doesn’t have enough context to answer a question well. Maybe it needs real-time data, access to user profiles, or the ability to take action on behalf of the user. Tool calling lets you solve that by giving the model access to external systems, as you learned in this blog post.

But again, the model doesn’t need to know how those tools work. It just needs to know that they exist, what they’re for, and how to call them. That’s where context engineering meets tool design, you’re crafting a set of tool definitions that serve as part of the model’s prompt.

MCP makes that process cleaner and more repeatable. Instead of hardcoding tools or writing ad hoc wrappers, you define a structured interface once and expose it through MCP. The LLM still sees the same types of tool definitions, but now they’re easier to maintain and scale.

So in the end, MCP is a tool for us developers, not for the LLM. It helps us build more reliable, modular systems. And it helps us focus on context engineering without reinventing the plumbing every time.

Where to go from here?

• Learn how to build a MCP Server in <10 minutes
• Test MCP Servers using MCP Inspector

If you found this tutorial helpful, don’t forget to share it with your network. For more content on AI and web development, subscribe to my YouTube channel and connect with me on LinkedIn, X or Bluesky.

We'll walk through the full process of building an MCP server for Open Library, a free and open-source book catalog API. You'll learn how to:

• Build a TypeScript-based MCP server
• Use the MCP Inspector to validate server responses
• Leverage LLMs for suggestions and debugging
• Integrate Open Library’s public API into your MCP setup

Click the image below to watch the YouTube video version:

Introduction

Learn more about the Model Context Protocol (MCP)

In this tutorial, we'll be building an MCP server for Open Library, an open, editable library catalog with a public API. Using the API, you can search and browse through a vast collection of books, authors, publishers, and more. Open Library is a project from the Internet Archive and can be thought of as the "Wikipedia for books". Furthermore, we'll use MCP Inspector and Claude Desktop to test the MCP server while building it.

Building a MCP server

As we'll be using the Node.js SDK for the MCP server, we'll need to install it first. You can do this by running the following commands in your terminal:

npm init -y
npm i @modelcontextprotocol/sdk zod
npm i --save-dev typescript

This will set up a new Node.js project with a package.json file. We'll also need to install the Zod library, which is used for defining and validating types in TypeScript -- which is the other dependency we just installed.

In the package.json file, we'll need to add a "type": "module" property. This tells Node.js that our project is using ES modules instead of CommonJS. Also, we'll add a few scripts to run the project:

{
  "name": "mcp-open-library",
  "version": "0.1.0",
  "description": "A Model Context Protocol server for Open Library",
  "private": true,
  "type": "module",
  "bin": {
    "mcp-open-library": "./build/index.js"
  },
  "files": ["build"],
  "scripts": {
    "build": "tsc && node -e \"require('fs').chmodSync('build/index.js', '755')\"",
    "prepare": "npm run build",
    "watch": "tsc --watch",
    "inspector": "npx @modelcontextprotocol/inspector build/index.js"
  }
  //...
}

As you can see in the above code snippet, I've named the project mcp-open-library and set its version to 1.0.0. Also, we have scripts to build the code (both build and watch) and to run the project using the inspector script.

In a new file called src/index.ts you should add the following code:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "mcp-open-library", version: "1.0.0" });

server.tool(
  "search_books",
  `
  Search for books on the Open Library API.
  `,
  {
    q: z.string(),
  },
  async ({ q }) => {
    const data = await fetch(
      `https://openlibrary.org/search.json?q=${q}&limit=20`
    );
    const json = await data.json();

    return {
      content: [
        {
          type: "text",
          text: JSON.stringify(json),
        },
      ],
    };
  }
);

await server.connect(new StdioServerTransport());

This code is a bit more complex than the previous example, but it's still pretty straightforward. We're creating an instance of the McpServer class and setting its name to "mcp-open-library" and version to "1.0.0". Then we add a tool called "search_books" that takes a query string as input and returns a list of books from the Open Library Search API. Later on in this tutorial we'll add more information about how to use this tool later on, but the value of q can be either a search term (like rowling for finding results about J.K. Rowling) or a search term prefixed with a category like author or title.

We then connect to a server using the StdioServerTransport class, which allows us to run our server in an interactive shell. Finally, we export the server instance so that it can be used by other scripts.

Try out a MCP server in MCP Inspector

To try this MCP server, you need first need to build and compile the code by running the following command in your terminal:

npm run watch

(You could also run npm run build but it will only run once, means you'll have to run it again after every change in your code).

Once you've built and compiled your code, you can run the server by running the following command in ANOTHER terminal window or tab:

npm run inspector

This will start MCP Inspector running on a local server, and you can connect to it by opening the following URL in your browser http://127.0.0.1:6274.

Here, you would first need to connect to the MCP server:

• In the left menu select stdio under "Transport type"
• Under "Command" type node
• Under "Arguments", type build/index.js
• Press "Connect" to connect to the MCP server

The MCP Inpector will automatically list all the tools available on the MCP server, and you can try them out by selecting one and pressing "Run tool".

For example, to use the Open Library tool, you would select it from the list of tools, provide a value for q (like author:rowling) and press "Run tool". This wil call the Open Library tool and display the results in the MCP inspector, as you can see in the screenshot below:

In the MCP inspector you can also find the history of all the tools you've run, and you can also find the response for each tool.

Iterating on the server

You can also iterate on the server by modifying the code. For example, we can limit the amount of data returned by the tool and handle pagination to see more than just 20 results.

First, let's add the page and limit arguments to the tool:

  {
    q: z.string(),
    limit: z.number().default(20),
    page: z.number().default(1),
  },

The values for limit and page are optional, so we can set a default value for both.

And then pass these arguments to the fetch call:

  async ({ q, limit, page }) => {
    const data = await fetch(
      `https://openlibrary.org/search.json?q=${q}&limit=${limit}&page=${page}`
    );

If you still have the command npm run watch running in your terminal you can restart the MCP inspector and see you can now add values for page and limit to see more results.

We also need to clean up the response of the tool, as it includes many fields we don't need. Remember, every character returned by the tool will be shared with the LLM you connect it to. This means that more characters increase your token count and thereby costs.

In the callback function we can add the following:

const json = await data.json();
let books = [];

if (json?.docs?.length > 0) {
  books = json.docs.map((book: any) => {
    const title = book.title;
    const author_name = book.author_name.join(", ");
    const first_publish_year = book.first_publish_year;
    const id = book.lending_edition_s;

    return { id, title, author_name, first_publish_year };
  });
}

return {
  content: [
    {
      type: "text",
      text: JSON.stringify(books),
    },
  ],
};

From the MCP inspector you can now see way less data is returned from the tool compared to before. This is because we are now only returning a subset of the data.

Finally, let's add some extra informaiton for the LLM before we use the tool in a MCP client like Claude Desktop. Add the following to the tool description:

Use the following format:

  q=title:flammable will find any books with "flammable" in the title field
  q=author:solnit will find authors with "solnit" in their name
  q=subject:tennis rules will find any books about "tennis" AND "rules"
  q=place:lisbon will find books about Lisbon
  q=person:rosa parks will look for people with rosa AND parks in their name
  q=language:spa will find any books with at least one edition in Spanish (most other language codes use the first three letters of the language except for Japanese which uses jpn There is also mul for multiple languages and und for undetermined)
  q=publisher:harper will looks for any books published by a publisher with "harper" in their name. (Publisher has never been a controlled field in the library world, so you can see we have a ton of variants of this famous publisher in the search facets.)
  q=publish_year:[* TO 1800] will find anything published before and up to the year 1800.

  You can also blend them together:

  q=subject:travel place:istanbul will look for books about travel in Istanbul.
  q=subject:dogs subject:("Juvenile fiction" OR "Juvenile literature") will look for children's books about dogs.

This description is a bit long, but it gives the LLM all the options on how to use the book search tool. You can try out these combinations in MCP Inspector yourself and remove any that you ecpect not to use.

Connect to a MCP Client

Now we have our server ready for use, let's connect to it from an MCP client. We'll start with the simplest possible example:

To use with Claude Desktop, open the server config:

• On MacOS: /Users/USER_NAME/Library/Application Support/Claude/claude_desktop_config.json
• On Windows: %APPDATA%/Claude/claude_desktop_config.json

And add the following config:

{
  "mcpServers": {
    "mcp-open-libary": {
      "command": "node",
      "args": ["/path/to/mcp-open-library/build/index.js"]
    }
  }
}

You can now open Claude Desktop and you would see the new MCP server list. If you had Claude Desktop open before editing the config, you'll need to restart it for the changes to take effect.

Let's start with a simple query: "Retrieve all books written by JK Rowling". Claude should see the server we just set up and return the results.

We can also use Claude Desktop to run more complex queries against our MCP server. For example, let's try asking this question: "Show me books about wizards that take place in the United Kingdom".

Interacting with Claude Desktop will require you to approve the suggested tool call to the MCP server, this looks something like the following:

The tool calls that Claude now generates are more complex than a simple query and will be able to generate multiple queries for you. For example, it can generate a list of all books about wizards written by JK Rowling, or a list of all books about wizards that take place in the United Kingdom.

The search queries it generated are:

`q`: `subject:wizards place:\"united kingdom\"`

And

`q`: `subject:(wizards OR magic) place:(britain OR england OR \"united kingdom\" OR scotland)`

This will return a list of books that include the Harry Potter series but also the "The Chronicles of Narnia" series by C.S. Lewis (1950) and "Northern Lights" (part of "His Dark Materials") by Philip Pullman (1995).

What's next?

Building MCP servers becomes significantly easier when leveraging both LLMs and the MCP Inspector. They provide guidance and testing capabilities, helping you build efficient and reliable MCP servers faster.

If you found this tutorial helpful, don’t forget to share it with your network. For more content on AI and web development, subscribe to my YouTube channel and connect with me on LinkedIn, X or Bluesky.

What You'll Learn:

• Install and set up an MCP server with TypeScript
• Define custom tools for your MCP server
• Execute tools using the MCP protocol
• Integrate your MCP server with a host such as Claude Desktop

Click the image below to watch the YouTube video version:

What is MCP?

The Model Context Protocol (MCP) simplifies the process of enabling AI agents to interact with various tools. MCP consists of three main components:

• MCP Servers: These act as bridges to connect APIs, databases, or code. They expose data sources as tools to the host and can be built using Python or TypeScript SDKs.
• MCP Clients: These clients use the protocol to interact with MCP servers. Like servers, they can be developed using SDKs in Python or TypeScript.
• MCP Hosts: These systems manage communication between servers and clients, ensuring smooth data exchange. Popular hosts include Claude Desktop, Zed, and Sourcegraph Cody.

The tools provided by an MCP server can be accessed via any MCP host, allowing developers to connect AI agents to new tools without the need for custom integration code.

Setting Up an MCP Server

In this tutorial, we'll focus on building an MCP server using the TypeScript SDK. We’ll use Claude Desktop as our host for testing.

Step 1: Install Dependencies

Begin by creating a new project and initializing an npm package. Add the necessary dependencies for the MCP server and TypeScript. Ensure your project includes configuration files like package.json and tsconfig.json:

mkdir mcp-server
cd mcp-server

Create a package.json file:

{
  "name": "mcp-server",
  "version": "0.1.0",
  "description": "A Model Context Protocol server example",
  "private": true,
  "type": "module",
  "bin": {
    "mcp-server": "./build/index.js"
  },
  "files": [
    "build"
  ],
  "scripts": {
    "build": "tsc && node -e \"require('fs').chmodSync('build/index.js', '755')\"",
    "prepare": "npm run build",
    "watch": "tsc --watch",
    "inspector": "npx @modelcontextprotocol/inspector build/index.js"
  },
  "dependencies": {
    "@modelcontextprotocol/sdk": "0.6.0"
  },
  "devDependencies": {
    "@types/node": "^20.11.24",
    "typescript": "^5.3.3"
  }
}

Create a tsconfig.json file:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "Node16",
    "moduleResolution": "Node16",
    "outDir": "./build",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules"]
}

Run the following command to install dependencies:

npm install

Step 2: Write Boilerplate Code

Create a file src/index.ts and add the following boilerplate code:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  CallToolRequestSchema,
  ErrorCode,
  ListToolsRequestSchema,
  McpError,
} from "@modelcontextprotocol/sdk/types.js";

const server = new Server({
  name: "mcp-server",
  version: "1.0.0",
}, {
  capabilities: {
    tools: {}
  }
});

server.setRequestHandler(ListToolsRequestSchema, async () => {
  return { tools: [] };
});

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === "name_of_tool") {
    return {};
  }
  throw new McpError(ErrorCode.ToolNotFound, "Tool not found");
});

const transport = new StdioServerTransport();
await server.connect(transport);

Step 3: Define and Add Tools

Define a tool schema and its execution logic. For example, to add a tool that calculates the sum of two numbers:

server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [{
      name: "calculate_sum",
      description: "Add two numbers together",
      inputSchema: {
        type: "object",
        properties: {
          a: { type: "number" },
          b: { type: "number" }
        },
        required: ["a", "b"]
      }
    }]
  };
});

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === "calculate_sum") {
    const { a, b } = request.params.arguments;
    return { toolResult: a + b };
  }
  throw new McpError(ErrorCode.ToolNotFound, "Tool not found");
});

Step 4: Integrate with Claude Desktop

Register the MCP server in claude_desktop_config.json:

{
  "mcpServers": {
    "mcp-server": {
      "command": "node",
      "args": [
        "/Users/YOUR_USER/mcp-server/build/index.js"
      ]
    }
  }
}

Restart Claude Desktop to see the tools listed.

You can click on the "tools" button to see the name and description of the available tools, including the MCP server that provided the tool:

After verifying the MCP server and the tool are available, you can start asking a question that would trigger a call to the calculate_sum tool, such as:

What is the sum of 9999 + 1?

When you press "enter," it should start generating your answer. If a tool is found that matches your question, you will be asked to grant Claude access to call that tool. This process is called "human in the loop" and will prevent malicious tool calls:

If granted access, Claude will use the tool "calculate_sum" to add up the two numbers and print the result (which is 10000) in the chat.

4. Calling a REST API as a tool

Besides executing code in the MCP server, you can also retrieve remote data from a source such as an API. Let's use a mock REST API from httpbin.org that returns JSON data about a mock slideshow.

In the file src/index.ts you need to add the following code to define the tool:

// Define available tools
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      { 
        // calculate_sum tool definition
      },
      {
        name: "httpbin_json",
        description: "Returns data about slide show",
        inputSchema: {
          type: "object",
          properties: {
            id: { type: "number" }
          },
          required: []
        }
      }
    ]
  };
});

As you can see in the video recording of this tutorial, I used Claude Desktop to generate the code to execute this REST API request. You need to add this code to src/index.ts too:

// Handle tool execution
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === "calculate_sum") {
   // ...
  }
  if (request.params.name === "httpbin_json") {
    try {
      const response = await fetch('https://httpbin.org/json', {
        method: 'GET',
        headers: {
          'accept': 'application/json'
        }
      });

      if (!response.ok) {
        throw new Error(`HTTP error! status: ${response.status}`);
      }

      const data = await response.json();

      return ({
        toolResult: data
      })
    } catch (e) {
      throw new Error("Something went wrong");
    }

    throw new Error("Tool not found");
});

Once you've added both pieces of code, make sure to build the MCP server code again by running:

npm run build

You don't need to make any changes to the Claude Desktop configuration this time, as we did not update the MCP server but only the tools for this server. You do have to close and restart Claude Desktop, as otherwise it doesn't pick up the newly built code.

After restarting Claude Desktop, you should see that there are two tools available now, and you can ask a question like:

Give me more details about the latest slideshow

After pressing "enter" you'll be asked to give Claude access to the new httpbin_json tool:

Once granted access, the MCP host will initiate a tool call to the MCP server. The MCP server will call the httpbin.org mock REST API and return the result back to the MCP host.

What's next?

he Model Context Protocol represents more than just a technical specification—it's a model for connecting your data sources to AI agents across different applications. While MCP simplifies integration, there are still areas where developers need to provide additional support, such as caching, authentication, and scalability.

One of the key next steps is to explore advanced integrations. For instance, combining MCP with a tool library or platform like IBM watsonx.ai Flows Engine can provide an even better tool development experience. This platform allows you to transform any data source into a tool and deploy it to a GraphQL endpoint. From there, tools can easily connect to AI agents or be integrated into MCP hosts.

If you found this tutorial helpful, don’t forget to share it with your network. For more content on AI and web development, subscribe to my YouTube channel and connect with me on LinkedIn, X or Bluesky.

We will walk through:

• Setting up a React app with Vite
• Installing and configuring LangChain
• Connecting to the OpenAI API
• Building a query function with LangChain
• Handling form submission to interface with the AI

Click the image below to watch the YouTube video version of this blog post:

Setting up a React app with Vite

Vite is a rapid frontend build tool for modern web development. For this tutorial, we use a basic Vite app styled similarly to ChatGPT - with a query box against an empty background ready to display questions and answers.

I've already created a boilerplate for this tutorial, which you can find here.

You can check out the repository by running the following command in your terminal:

git clone https://github.com/royderks/ai-frontend-workshop.git

After cloning the repository, you'll need to move into the new directory and install the dependencies.

cd ai-frontend-workshop/my-gpt
npm install

Once you've got everything installed, open your project in whatever IDE you use – we're gonna go with Visual Studio Code here. The project folder is gonna look pretty familiar if you've ever dabbled with Create React App. You'll find static assets such as images in public and your React code in src. Plus, all the must-haves like package.json and vite.config.js are there. Oh, and TypeScript users, you haven’t been forgotten – there’s a tsconfig.json in there for you.

Ready to see your project live? Start your local development server with:

npm run dev

And just like that, your Vite app is up and running in your browser. Which will look something like the screenshot you can see below.

You get hot-reloading and all the modern features that make coding less of a chore.

Installing and configuring LangChain

LangChainJS is a JavaScript library designed to integrate language AI capabilities into web and Node.js applications. LangChain began as a Python SDK but now has JavaScript and TypeScript support. By offering developers an easy-to-use interface to leverage Large Language Models (LLMs) like GPT-4, LangChainJS simplifies the process of incorporating advanced natural language understanding and generation into projects.

Popular use cases for LangChainJS are chatbots, automating content creation, enhancing search functionalities, or crafting personalized user experiences. You can do all of this with a limited amount of knowledge about LLMs as LangChain offers a set of abstractions on top of popular LLM providers such as OpenAI and IBM Watson.

Before installing LangChain, let's stop the dev server and run:

npm install langchain @langchain/openai

This will install both the general LangChain library and the library needed to connect to OpenAI. In the next section, we'll be connecting to OpenAI for which we need to generate an API Key first.

Connecting to OpenAI API

OpenAI isn't only the creator of ChatGPT; it also has a platform where you can access the models used by ChatGPT. Developers can sign up for free, and often, will get a small credit of $5 to try out their APIs. On

the OpenAI dashboard, we will generate a new secret key to authenticate our app.

With our key secured, we create an environment file called .env to store it:

VITE_OPENAI_API_KEY=<your_key>

We're using VITE_ as a prefix so the environment variable gets picked up by Vite.

Now we can initialize the connection in a new file called langchain.ts:

import { OpenAI } from "@langchain/openai";

const llm = new OpenAI({
    openAIApiKey: import.meta.env.VITE_OPENAI_API_KEY,
});

After creating the connection to OpenAI, we can create a function to call the LLM and pass our question to retrieve the answer.

Building a query function with LangChain

There are multiple methods to query an LLM using LangChain, each of these methods will behave slightly differently. For this tutorial, we'll use the invoke method, one of the simplest and quickest available in LangChainJS.

With our connection configured, we can build out the query function in the same langchain.ts file:

import { OpenAI } from "@langchain/openai";

const llm = new OpenAI({
    openAIApiKey: import.meta.env.VITE_OPENAI_API_KEY,
});

export async function getAnswer(question: string) {
    let answer = ''

    try {
        answer = await llm.invoke(question);
    } catch (e) {
        console.error(e);
    }

    return answer;
}

This async function takes the question, queries the API using LangChain's invoke method, and returns the answer. There's a try/catch block around the function so we can catch errors, for example, when we run out of tokens.

Handling form submission to interface with the AI

The final step to completing this tutorial is to use the getAnswer function in the user interface that we built in the first section. As we're using client-side React, we need to create a few state variables in src/App.tsx and import the getAnswer function from langchain.ts. Also, the getAnswer function needs to be wrapped in a function that we can connect to the onSubmit function of the text input for typing the question:

import { useState } from "react";
import { getAnswer } from "./langchain";

export default function App() {
  const [question, setQuestion] = useState("");

  async function handleSubmit(e: React.FormEvent<HTMLFormElement>) {
    e.preventDefault();
    const result = await getAnswer(question);
    console.log(result);
  }

  // ...

We can now handle the submission of the question by adding this function to the onSubmit in the form element:

<form
    className="stretch mx-2 flex flex-row gap-3 last:mb-2 md:mx-4 md:last:mb-6 lg:mx-auto lg:max-w-2xl xl:max-w-3xl"
    onSubmit={handleSubmit}
>

With that, our app can now interface with the AI! We can ask questions and see it return answers that are logged to the console. If you want to display the result in the user interface, you can create another state variable for the answer:

import { useState } from "react";
import { getAnswer } from "./langchain";

export default function App() {
  const [question, setQuestion] = useState("");
  const [answer, setAnswer] = useState("");

  async function handleSubmit(e: React.FormEvent<HTMLFormElement>) {
    e.preventDefault();
    const result = await getAnswer(question);

    setAnswer(result);
  }
  
  // ...

The value for answer can be rendered anywhere in the user interface, for example, in a text balloon.

What's next?

Integrating LangChain opens up lots of possibilities for automating workflows, analyzing data, providing search functionality, and more. The contents of this tutorial should give you a good start in building your own AI integrations. Feel free to leave any questions below!

If you found this article useful, let me know on LinkedIn, X or Bluesky. Please share it around the web or subscribe to my YouTube channel for more exciting content on web technologies.

Click the image below to watch the YouTube video version of this blog post:

Getting started

Here's a high-level overview of what we'll cover:

• Setting up a new React project with Vite instead of Create React App
• Creating React components for the header, board, lanes, and tasks
• Passing data and functions between components
• Implementing drag and drop using browser Web APIs
• Replacing CSS with Tailwind classes

You will need to have Node and npm installed on your machine.

Setting up a new React project with Vite

Starting a new project with Vite is as easy as running a single command:

npx create-vite@latest

Upon running this command, you'll be prompted to answer a few questions, including the name for your new project. For this example, let's go with project-board. One of Vite's standout features is its compatibility with a range of JavaScript flavors and frameworks—not just React, but also Preact, Lit, Svelte, and even vanilla JavaScript. We select React as the framework, and opt to use TypeScript as well. Vite handles all the configuration for us and scaffolds the initial project files.

With the project generated, we need to move into the project directory and install the dependencies:

cd project-board
npm install

After the installation is complete, we can start the development server:

npm run dev

The starter Vite React app loads up in the browser, on the endpoint displayed in your terminal.

Next step is to delete the boilerplate content, leaving just an <h1> with "Project Board" for our starting point. We also remove the .svg files and the import statement for it in src/App.tsx.

Creating React components

With a blank slate, we can begin creating React components for the major pieces of the project board:

• Header - simple component that renders the title
• Board - main area that will contain the lanes
• Lane - vertical column for a stage in the workflow
• Task - draggable ticket/card that lives inside a lane

Each component goes in its own file like src/components/Header/Header.tsx:

// src/components/Header/Header.tsx
export default function Header() {
    return (
        <div className="Header">
            <h1>Project Board</h1>
        </div>
    )
}

We can then import and render the Header component in src/App.tsx:

// src/App.tsx
import Header from './components/Header/Header'

export default function App() {
  return (
    <div className="App">
      <Header />
    </div>
  )
}

The Board component is next. It will contain the lanes, so we can start by creating a Lane component in a new file called src/components/Lane/Lane.tsx:

// src/components/Lane/Lane.tsx
export default function Lane() {
    return (
        <div className="Lane">
            <h2>Lane</h2>
        </div>
    )
}

And importing it into Board, which you can create a new file for at src/components/Board/Board.tsx:

// src/components/Board/Board.tsx
import Lane from '../Lane/Lane';

export default function Board() {
  return (
    <div className="Board">
      <Lane />
      <Lane />
      <Lane />
      <Lane />
    </div>
  )
}

Next, we'll create the Task component in src/components/Task/Task.tsx:

// src/components/Task/Task.tsx
export default function Task() {
    return (
        <div className="Task">
            <h3>Task</h3>
        </div>
    )
}

And finally, we can import and render the Board component in App.tsx:

// src/App.tsx
import Header from './components/Header/Header';
import Board from './components/Board/Board';

function App() {
  return (
    <div className="App">
      <Header />
      <Board />
    </div>
  )
}

From this point, we can start adding some basic styling to the components. We'll use "plain old" CSS for this first, and get to Tailwind CSS later:

• Board - first create the styling file src/components/Board/Board.css and add the following:

  /* src/components/Board/Board.css */
  .Board {
    display: flex;
    flex-direction: row;
    justify-content: space-between;
    padding: 1rem;
    margin: 0 auto;
    max-width: 1200px;
  }
  

  And import it into Board.tsx at the top:

  // src/components/Board/Board.tsx
  import './Board.css';
  
  // Everything else...
  

• Lane - create the styling file src/components/Lane/Lane.css and add the following:

  /* src/components/Lane/Lane.css */
  .Lane {
    background-color: #DBEAFE;
    border-radius: 0.5rem;
    flex: 1;
    margin: 0 0.5rem;
    padding: 1rem;
  }
  

  And import it into Lane.tsx at the top:

  // src/components/Lane/Lane.tsx
  import './Lane.css';
  
  // Everything else...
  

• Task - create the styling file src/components/Task/Task.css and add the following:

  /* src/components/Task/Task.css */
  .Task {
    background-color: #fff;
    border-radius: 0.5rem;
    box-shadow: 0 0 0.5rem rgba(0, 0, 0, 0.1);
    margin: 0.5rem 0;
    padding: 1rem;
  }
  

  And import it into Task.tsx at the top:

  // src/components/Task/Task.tsx
  import './Task.css';
  
  // Everything else...
  

• Header - create the styling file src/components/Header/Header.css and add the following:

  /* src/components/Header/Header.css */
  .Header {
    background-color: #e5e7eb;
    box-shadow: 0 0 0.5rem rgba(0, 0, 0, 0.1);
    padding: 1rem;
    text-align: center;
  }
  

  And import it into Header.tsx at the top:

  // src/components/Header/Header.tsx
  import './Header.css';
  
  // Everything else...
  

Make sure to import the CSS files into the components, otherwise the styles won't be applied, the application will look like this:

With the basic styling in place, we can start adding some content to the components to make them look more like a project management board.

Passing data and functions between components

To pass data and functions between components, we'll use props. In React, props are used to pass data from a parent component to a child component. Props are passed to components via HTML attributes, and are accessed in the component via the props object.

Let's start by adding some props to the Lane component. We'll add a title prop to the Lane component, and pass it in from the Board component. As we're using TypeScript, we'll also add a type for the title prop:

// src/components/Lane/Lane.tsx
import './Lane.css';

type LaneProps = {
    title: string;
}

export default function Lane({ title }: LaneProps) {
    return (
        <div className="Lane">
            <h2>{title}</h2>
        </div>
    )
}

And in the Board component, we'll pass in the title prop to each Lane component. We'll create an object for each lane, with an id and title property:

// src/components/Board/Board.tsx
import Lane from "../Lane/Lane";

const lanes = [
    {
        id: 1,
        title: "To Do",
    },
    {
        id: 2,
        title: "In Progress",
    },
    {
        id: 3,
        title: "Review",
    },
    {
        id: 4,
        title: "Done",
    }
]

export default function Board() {
  return (
    <div className="Board">
      {lanes.map(lane => (
        <Lane 
          key={lane.id} 
          id={lane.id}
          title={lane.title} 
        />
      ))}
    </div>
  )
}

We're also passing the prop id to the Lane component, which we'll use later to identify the lane when we implement drag and drop. In the Lane component, we'll already create a type for the id prop:

// src/components/Lane/Lane.tsx
import './Lane.css';

type LaneProps = {
    id: number;
    title: string;
}

export default function Lane({ id, title }: LaneProps) {
    return (
        <div className="Lane">
            <h2>{title}</h2>
        </div>
    )
}

We can now see the lane titles in the browser, but first we'll add some task to fill our page a bit more. We'll use a basic state hook to store the tasks in the Board component:

// src/components/Board/Board.tsx
import { useState } from "react";

// ...

export default function Board() {
    const [tasks, setTasks] = useState([
        {
            "id": 1,
            "title": "Fix navigation bug",
            "body": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque egestas dictum libero, vel tristique odio pulvinar vitae.",
            "laneId": 1
        },
        {
            "id": 2,
            "title": "Release new website",
            "body": "hasellus eleifend lacus vitae est ultrices placerat. Nunc at risus id risus venenatis laoreet sit amet cursus neque.",
            "laneId": 2
        },
        {
            "id": 3,
            "title": "Change button color",
            "body": "Suspendisse ac lorem a neque tempus luctus non aliquam sapien. Cras ut lacus bibendum, placerat nibh eu, tempus neque.",
            "laneId": 3
        },
        {
            "id": 4,
            "title": "Deploy server on acceptance environment",
            "body": "Pellentesque pharetra fermentum sapien, aliquet ultrices ligula mattis porttitor.",
            "laneId": 3
        },
        {
            "id": 5,
            "title": "Change layout for the content page",
            "body": "Cras tellus ligula, mattis at facilisis eu, ultricies vel elit. Ut aliquam volutpat lacus, a rutrum sem vulputate non.",
            "laneId": 3
        },
        {
            "id": 6,
            "title": "Complete the registration flow",
            "body": "In vel commodo ipsum. Duis id ipsum semper, condimentum ipsum sit amet, maximus massa.",
            "laneId": 4
        },
        {
            "id": 7,
            "title": "Create new database instance",
            "body": " Curabitur nec sem lorem. Donec venenatis, arcu vitae malesuada consequat, dolor ante placerat mi, in fermentum diam ipsum id libero.",
            "laneId": 4
        }
    ])

    // Everything else...

}

The values in the laneId property correspond to the id of the lane. We'll use this to filter the tasks and render them in the correct lane. We'll pass the tasks state to the Lane component as a prop, and filter the tasks based on the laneId:

// src/components/Board/Board.tsx

// ...

export default function Board() {
    // ...

    return (
        <div className="Board">
            {lanes.map(lane => (
                <Lane
                    key={lane.id}
                    id={lane.id}
                    title={lane.title}
                    tasks={tasks.filter(task => task.laneId === lane.id)}
                />
            ))}
        </div>
    )
}

In the Lane component, we'll add a type for the tasks prop, and import the component we need to render the tasks in the lane:

// src/components/Lane/Lane.tsx
import './Lane.css';
import Task from "../Task/Task";

type LaneProps = {
    id: number;
    title: string;
    tasks: {
        id: number;
        title: string;
        body: string;
        laneId: number;
    }[];
}

export default function Lane({ id, title, tasks }: LaneProps) {

  // ...

}

And render the tasks in the Lane component by mapping over the tasks prop and rendering a Task component for each task:

// src/components/Lane/Lane.tsx
// ...

export default function Lane({ id, title, tasks }: LaneProps) {
    return (
        <div className="Lane">
            <h2>{title}</h2>
            <div>
                {
                    tasks.map((task) => {
                        return (
                            <Task
                                key={task.id}
                                id={task.id}
                                title={task.title}
                                body={task.body}
                                laneId={task.laneId}
                            />
                        )
                    })
                }
            </div>
        </div>
    )
}

Finally, we need to update the Task component to accept the new props:

// src/components/Task/Task.tsx
import './Task.css';

type TaskProps = {
    id: number;
    title: string;
    body: string;
    laneId: number;
}

export default function  Task({ id, title, body, laneId }: TaskProps) {
    return (
        <div className="Task">
            <h3>{title}</h3>
            <p>{body}</p>
        </div>
    )
}

In the browser, we can now see the tasks in the correct lanes:

Fantastic! We now have a basic project board with lanes and tasks. Next, we'll implement drag and drop to make the tasks draggable between lanes.

Implementing drag and drop using browser Web APIs

To make the tasks draggable, we utilize the browser's native drag and drop API. The drag and drop API consists of a set of events that are fired when a draggable element is dragged, dropped, or dragged over another element. We'll use the following events:

• dragstart - fired when the user starts dragging an element
• dragover - fired when the user drags an element over another element
• drop - fired when the user drags an element over another element

First, we'll create two functions that handle the dragstart and dragover events. This function will be called when the user starts dragging a task. We'll add the function to the Board component:

// src/components/Board/Board.tsx
// ...

function handleOnDragStart(event: React.DragEvent, id: number) {
    console.log('Drag event started', { id })
    event.dataTransfer.setData("id", id.toString());
}

function handleOnDragOver(event: React.DragEvent) {
    event.preventDefault();
}

export default function Board() {
    // ...

        return (
        <div className="Board">
            {lanes.map(lane => (
                <Lane
                    key={lane.id}
                    id={lane.id}
                    title={lane.title}
                    tasks={tasks.filter(task => task.laneId === lane.id)}
                    handleOnDragStart={handleOnDragStart}
                    handleOnDragOver={handleOnDragOver}
                    handleOnDrop={handleOnDrop}
                />
            ))}
        </div>
    )
}

The handleOnDragStart function takes two arguments: the event object and the id of the task. We'll use the id to identify the task when we drop it in another lane. The handleOnDragOver function takes only the event object as an argument. We'll use this function to prevent the default behavior of the dragover event, which is to not allow dropping on an element.

We'll need to add the onDragStart and onDragOver event handlers to the Lane and Task components, and pass in the functions we just created:

• Lane:

First, add the functions to the types and props for the component:

// src/components/Lane/Lane.tsx

// ...

type LaneProps = {
    id: number;
    title: string;
    tasks: {
        id: number;
        title: string;
        body: string;
        laneId: number;
    }[];
    handleOnDragStart: (event: React.DragEvent, id: number) => void;
    handleOnDragOver: (event: React.DragEvent) => void;
}

export default function Lane({ id, title, tasks, handleOnDragStart, handleOnDragOver }: LaneProps) {
  // ...

}

Then, pass the functions to the onDragStart and onDragOver event handlers or the component:

// src/components/Lane/Lane.tsx
// ...

    return (
        <div 
          className="Lane"
          onDragOver={handleOnDragOver}
        >
            <h2>{title}</h2>
            <div>
                {
                    tasks.map((task) => {
                        return (
                            <Task
                                key={task.id}
                                id={task.id}
                                title={task.title}
                                body={task.body}
                                laneId={task.laneId}
                                handleOnDragStart={handleOnDragStart}
                            />
                        )
                    })
                }
            </div>
        </div>
    )
}

• Task:

We passed the function handleOnDragStart to the Task component as a prop, and now add it to the types and props for the component. Also, we add the onDragStart event handler and the draggable attribute to the Task component:

// src/components/Task/Task.tsx
// ...

export default function  Task({ id, title, body, laneId }: TaskProps) {
    return (
        <div 
          className="Task"
          draggable
        >
            <h3>{title}</h3>
            <p>{body}</p>
        </div>
    )
}

You can now drag the tasks around, but they don't do anything yet. We'll create a function to handle the drop event, and add it to the Board component:

// src/components/Board/Board.tsx
// ...

export default function Board() {
    // ...

    function handleOnDrop(event: React.DragEvent, laneId: number) {
        const id = event.dataTransfer.getData("id");

        const task = tasks.find((task) => task.id === parseInt(id));

        if (task) {
            const newTasks = tasks.filter((task) => task.id !== parseInt(id));
            setTasks(newTasks.concat({ ...task, laneId }));
        }
    }

    return (
      // ...
    )
}

The handleOnDrop function takes two arguments: the event object and the laneId of the lane where the task is dropped. We'll use the laneId to update the laneId of the task. We'll also use the event object to get the id of the task that is being dropped. We'll use this id to identify the task in the tasks array, and update the laneId of the task.

We'll need to pass the handleOnDrop function to the Lane component:

// src/components/Board/Board.tsx
// ...

    return (
        <div className="Board">
            {lanes.map(lane => (
                <Lane
                    key={lane.id}
                    id={lane.id}
                    title={lane.title}
                    tasks={tasks.filter(task => task.laneId === lane.id)}
                    handleOnDrop={handleOnDrop}
                />
            ))}
        </div>
    )
}

And add it to the types and props for the Lane component, where the onDrop event handler is also added to the div element. The function is called with the event object and the id of the lane:

// src/components/Lane/Lane.tsx
// ...

type LaneProps = {
    // ...
    handleOnDragStart: (event: React.DragEvent, id: number) => void;
    handleOnDragOver: (event: React.DragEvent) => void;
    handleOnDrop: (event: React.DragEvent, laneId: number) => void;
}

export default function Lane({ id, title, tasks, handleOnDragStart, handleOnDragOver, handleOnDrop }: LaneProps) {
    return (
        <div 
            className="Lane"          
            onDragOver={handleOnDragOver}
            onDrop={(event) => handleOnDrop(event, id)}
        >
            // ...
    )
}

Et voilà! You can now drag the tasks between lanes!

Replacing CSS with Tailwind classes

Now that we have the drag and drop functionality in place, we can start replacing the CSS with Tailwind classes. Tailwind makes it easy to style your components without having to write any CSS. In some ways it's comparable to Bootstrap, which is one of the easiest was to style React applications. We'll start by installing Tailwind and its dependencies, and then configure it to work with Vite:

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

You can find the most recent installation guide for Vite and Tailwind here.

Once the installation is complete, we'll need to configure Tailwind to work with Vite. We'll do this by adding the following to the tailwind.config.ts file, which is created by the npx tailwindcss init -p command:

// tailwind.config.ts
/** @type {import('tailwindcss').Config} */
export default {
  content: [
    "./index.html",
    "./src/**/*.{js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

Tailwind is now configured to work with Vite. We'll need to import the Tailwind CSS files with base styling into the src/index.css file:

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

Make sure to check if the index.css file is imported in the src/main.tsx file. If not, add the following line to the top of the file:

// src/main.tsx
import './index.css'

// Everything else...

Restart the development server, and you should see the Tailwind styles applied to the application.

We can now start replacing the CSS with Tailwind classes. We'll start with the Board component, and replace the CSS with Tailwind classes. Also, the import statement for the Board.css CSS file can be removed:

// src/components/Board/Board.tsx
// ...

    return (
        <div className="grid grid-cols-4 gap-4">
            {lanes.map(lane => (
                <Lane
                    key={lane.id}
                    id={lane.id}
                    title={lane.title}
                    tasks={tasks.filter(task => task.laneId === lane.id)}
                    handleOnDragStart={handleOnDragStart}
                    handleOnDragOver={handleOnDragOver}
                    handleOnDrop={handleOnDrop}
                />
            ))}
        </div>
    )
}

Next, we'll replace the CSS in the Lane component with Tailwind classes. We'll also remove the import statement for the Lane.css CSS file:

// src/components/Lane/Lane.tsx
// ...

  return (
    <div 
      className="bg-blue-100 p-4"
      onDragOver={handleOnDragOver}
      onDrop={(event) => handleOnDrop(event, id)}
    >
      <h2 className="text-center text-xl font-bold mb-4">{title}</h2>
      <div>
        // ...  

  )
}

Also, we'll replace the CSS in the Task component with Tailwind classes. We'll also remove the import statement for the Task.css CSS file:

// src/components/Task/Task.tsx
// ...

  return (
    <div 
      className="bg-white border border-gray-400 p-4 rounded-lg mb-4"
      draggable
      onDragStart={(event) => handleOnDragStart(event, id)}
    >
      <h3>{title}</h3>
      <p>{body}</p>
    </div>
  )
}

And finally, we'll replace the CSS in the Header component with Tailwind classes. We'll also remove the import statement for the Header.css CSS file:

// src/components/Header/Header.tsx
export default function Header() {
    return (
        <div className="bg-blue-600 white p-6 mb-4">
            <h1 className="text-center text-white text-6xl">Project Board</h1>
        </div>
    )
}

And that's it! We now have a fully functional project management board built with React, TypeScript, and Tailwind CSS.

Learn more

You can find the full source code for this project on GitHub or watch the recording on my YouTube channel. If you found this article useful, let me know on LinkedIn, X or Bluesky. Please share it around the web or subscribe to my YouTube channel for more exciting content on web technologies.

Click the image below to watch the YouTube video version of this blog post:

Short vs. Long Answer

The short answer (as is the answer to any hard problem in software engineering) is "It depends". However, the long answer is more nuanced and depends on various factors. As a solo developer or a small startup team, you may not necessarily need GraphQL. However, if you are a growing organization or an enterprise, it is essential to consider the benefits of GraphQL. Let's dive into this topic and explore the long-form answer.

What are React Server Components?

The introduction of React Server Components in Next.js 14 is something many developers have been eagerly awaiting. By writing React components server-side and subsequently requesting the data displayed in that component server-side as well, you can reduce the bundle size of your application. The diagram below shows how React Server Components work:

Overview of how React Server Components work. Source: Next.js

React Server Components bring us back to the MVC (Model, View, Controller) days that some of you might remember from PHP. Data fetching was coupled with the view, which is something that we moved away from when we started building single-page applications with JavaScript frameworks React. When we ditched MVC, we lost server-side rendering and embraced client-side rendering. But for all sorts of reasons, in recent years we returned to server-side rendering.

Why are developers debating server components? Well, it means that you (for example) can now query databases directly from your React components, which means that (in theory) you no longer need to use GraphQL or other data-fetching libraries like React Query. Instead, you can use React Server Components to fetch data from your database and render it directly in your React components:

Still from a talk at Next.js Conf 2023

In the example above, we are querying a database directly from a React component. This is something that was not possible before React Server Components. The React team has been working on this feature for a while now, and it's finally available in Next.js 14. However, it's important to note that this feature is still experimental and not recommended for production use. Furthermore, I would argue that it's not a good idea to query a database directly from your React components.

When Should You Use GraphQL?

So when should you use GraphQL? GraphQL shines when you need to maintain relationships between multiple backends and applications.

Don't know what GraphQL is? Check out my Why Developers Love GraphQL blog post.

It excels in scenarios where you have a one-to-many or many-to-many setup. By using GraphQL Federation or GraphQL Fusion (a newer federation spec from the GraphQL Foundation), you can bring together multiple GraphQL backends and have a single source of truth for different backends. This empowers developers integrating with your GraphQL API to have control over the data they load into their applications.

In the above 1:1 relations React Server Components offer convenience and rapid prototyping for solo developers or teams that are moving fast. Having to maintain a GraphQL API on top of your database can be a lot of work, especially if you are a small team. There are solutions out there that can help you with this, such as StepZen, which I highly recommend checking out (I was working at StepZen, before joining IBM after our acquisition). With just a few lines of code, you can generate a GraphQL API on top of your database. This is a great solution for small teams that want to move fast and don't want to maintain a GraphQL API on top of their database.

However, it's important to consider the size of your product and the capacity of your team. GraphQL may introduce complexity that isn't necessary for small-scale applications or teams still relying on a one-to-one connection between their backend data source and front-end application. In such cases, the added complexity might outweigh the benefits provided by GraphQL. Alternatively, you could try tRPC, which is a great alternative to GraphQL when you're building your entire stack with TypeScript. A good talk I recommend watching is The Right Size for GraphQL by The Browne at the last GraphQL Conf in San Francisco last September.

Conclusion

In conclusion, the question of whether we still need GraphQL in a world of React Server Components is subjective. Server components have the potential to speed up web experiences and offer more flexibility in scaling applications. However, I have reservations about how well they will scale in the long run, especially when serving numerous users. For example, querying a database directly from a React component, as shown in the Next.js Conf example, is not recommended. Growing teams would likely benefit more from using other solutions like tRPC or GraphQL.

If you decide to adopt GraphQL for your startup, product, or team, I recommend exploring other resources, such as my YouTube videos, where I discuss GraphQL extensively. Feel free to reach out to me on LinkedIn, X or Bluesky too.

Click the image below to watch the YouTube video version of this blog post:

What's wrong with Create React App?

While Create React App (CRA) has been a popular choice for bootstrapping React applications, it's important to note that it's not inherently "wrong" or "bad." Rather, there are limitations and scenarios where other tools may be a better fit. Below are some common critiques developers have about Create React App:

• Lack of maintainability: Create React App is a large project with a lot of moving parts. As such, it can be difficult to maintain and update. This is especially true when you consider that Create React App isn't maintained by the React core team or any other official organization.

• Limited to Webpack: CRA is tightly coupled with webpack. While webpack is powerful, it can be complex to configure, and it's not the only module bundler out there. Alternatives like Vite use the native ES modules feature in modern browsers for faster development and smaller builds, without relying on webpack.

• Bad tree shaking: Although webpack supports tree shaking, CRA does not make it as straightforward as some developers would like. In other tools like Vite or Rollup, tree shaking is often more efficient, which helps in reducing the final bundle size.

And much more can be said about why React developers started to dislike using Create React App.

Why Vite Over Create React App?

While Create React App has been an industry standard for bootstrapping React applications, it's not without its limitations—namely, its lack of build optimizations for production-grade applications. On the other hand, Vite offers various features and optimizations aimed at improving both your build size and development speed. Here are some of the key benefits of using Vite over Create React App:

• Faster development: Vite offers a lightning-fast development server that leverages native ES modules in modern browsers. This means that your code is compiled on the fly, which results in faster development times.

• Proper maintenance: Vite is maintained by the Vue core team, which means that it's more likely to receive updates and bug fixes than Create React App.

• Smaller bundle size: Vite uses Rollup under the hood, which is a module bundler that's known for its tree-shaking capabilities. This means that Vite can produce smaller bundles than Create React App.

As you can see from the list above it's an excellent choice for those who have found Create React App's capabilities limiting.

Setting Up a New Project with Vite

Starting a new project with Vite is as easy as running a single command:

npx create-vite

Upon running this command, you'll be prompted to answer a few questions, including the name for your new project. For this example, let's go with "vite-project". One of Vite's standout features is its compatibility with a range of JavaScript flavors and frameworks—not just React, but also Preact, Lit, Svelte, and even vanilla JavaScript.

After setup, your project directory will look quite familiar if you've ever used Create React App before. You'll see directories like public and src containing your static assets and React components, respectively. Additionally, you'll find crucial configuration files like package.json and vite.config.js. If you're into TypeScript, it's good to know that a tsconfig.json will also be present.

To install all dependencies, execute:

npm install

Open your project in your IDE of choice — let's use Visual Studio Code for this example. Vite's primary configuration can be found in vite.config.ts. Unlike Create React App, which relies heavily on webpack, Vite allows you to place all your plugins and configurations within this single file.

To fire up your local development server, run:

npm run dev

Doing this will launch your Vite application, which you can then view in your browser. The development server offers hot-reloading and other features that make development a breeze.

Building Your React App

Once the development server is running, building out your React application using Vite is fundamentally the same as it would be with Create React App. You're free to create new components, apply styles using CSS, or even employ other styling libraries like Tailwind CSS. Additional configurations for certain libraries can be made in the vite.config.ts file, but Vite is generally designed to be compatible with most existing libraries.

If you've been following the latest advice from the React core team, you might find Vite to be a recommended alternative to Create React App for future projects. It's a promising choice for those looking to stay ahead of the curve in the rapidly evolving frontend development landscape.

Conclusion

Vite is positioning itself as the modern solution for building efficient and fast React applications. With features designed to optimize both build size and development speed, it stands as a compelling alternative to Create React App. So why not give Vite a try? It could be the game-changer you've been waiting for in your React development.

If you found this article useful, let me know on LinkedIn, X or Bluesky. Please share it around the web or subscribe to my YouTube channel for more exciting content on web technologies.

Click the image below to watch the YouTube video version of this blog post:

Introduction to GraphQL IDEs

Before diving into our comparison, let's quickly understand what a GraphQL IDE is. A GraphQL IDE is a tool that helps developers interact with GraphQL APIs, very similar to how your text-editor (like VSCode or IntelliJ) helps you write code.

These IDEs provide several functionalities, such as auto-completion, error highlighting, and interactive documentation. They help developers to construct and test GraphQL queries and mutations, visualize the returned data, and understand the structure of the GraphQL schema.

Two popular GraphQL IDEs are GraphiQL and Altair. Let's take a closer look at each.

GraphiQL

GraphiQL is one of the most well-known GraphQL IDEs. Originally developed by Facebook, it is an in-browser tool that enables developers to write, validate, and test GraphQL queries. It is open-source and can be integrated into any project that uses GraphQL. Recently, GraphiQL has been revamped with a new UI and several new features as you can read in ths blog post I wrote earlier.

The most important features of GraphiQL are:

• Schema introspection: GraphiQL offers a robust view of the schema, letting you examine types, fields, and overall structure.

• Autocompletion: Based on the schema, GraphiQL provides autocompletion, making it easier to construct complex queries.

• Syntax highlighting: This feature makes it easier to understand and navigate through the GraphQL queries and mutations. This includes errors. If you make a syntax mistake, GraphiQL will underline it immediately.

• Interactive Documentation: GraphiQL builds an interactive GraphQL API documentation on-the-fly, making it easy to understand the API.

• Query history: This feature lets you access your previous queries, so you don't have to rewrite them.

As mentioned, if you want to learn more about GraphiQL then check out this blog post I wrote earlier.

Altair

Altair GraphQL Client is another impressive GraphQL IDE. It is open-source and available as a desktop app for all major operating systems, as well as a web extension for Chrome and Firefox.

There's a lot of features that Altair offers that you can also find in GraphiQL, but here are some of the most important ones:

• Multiple Windows: Altair allows you to open multiple windows at the same time, enabling you to work with different queries (and GraphQL APIs) simultaneously.

• Autocompletion & Error Highlighting: Like GraphiQL, Altair also offers autocompletion and error highlighting.

• Subscriptions: Altair supports GraphQL subscriptions, enabling real-time updates.

• File Uploads: Altair supports GraphQL multipart request specification (Multipart request), allowing you to test file uploads.

• Pre-request scripting: You can write scripts that run before the request is sent. This is useful for handling complex authentication flows.

• Collections:: Perhaps the most powerful feature of Altair is the ability to create collections of queries and mutations. This allows you to organize your queries and mutations across multiple GraphQL APIs in a logical way.

Of course, there are many more features that Altair offers. If you want to learn more about Altair, then check out the official documentation.

So how do GraphiQL and Altair compare? Let's find out.

Comparing GraphiQL and Altair

GraphiQL and Altair share a common set of features like schema introspection, syntax highlighting, error highlighting, and auto-completion. However, they have some distinctive attributes as well.

While GraphiQL's interactive documentation and query history make API exploration and reiteration of queries more comfortable, it lacks some advanced features like pre-request scripting, file uploads, and subscriptions, which are provided by Altair.

On the other hand, Altair shines with its extensive feature set, providing advanced functionalities that make it more versatile for complex use-cases. The ability to handle file uploads and work with multiple GraphQL APIs simultaneously is a huge plus.

To see a side-by-side comparison of GraphiQL and Altair, check out the video on my YouTube channel.

Or find me on LinkedIn, X or Bluesky. I'd love to hear from you!

Click the image below to watch the YouTube video version of this blog post:

React Router history

React Router has become a popular choice for managing routing in React applications and is widely used in both small and large applications. It is also highly customizable, allowing developers to create custom routing logic and integrate it into their applications. Currently, the library is maintained by the team behind Remix, a React-based framework for building web applications.

With React Router, you can define routes and their corresponding components using a declarative syntax. When the user navigates to a particular URL, React Router will render the corresponding component for that URL. React Router also provides features such as nested routes, route parameters, and query parameters. One of the biggest advantages of React Router is that it works with any Reaac application, regardless of the framework or library that is used.

Setting up React Router

React Router is a JavaScript library, so you can use a package manager such as npm or Yarn. Assuming you already have a React project set up, you can follow these steps to install React Router using npm:

Open your terminal and navigate to your React project directory. Run the following command to install React Router:

npm install react-router-dom

This will install React Router and its dependencies.

Once the installation is complete, you can use React Router in your application. To get started, you can import the necessary methods and components from React Router as you'll learn in the next step.

Creating routes

To create routes in React Router, you can use the createBrowserRouter method with the RouterProvider component. With createBrowserRouter you define the available routes and their corresponding component. You can use the path prop to define the URL path for the route, and the element prop to define the component that should be rendered when the user navigates to the route.

The following example shows how to create a route for the /about URL path:

import { createBrowserRouter, RouterProvider } from 'react-router-dom';

function About() {
  return <h1>About</h1>;
}

const router = createBrowserRouter([
  {
    path: '/about',
    element: <About />,
  },
]);

function App() {
  return (
    <RouterProvider value={router}>
      {/* Your components */}
    </RouterProvider>
  );
}

When the user navigates to the /about URL path, React Router will render the About component. But how would you handle nested routes? For example, what if you want to share the same layout for multiple routes? In the next section, you'll learn how to create nested routes and layouts using the <Outlet /> component.

Use <Outlet /> to create children routes

With React Router 6, you can define nested routes using the children field in the route object. This allows you to create layouts that can be shared across multiple routes.

Let's say you want to create a layout that contains a header and a footer. You can use the element prop to define the layout component and the children field to define the nested routes. The following example shows how to create a layout that contains a header and a footer:

import { createBrowserRouter, RouterProvider, Outlet } from 'react-router-dom';

function About() {
  return <h1>About</h1>;
}

function Layout() {
  return (
    <div>
      <header>
        <h1>Layout</h1>
      </header>
      <Outlet />
      <footer>Copyright 2023</footer>
    </div>
  );
}

const router = createBrowserRouter([
  {
    path: '/',
    element: <Layout />,
    children: [
      {
        path: 'about',
        element: <About />,
      },
    ],
  },
]);

You can use the <Outlet /> component to render nested routes. This allows you to create layouts that can be shared across multiple routes, reducing the amount of duplicated code in your application.

React Router 6 parameters

React Router 6 allows you to pass parameters to routes. This will enable you to create dynamic routes that can be used to render different components based on the parameters that are passed to the route.

To pass parameters to a route, you can add the params to the path field in the route object. The following example shows how to pass a userId parameter to the /user/:userId route:

const router = createBrowserRouter([
  {
    path: '/',
    element: <Layout />,
    children: [
      {
        path: 'about',
        element: <About />,
      },
      {
        path: 'user/:userId',
        element: <User />,
      },
    ],
  },
]);

And the following example shows how to retrieve the userId parameter with the useParams hook in the User component:

import { useParams } from 'react-router-dom';

function User() {
  const { userId } = useParams();

  return <h1>User {userId}</h1>;
}

You can use the useParams hook to retrieve the parameters that are passed to the route. The useParams hook returns an object with the parameters that are passed to the route.

Keep learning

In this blog post, you learned how to bootstrap React Router 6, create layouts using the new <Outlet> component, and pass parameters to routes. If you want to learn more about React Router 6, you can check out the official documentation. Also, keep an eye out for my YouTube channel, where I'll post more videos about React and React Router 6.

> Subscribe to my YouTube channel

Or find me on LinkedIn, X or Bluesky. I'd love to hear from you!

Click the image below to watch the YouTube video version of this blog post:

What is React?

React is a JavaScript library that is widely used for building user interfaces, particularly for single-page applications. It allows you to create reusable components that can be rendered on the web, mobile, or desktop. Today, it is one of the most popular tools for front-end web development.

So, if you're interested in learning React, where do you start?

JavaScript

First, it's important to have a solid understanding of JavaScript. React is built with JavaScript, so you'll need to be comfortable with the basics of the language before you dive into React.

Once you've got a handle on JavaScript, the next step is to familiarize yourself with the React syntax and concepts.

Components

One of the core principles of React is that a component should be a self-contained piece of code that is easy to understand and maintain.

This is what a component looks like:

function MyComponent() {
  return (
    <div>
      <h1>My Component</h1>
    </div>
  );
}

A component is a JavaScript function that returns a React element. It can be a simple function that returns a single element, or it can be a more complex component that returns multiple elements or has state.

Data flows

In React, data flows in a single direction from the parent component to the child component, following the unidirectional data flow principle. This helps make applications easier to reason about and debug.

Parent components can pass data to child components using props, below is an example of a child compoinent that receives data from a parent component:

function MyComponent() {
  return (
    <div>
      <Title title='My Component' />
    </div>
  );
}

function Title({ title }) {
  return <h1>{title}</h1>;
}

Props are used to keep track of data that is passed from a parent component to a child component. They are immutable, which means that they cannot be changed once they are passed to a child component.

State

State is a special type of data that is managed by a component. It is used to store data that is specific to a component and it can be passed on to other components lower in the tree. State is often used to store data that is used to render the UI, such as a list of items or a user's name.

State can be managed using the useState hook, which is a function that returns an array with two values: the current state and a function that can be used to update the state:

import React, { useState } from 'react';

function MyComponent() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <Counter count={count} setCount={setCount} />
    </div>
  );
}

function Counter({ count, setCount }) {
  return (
    <div>
      <p>{count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}

Virtual DOM

React uses a virtual DOM (Document Object Model) to optimize updates and minimize the number of DOM mutations. This makes applications built with React faster and more efficient.

The Virtual DOM is a virtual representation of a user interface, which is kept in memory and synchronized with the "real" DOM by for example ReactDOM.

Ecosystem

React also has a large ecosystem of tools and libraries that can be leveraged to build amazing applications. Some popular ones include Tanstack Query for data fetching, Tailwind for styling and Next.js or Remix for server-rendered React applications.

Building Projects

It's also a good idea to start building some small projects with React to get a feel for how it works in practice. There are plenty of resources available online that can help you get started with your first React project, including templates and starter kits.

Need inspiration for a project?

you might want to have a look at my book React Projects. Which walks you through all the React concepts in 10 chapters. You'll build 10 unique projects. These are a "movie list" (like IMDB), a developer portfolio website using Github, a mobile game application and much more.

Keep learning

Finally, keep in mind that learning React is an ongoing process. As you build more complex projects and encounter new challenges, you'll continue to learn and improve your skills.

The comings months I'll livestreams on building these projects - and the first ones are already uploaded. So if you're interested in learning React, make sure to subscribe to my YouTube channel.

> Subscribe to my YouTube channel

Or find me on LinkedIn, X or Bluesky. I'd love to hear from you!

Click the image below to watch the YouTube video version of this blog post:

This blog post is extracted from my book React Projects, available on Packt and Amazon.

Why use Bootstrap?

IMO, Bootstrap is still the easiest way to style a React application. Bootstrap has been around for a long time and is widely used across web applications of all sorts and sizes. And build with different frameworks or tools, ranging from WordPress to React. There are a few reasons why you might want to use Bootstrap to style a React app:

• Ease of use: Bootstrap is a well-documented and widely-used CSS framework, making it easy to start and learn.
• Responsive design: Bootstrap includes a responsive grid system and predefined styles for common UI elements, which makes it easier to build a responsive app that looks good on multiple devices.
• Time savings: Using a CSS framework like Bootstrap can save you time by providing a set of pre-styled UI components that you can use out-of-the-box, rather than style everything from scratch.
• Consistency: By using a common CSS framework, you can ensure that your app has a consistent look and feel, which can improve the user experience.

Overall, Bootstrap (or any other CSS framework) can be useful for building a well-designed and responsive React app more efficiently.

Installing Bootstrap

You can install Bootstrap using npm or yarn. For this blog post, we will use npm:

npm install --save-dev bootstrap

This will install Bootstrap as a devDependency in your project, and it will only be used during development and will not be included in the production build. By installing Bootstrap you can now include the CSS in your project by importing it in the root of your React project, for example, your index.js file that contains the root component of your app:

import ReactDOM from 'react-dom/client';
import List from './containers/List';

import 'bootstrap/dist/css/bootstrap.min.css';

function App() {
  // ...
}

const container = document.getElementById('app');
const root = ReactDOM.createRoot(container);

root.render(<App />);

The important part in the code block above is the line import 'bootstrap/dist/css/bootstrap.min.css', which will import the Bootstrap CSS file from the node_modules directory. This will make the Bootstrap styles available to your app.

Using Bootstrap components

Bootstrap includes several pre-styled components that you can use in your React app. For example, you can use the NavBar component to add a header element to your application.

To use this component, you can copy-paste the following code block and use it in your app:

import React from 'react';
import 'bootstrap/dist/css/bootstrap.css';

export default function Header() {
  return (
    <nav class="navbar bg-body-tertiary">
      <div class="container-fluid">
        <a class="navbar-brand" href="#">
          <img src="https://getbootstrap.com/docs/5.3/assets/brand/bootstrap-logo.svg" alt="Logo" width="30" height="24" class="d-inline-block align-text-top">
          Bootstrap
        </a>
      </div>
    </nav>
  )
}

Which will render the following header:

By adding the correct class names to HTML elements, you will get a modern-looking header that you don't need to style.

Of course, there are much more Bootstrap components that you can use in your React app. For example, you can use the Card component to render a card with a title, image, and text:

import React from 'react';
import 'bootstrap/dist/css/bootstrap.css';

export default function Card() {
  return (
    <div class='card' style='width: 18rem;'>
      <img src='...' class='card-img-top' alt='...' />
      <div class='card-body'>
        <h5 class='card-title'>Card title</h5>
        <p class='card-text'>
          Some quick example text to build on the card title and make up the
          bulk of the card's content.
        </p>
        <a href='#' class='btn btn-primary'>
          Go somewhere
        </a>
      </div>
    </div>
  );
}

Which will render the following card:

With just a few lines of HTML you can render a card with a title, image, and text. And you can extend this further by using Bootstrap utilities or custom CSS to style the card even more.

Bootstrap utilities

Bootstrap includes a set of utility classes that can be used to apply common styles quickly and easily. These utility classes are designed to be used in conjunction with other Bootstrap styles and can be used to override or extend the default styles of certain elements.

Some of the Bootstrap utilities include:

• .text-*: These classes can be used to apply different colors to text, depending on the context (e.g. .text-primary, .text-secondary, etc.).
• .bg-*: These classes can be used to apply different background colors to elements (e.g. .bg-primary, .bg-secondary, etc.).

Let's look at an example:

import React from 'react';
import 'bootstrap/dist/css/bootstrap.css';

function App() {
  return (
    <div className="container mt-5">
      <div className="row">
        <div className="col-md-6">
          <div className="card bg-primary text-white">
            <div className="card-body">
              <h5 className="card-title">Primary Card</h5>
              <p className="card-text">Some quick example text to build on the card title and make up the bulk of the card's content.</p>
            </div>
          </div>
        </div>
        <div className="col-md-6">
          <div className="card bg-secondary text-white">
            <div className="card-body">
              <h5 className="card-title">Secondary Card</h5>
              <p className="card-text">Some quick example text to build on the card title and make up the bulk of the card's content.</p>
            </div>
          </div>
        </div>
      </div>
    </div>
  );
}

export default App;

In this example, we use Bootstrap's grid system to create a layout with two equal-width columns, and we use the .bg-primary and .bg-secondary classes to give the cards different background colors. We are also using the .text-white class to make the text white to be visible against the colored backgrounds.

These are just a few examples of Bootstrap utilities. Many others are available, and you can find more information in the Bootstrap documentation.

Conclusion

This blog post has shown how to use Bootstrap 5 to style a React application. With Bootstrap you don't have to write any stying rules yourself. Instead, you can use class names to apply styles to HTML elements. Of course, you can also use Bootstrap utilities to apply common styles quickly and easily.

This blog post is extracted from my book React Projects, available on Packt and Amazon.

I hope you learned some new things about styling in React! Any feedback? Let me know by connecting to me on LinkedIn, X or Bluesky. Or leave a comment on my YouTube channel.

Click the image below to watch the YouTube video version of this blog post:

This blog post is extracted from my book React Projects, available on Packt and Amazon.

Setting up a new project

Before you can start building your new React project, you will need to create a new directory on your local machine. For this blog (which is based upon the book React Projects), you can name this directory 'chapter-1'.

To initiate the project, navigate to the directory you just created and enter the following command in the terminal:

npm init -y

This will create a package.json file with the minimum information required to run a JavaScript/React project. The -y flag allows you to bypass the prompts for setting project details such as the name, version, and description.

After running this command, you should see a package.json file created for your project similar to the following:

{
  "name": "chapter-1",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

Now that you have created the package.json file, the next step is to add Webpack to the project. This will be covered in the following section.

Adding Webpack to the project

In order to run the React application, we need to install Webpack 5 (the current stable version at the time of writing) and the Webpack CLI as devDependencies. Webpack is a tool that allows us to create a bundle of JavaScript/React code that can be used in a browser. Follow these steps to set up Webpack:

1. Install the necessary packages from npm using the following command:

npm install --save-dev webpack webpack-cli

2. After installation, these packages will be listed in the package.json file and can be run in our start and build scripts. But first, we need to add some files to the project:

chapter-1
|- node_modules
|- package.json
   |- src
      |- index.js

This will add an index.js file to a new directory called src. Later, we will configure Webpack so that this file is the starting point for our application.

3. Add the following code block to this file:

console.log('Rick and Morty');

4. To run the code above, we will add start and build scripts to our application using Webpack. The test script is not needed in this case, so it can be removed. Also, the main field can be changed to private with the value of true, as the code we are building is a local project:

{
  "name": "chapter-1",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "webpack --mode=development",
    "build": "webpack --mode=production"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

The npm start command will run Webpack in development mode, while npm run build will create a production bundle using Webpack. The main difference is that running Webpack in production mode will minimize our code and reduce the size of the project bundle.

5. Run the start or build command from the command line; Webpack will start up and create a new directory called dist.

chapter-1
|- node_modules
|- package.json
   |- dist
      |- main.js
   |- src
      |- index.js

6. Inside this directory, there will be a file called main.js that includes our project code and is also known as our bundle. If successful, you should see the following output:

asset main.js 794 bytes [compared for emit] (name: main)
./src/index.js 31 bytes [built] [code generated]
webpack compiled successfully in 67 ms

The code in this file will be minimized if you run Webpack in production mode.

7. To test if your code is working, run the main.js file in your bundle from the command line:

node dist/main.js

This command runs the bundled version of our application and should return the following output:

> node dist/main.js
Rick and Morty

Now, we're able to run JavaScript code from the command line. In the next part of this blog post, we will learn how to configure Webpack so that it works with React.

Configuring Webpack for React

Now that we have set up a basic development environment with Webpack for a JavaScript application, we can begin installing the packages necessary to run a React application. These packages are react and react-dom, where the former is the core package for React and the latter provides access to the browser's DOM and allows for rendering of React. To install these packages, enter the following command in the terminal:

npm install react react-dom

However, simply installing the dependencies for React is not enough to run it, since by default, not all browsers can understand the format (such as ES2015+ or React) in which your JavaScript code is written. Therefore, we need to compile the JavaScript code into a format that can be read by all browsers.

To do this, we will use Babel and its related packages to create a toolchain that allows us to use React in the browser with Webpack. These packages can be installed as devDependencies by running the following command:

In addition to the Babel core package, we will also install babel-loader, which is a helper that allows Babel to run with Webpack, and two preset packages. These preset packages help determine which plugins will be used to compile our JavaScript code into a readable format for the browser (@babel/preset-env) and to compile React-specific code (@babel/preset-react).

Now that we have the packages for React and the necessary compilers installed, the next step is to configure them to work with Webpack so that they are used when we run our application.

npm install --save-dev @babel/core babel-loader @babel/preset-env @babel/preset-react

To do this, configuration files for both Webpack and Babel need to be created in the src directory of the project: webpack.config.js and babel.config.json, respectively. The webpack.config.js file is a JavaScript file that exports an object with the configuration for Webpack. The babel.config.json file is a JSON file that contains the configuration for Babel.

The configuration for Webpack is added to the webpack.config.js file to use babel-loader:

module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
        },
      },
    ],
  },
};

This configuration file tells Webpack to use babel-loader for every file with the .js extension and excludes files in the node_modules directory from the Babel compiler.

To utilize the Babel presets, the following configuration must be added to babel.config.json:

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "targets": {
          "esmodules": true
        }
      }
    ],
    [
      "@babel/preset-react",
      {
        "runtime": "automatic"
      }
    ]
  ]
}

In the above @babel/preset-env must be set to target esmodules in order to use the latest Node modules. Additionally, defining the JSX runtime to automatic is necessary since React 18 has adopted the new JSX Transform functionality.

Now that we have set up Webpack and Babel, we can run JavaScript and React from the command line. In the next section, we will write our first React code and run it in the browser.

Rendering React components

Now that we have installed and configured the packages necessary to set up Babel and Webpack in the previous sections, we need to create a real React component that can be compiled and run. This process involves adding some new files to the project and making changes to the Webpack configuration:

1. Let's edit the index.js file that already exists in our src directory so that we can use react and react-dom. Replace the contents of this file with the following:

import ReactDOM from 'react-dom/client';

function App() {
  return <h1>Rick and Morty</h1>;
}

const container = document.getElementById('root');
const root = ReactDOM.createRoot(container);
root.render(<App />);

As you can see, this file imports the react and react-dom packages, defines a simple component that returns an h1 element containing the name of your application, and has this component rendered in the browser with react-dom. The last line of code mounts the App component to an element with the root ID selector in your document, which is the entry point of the application.

2. We can create a file that has this element in a new directory called public and name that file index.html. The document structure of this project should look like the following:

chapter-1
  |- node_modules
  |- package.json
  |- babel.config.json
  |- webpack.config.js
  |- dist
    |- main.js
  |- public
    |- index.html
  |- src
    |- index.js

3. After adding a new file called index.html to the new public directory, we add the following code inside it:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta
      name="viewport"
      content="width=device-width,
initial-scale=1.0"
    />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <title>Rick and Morty</title>
  </head>
  <body>
    <section id="root"></section>
  </body>
</html>

This adds an HTML heading and body. Within the head tag is the title of our application, and inside the body tag is a section with the "root" ID selector. This matches the element we have mounted the App component to in the src/index.js file.

4. The final step in rendering our React component is extending Webpack so that it adds the minified bundle code to the body tags as scripts when running. To do this, we should install the html-webpack-plugin package as a devDependency:

npm install --save-dev html-webpack-plugin

To use this new package to render our files with React, the Webpack configuration in the webpack.config.js file must be updated:

const HtmlWebpackPlugin = require('html-webpack-plugin');
module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
        },
      },
    ],
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: './public/index.html',
      filename: './index.html',
    }),
  ],
};

Now, if we run npm start again, Webpack will start in development mode and add the index.html file to the dist directory. Inside this file, we'll see that a new scripts tag has been inserted inside the body tag that points to our application bundle – that is, the dist/main.js file.

If we open this file in the browser or run open dist/index.html from the command line, it will display the result directly in the browser. The same is true when running the npm run build command to start Webpack in production mode; the only difference is that our code will be minified:.

This process can be sped up by setting up a development server with Webpack. We'll do this in the final part of this blog post.

Setting up a Webpack development server

While working in development mode, every time we make changes to the files in our application, we need to rerun the npm start command. This can be tedious, so we will install another package called webpack-dev-server. This package allows us to force Webpack to restart every time we make changes to our project files and manages our application files in memory instead of building the dist directory.

The webpack-dev-server package can be installed with npm:

npm install --save-dev webpack-dev-server

Also, we need to edit the dev script in the package.json file so that it uses webpack- dev-server instead of Webpack. This way, you don't have to recompile and reopen the bundle in the browser after every code change:

{
  "name": "chapter-1",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "webpack serve --mode=development",
    "build": "webpack --mode=production"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

The preceding configuration replaces Webpack in the start scripts with webpack-dev-server, which runs Webpack in development mode. This will create a local development server that runs the application and ensures that Webpack is restarted every time an update is made to any of your project files.

To start the local development server, just enter the following command in the terminal:

npm start

This will cause the local development server to be active at http://localhost:8080/ and refresh every time we make an update to any file in our project.

Now, we have created the basic development environment for our React application, which you can further develop and structure when you start building your application.

Conclusion

In this blog post, we learned how to set up a React project with Webpack and Babel. We also learned how to render a React component in the browser. I always like to learn a technology by building something with it from scratch before jumping into a framework like Next.js or Remix. This helps me understand the fundamentals of the technology and how it works.

This blog post is extracted from my book React Projects, available on Packt and Amazon.

I hope you learned some new things about React! Any feedback? Let me know by connecting to me on LinkedIn, X or Bluesky. Or leave a comment on my YouTube channel.

Click the image below to watch the YouTube video version of this blog post:

What is GraphQL?

If you haven't heard of GraphQL, it's a query language for APIs. It was created by Facebook in 2012 and open-sourced in 2015. GraphQL allows you to query data from an API in a structured way. It's a great alternative to REST, the most popular way to create APIs today.

I started using GraphQL in 2016 during a hackathon in Berlin and have been using it ever since. I'm using GraphQL in all my projects where I need access to an API, and I have been creating content about GraphQL for years. I've created a GraphQL book, Fullstack GraphQL, and multiple GraphQL tutorials on my YouTube channel.

Why do developers love GraphQL?

One single endpoint for all your data

One of the biggest advantages of GraphQL is that you only need one single endpoint to query all your data. In REST, you need multiple endpoints to query different data. Generally speaking, every data entity (like a database table) in REST API will have its own endpoint. For example, if you want to get a list of posts and a specific from a CMS API, you need to send requests to two endpoints:

• GET /posts (list of posts)
• GET /posts/1 (specific post)

In GraphQL, you can request both the list of posts and the specific post in one single query:

query {
  posts {
    id
    title
  }
  post(id: 1) {
    id
    title
  }
}

GraphQL would execute this query against a single endpoint, which is much easier to manage. You don't need to worry about creating multiple endpoints, and you don't need to worry about versioning them.

No more over- and under-fetching

In REST, you sometimes fetch more than the data you actually need, and this is called over-fetching. In the example from the previous section, you're fetching the list of posts from a REST API, and let's say we want to display them on an overview page. Therefore we need the id and title of each post, but this REST API is returning a lot more data than you need. Not only is it returning the id and title of the post, but also the body and userId. Getting more data than you need wastes bandwidth and processing power.

[
  {
    "id": 1,
    "userId": 1,
    "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
    "body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"
  },
  {
    "id": 2,
    "userId": 1,
    "title": "qui est esse",
    "body": "est rerum tempore vitae\nsequi sint nihil reprehenderit dolor beatae ea dolores neque\nfugiat blanditiis voluptate porro vel nihil molestiae ut reiciendis\nqui aperiam non debitis possimus qui neque nisi nulla"
  }
  // Other posts...
]

In GraphQL, you can request exactly the data you need by specifying the fields you want to get in your query:

query {
  posts {
    id
    title
  }
}

Opposite to over-fetching, there's also under-fetching. Sometimes need to make multiple requests to REST API endpoints to get all the data you need. This is called under-fetching because you're not getting all the data you need at once. Let's have another look at the example from the previous section. Instead of just getting a specific post on a detail page, we also want the comments for this post. In REST, you need to make two requests as a different endpoint than the post returns the comments:

• GET /posts/1 (specific post)
• GET /posts/1/comments (comments for specific post)

In GraphQL, you can request exactly the data you need even when the data is spread across multiple entities. You can request the post and the comments in one single query:

{
  post(id: 1) {
    id
    title
    comments {
      id
      name
    }
  }
}

This query would return the post and comments in one single response, which is much easier to manage in your application and takes fewer data to transfer. Especially as you prevent over-fetching in this example and only receive the data you're using on your detail page.

GraphQL is self-documenting

Well, at least partially...

In REST, you need to document your API. This is a lot of work, and it's easy to forget to update the documentation when you make changes to your API. In GraphQL, you don't need to document your API, as the documentation is generated automatically. You can use the GraphiQL tool to explore your GraphQL API and see all the available queries and mutations. You can also see the fields you can request for each query and mutation. This is much easier to manage than documenting your API manually.

GraphQL APIs have built-in documentation, which can be generated from its GraphQL schema. Every GraphQL API has a schema for defining all the operations and data types. The schema is used to validate the queries and mutations you send to the API. You can use the GraphiQL tool (read more in this blog post) to explore your GraphQL API and see all the available queries and mutations. You can also see the fields you can request for each query and mutation. But also to generate the documentation, making using a GraphQL API a lot easier to manage than having to document your REST API manually.

Conclusion

There are many reasons developers love GraphQL, especially frontend developers. GraphQL is easier to manage than REST and is much easier to use in your application. You can use GraphQL in your frontend application to fetch all the data you need in one single request. It prevents over- and under-fetching, plus it's self-documenting.

I'd love to hear your thoughts on this topic. Do you love GraphQL? Why? Let me know by connecting to me on LinkedIn, X or Bluesky. Or leave a comment on my YouTube channel.

But for many years, GraphiQL hasn't had a UI update. And it's been a while since it's been updated. But now since few months, GraphiQL 2 is here. It's a complete new version of GraphiQL with a new UI and a lot of new features. In this blog post, I'll explore the new features of GraphiQL 2 and show you how to use them.

Click the image below to watch the YouTube video version of this blog post:

Little bit of history

GraphiQL is a tool that was created to help developers explore GraphQL APIs, maintained by the GraphQL Foundation. But when GraphiQL became more and more popular, developers started to create additional GraphQL IDEs. A good example of this was GraphQL Playground, which quickly became the most popular GraphQL IDE. It was loosely based on GraphiQL, but had more features and a better UI.

After GraphQL Playground became part of the GraphQL Foundation, the need for having just one GraphQL IDE became more important. So the GraphQL Foundation decided to merge GraphiQL and GraphQL Playground into one tool. GraphiQL 1 relied on major tech debt and multiple dependencies that were outdated and hard to maintain. With the merge of GraphiQL and GraphQL Playground, the GraphQL Foundation decided to create a new version of GraphiQL, which is now called GraphiQL 2. The design and creation of GraphiQL 2 was all documented in Github.

First look at GraphiQL 2

For me personally, this is one of the biggest releases in GraphQL world this year. As for too many years we had to work with GraphiQL 1, which is looking like it's coming from the Stone Age. With GraphiQL 2, the theme behind GraphiQL has really outdone themselves as they've created a better version of GraphiQL that looks like it's actually from modern day.

As you can see in the above screenshot of GraphiQL 2, it looks way more modern than GraphiQL 1. It has a dark mode, a light mode, and a system mode. It has a new UI, and a lot of new features. Compared to GraphiQL 1, it's looks like a complete new version of GraphiQL with the same feel.

Let's look at the same page in GraphiQL 1:

This screenshot is from GraphiQL 1 and as you can see it just feels outdated, from the color scheme to the used font. As oppposed to GraphiQL 2 there's no way to change the theme from the UI itself.

Most features from GraphiQL 1 are also available in GraphiQL 2, such as the docs page, history, and the ability to pass variables and headers. But GraphiQL 2 has a lot of new features as well, which I'll explore in the next section.

New features in GraphiQL 2

I already mentioned GraphiQL 2 has a dark mode, which is a great addition and something most modern developer tools have today. OFcourse, you cna also switch to system mode, which will use the system theme so it changes to dark when sun sets.

But next to dark mode the biggest feature update is the tabs to switch between multiple queries. This is a great addition as it allows you to have multiple queries open at the same time. This is something I've been missing in GraphiQL 1 for a long time.

Having tabs is especially useful when you have a query to get a list of results and a query to get a specific item. You can now have both open at the same time and switch between them.

Conclusion

GraphiQL 2 is a great update to GraphiQL 1. It has a new UI, a lot of new features, and a dark mode. It's still the easiest tool to use for GraphQL developers to explore a GraphQL API. I'm really excited to see what the future of GraphiQL 2 will bring, especially as GraphiQL 2 is now maintained more activley than GraphiQL 1 used to be.

P.S. Follow Roy Derks on LinkedIn, X or Bluesky for more React, GraphQL and TypeScript tips & tricks. And subscribe to my YouTube channel for React, GraphQL and TypeScript tutorials.

Click the image below to watch the YouTube video version of this blog post:

By the end of this blog post, you will:

• Know how to set up a fresh application with Next.js
• Understand the core concepts of Next.js and TypeScript
• Be able to use TypeScript in your Next.js Project

Why combine Next.js and TypeScript?

Building robust, modern web applications can be easy. With Next.js, you'll leverage two of today's most popular technologies - Next.js and TypeScript - together without needing any complex configuration.

Next.js is a framework that allows you to build React applications quickly. It's a great choice for developers who want to get up and running soon with modern web applications without worrying about complex configurations. It's also an excellent choice for developers who wish to build performant and scalable applications, as Next.js has many features that help you make fast and efficient applications. For example, Next.js supports Server-side Rendering (SSR) and Static Site Generation (SSG), two of the most efficient ways to load data in a web application.

TypeScript, on the other hand, is a typed language that adds type safety and improved performance to your codebase.

Together, they form a powerful combination for building modern and performant web apps.

Getting Started with Next.js

Setting up a development environment with Next.js is straightforward.

You can create a new Next.js project from your terminal using the following command:

npx create-next-app my-app

Where my-app is the name of your project, Next.js will prompt you to choose a template, creating a new project for you. For the sake of this blog post, we will select the default template, a simple Next.js application with a single page. And NOT set up a TypeScript project.

Once the project is created, you can run the following command to start the development server:

npm run dev

And you should be seeing a small application that's available at http://localhost:3000.

Fix the "parsing error for using import"

When writing this blog post, I'm using Next.js version 13.0.5. And when I hover over any of the import statements at the top of a file, I get the following error:

Parsing error: Cannot find module 'next/babel'

This error shows because Next.js is using Babel to transpile the code, which somehow interferes with the Prettier plugin that my VSCode uses. To fix this, I need to change my .eslintrc.json file from:

{
  "extends": "next/core-web-vitals"
}

To this:

{
  "extends": ["next/core-web-vitals", "prettier"]
}

When you're done, you should be able to hover over the import statements without getting any errors.

Using TypeScript in your Next.js Project

Now that we have a basic Next.js application, we can start adding TypeScript to it. To do this, you don't have to install any additional packages, as Next.js has built-in support for TypeScript.

Convert all the files in your project from .js to .tsx, and you're good to go. For example, if you have a file called pages/index.js, you can rename it to pages/index.tsx.

And restart your development server. Next.js will install the dependencies needed to use TypeScript for your project and generate a tsconfig.json. This file includes all the required configurations to use Next.js together with TypeScript. You should now be able to use TypeScript features in your codebase.

Once you've done this, you can use TypeScript features in your codebase. For example, you can add types to your function parameters and use interfaces to define the shape of your data.

Conclusion

In this blog post, you learned how to set up a new application with Next.js, understand the core concepts of Next.js and TypeScript, and be able to use TypeScript in your Next.js Project.

If you're ready to take your web development skills to the next level and learn how to build powerful applications using Next.js and TypeScript, join me for my upcoming videos by subscribing to my YouTube channel.

> Subscribe to my YouTube channel

Or find me on LinkedIn, X or Bluesky. I'd love to hear from you!

Click the image below to watch the YouTube video version of this blog post:

Biggest Breaking Changes

Let's look at the most significant breaking changes in Apollo Server v4. Together with these breaking changes, a migration path from earlier versions of Apollo Server was also published in the documentation.

"We recommend that all users of Apollo Server upgrade to Apollo Server 4 as soon as possible. Apollo Server 2 and Apollo Server 3 are deprecated, with an end-of-life date of October 22nd, 2023." - Apollo Server v4 Migration Guide

New project structure

Apollo Server v4 is the latest version of Apollo Server and is replacing Apollo Server v2 and v3. As part of this update, they've bundled some packages in @apollo/server to replace the apollo-server package. Part of this is the apollo-server-express package, the most popular package for building GraphQL servers in Node.js, which is now integrated into the @apollo/server package.

Thus, if you want to use Apollo Server v4, you must follow the migration guide and update your code to use the new packages. As shown in the migration guide flowchart below:

This seems like a minor deal unless you're not using Express as your web framework. And an important note here is that Express GraphQL is being deprecated by the GraphQL Foundation. So if you're using Express for a GraphQL API, you should move away from it anyway.

Dropped support for other web frameworks

Now that Express is the default framework for running the GraphQL server, Apollo decided to remove support for all other web frameworks. This means Apollo is forcing developers to use Express to run their GraphQL servers. This is a big change as Apollo Server v2, and v3 allowed you to build on top of the apollo-server-* packages, such as apollo-server-fastify or apollo-server-koa. This is a huge change as it means you can no longer use Koa or Fastify to run your GraphQL servers unless someone builds a new package for it.

Until someone decides to build a new package for the web framework you use, you're stuck with Apollo Server v3, which is deprecated and will be end-of-life in October 2023.

Updated concept of dataSources

Apollo Server v4 has a new concept of dataSources. In Apollo Server v2 and v3 you could use the dataSources property to pass in an object with all of your data sources. This is no longer the case in Apollo Server v4. Instead, you will need to create a class that extends the DataSource class and then pass in an array of instances of this class to the dataSources property.

As a "side effect" of this change, Apollo deprecated the data source implementations created for SQL, MongoDB, and Firestore. Similar to the web framework plugins, you will need to make your own data source implementation for these data sources.

What else has changed?

Besides no longer supporting any other web framework than Express, there are a a lot of other breaking changes. Not all of them are bad, and the new Apollo Server v4 seems to be fixing a lot of tech debt the team has been building up over the years. For example, Apollo Server v4 has better TypeScript support than previous versions. And the deprecation of ApolloError in favor of GraphQLError from the graphql package is a good step forward to keep Apollo Server more in line with other libraries to build your GraphQL API.

Should I move away from Apollo Server?

It's entirely up to you. But from a Reddit post of the Apollo team it seems the next "backwards incompatible" release of Apollo Server will be Apollo Server v5, in spring 2023(!). To me, that just shows that Apollo Server is not a stable library to build your GraphQL API. And if you're building a GraphQL API for a company, you don't want to be stuck with a library that is not stable and will be deprecated every few years.

That said, if you are using Express you can easily upgrade to Apollo Server v4. Keeping in mind that express-graphql has been deprecated as well. If you're using Koa or Fastify, you can still use Apollo Server v3 until October 2023. You're out of luck if you're using any other web framework. You will either need to switch to Express, stay on Apollo Server v3 or wait for community support for the web framework you're using. In that case, consider moving away from Apollo Server.

When moving away from Apollo Server, and you're looking for a replacement built with JavaScript or TypeScript, let me give you some options. If you want to keep building your GraphQL API schema first, you might want to consider Mercurius (which relies on Fastify) or GraphQL Yoga. If you're going to build your GraphQL API code or resolver first, have a look at TypeGraphQL or Nexus. Alternatively, there are great GraphQL-as-a-Service solutions such as StepZen in case you no longer want to build, maintain and host your own GraphQL API.

You can learn more about the differences between schema-first, code/resolver-first, or using a GraphQL-as-a-Service in this recording of my talk at GraphQL Galaxy 2021.

Are you using Apollo Server? What are your thoughts on the breaking changes? Let me know on LinkedIn, X or Bluesky.

TLDR; GraphQL is a query language, and tRPC is a library.

As a developer working with GraphQL in the past years, this triggered me to compare the two and see what they are both excellent at (and what they are not).

Click the image below to watch the YouTube video version of this blog post:

But first; You might have been using GraphQL wrong

GraphQL is a query language for your API, and it's not a one-to-one replacement for REST. It's a way to query your API in a way that is more flexible than REST, giving you control over the response of the requests. In many of the Twitter conversations, I found that people were comparing GraphQL to REST, and that's different from what GraphQL is. Also, the GraphQL type system is not meant to be used for end-to-end type safety, at least not in a first way. But instead, as a way to document your API and ensure the runtime types of your API are correct.

Can we compare GraphQL to tRPC?

GraphQL is a query language for your API, while tRPC is a set of libraries for building end-to-end typesafe APIs. As mentioned earlier, this is like comparing apples to oranges. But let's break down both of them and learn about their characteristics.

GraphQL is a query language

GraphQL APIs typically use HTTP as a transport layer, and the GraphQL query is sent as a POST request to the API. The API then processes the query and returns the result as a JSON response. This is the same way that REST APIs work, but GraphQL is a query language, not a protocol. This means that you can use GraphQL over any transport layer and any protocol you want. This is also why you can use GraphQL in your frontend application because it's just a query language.

GraphQL itself is nothing more than a query language, and it's up to the GraphQL implementation libraries and frameworks to implement this query language according to its specification. This means that there are many different ways to implement GraphQL, and there are many different ways to use GraphQL. This is also why there are many different ways to use GraphQL in your front end application.

tRPC is a library

tRPC is a set of libraries that uses TypeScript to ensure type safety throughout the entire application. Its primary purpose is to make it easy to build end-to-end typesafe applications in a single codebase. The basis is a tRPC server in which you define the endpoints (or routes), the type definition for these endpoints, and handle any connection to a data source - like a database.

You can consume a tRPC API in your frontend application, using the tRPC client library. You're not directly sending an HTTP request to get your data, but let the tRPC client handle this for you, almost like an ORM for APIs. This client can make strongly typed API calls without relying on code generation. You can import TypeScript types from the server directly into your frontend application without generating any code.

What differentiates GraphQL and tRPC?

This is a very subjective question, but I think it's important to know what differentiates GraphQL and tRPC. This way, you can decide for yourself what you want to use in your application.

GraphQL is great for querying multiple data sources

GraphQL excels in combining multiple data sources into a single query. GraphQL is often used for data modeling and architecture, and it's great for this. For example, if you want to query data from one service (like a Headless CMS) and data from another (let's say a database), you can do this in a single query with GraphQL. You can even combine this data on field or type level. It is one of the major reasons companies like Facebook and GitHub are using GraphQL.

Tweets from Jamie Barton and Taz Singh.

Whereas tRPC is not really meant for this. It's meant for building end-to-end typesafe APIs, and it's not really meant for combining multiple data sources. You can do this, but it's not the purpose of tRPC.

tRPC is great for end-to-end type safety

tRPC is great for end-to-end type safety, and it allows you to use the same types in your frontend application as you use in your backend application. GraphQL has no built-in way to share type definitions between a frontend and backend, but you can use the GraphQL schema to generate TypeScript type definitions. But this is different from end-to-end type safety. Every time you update your GraphQL schema, you have to regenerate the types.

When using tRPC, you're building everything using TypeScript. This means that you can import the types from the server directly into your frontend application. The tRPC client can access the TypeScript types from your tRPC server directly. You don't need external libraries when querying tRPC in your frontend application because it's all built-in the tRPC libraries.

GraphQL allows for decoupled services; tRPC for a single codebase

GraphQL is great for decoupled services as it's programming language and transport layer agnostic. This means that you can use any programming language and any transport layer you want. Services that expose a GraphQL API can be implemented in any programming language, for example TypeScript and Go, and still be able to communicate with each other. For teams and companies that are technologicallyy diverse this is a great way to scale and limit the amount of dependencies between teams.

tRPC is not really meant for this. It's meant for building end-to-end typesafe APIs in a single codebase, in TypeScript! It brings your frontend and backend closely together, for example in a monorepo. You can use the same types in your frontend and backend application, which allows you to rapidly iterate on your application. What's not to love if you're building a fullstack TypeScript project?

tRPC is easier to use than GraphQL

"tRPC is easier to use than GraphQL" is a recurring statement people make when comparing GraphQL and tRPC. But as tRPC is a library and GraphQL is a query language, it's impossible to compare. For GraphQL, it's up to the developer to build a GraphQL using one of the many available implementations, while tRPC is a set of libraries you can use out of the box. This makes it not a fair comparison, but let's break it down anyway.

For example, you could build a GraphQL API using a schema-first GraphQL server library. You have to define a GraphQL schema, write the resolvers to collect the data from a data source, and then generate the types from the schema. Going this path is a lot of work and comes with many choices you need to make as a developer.

But you can also build a GraphQL API using a code-first GraphQL server library. This means you can write the resolvers and then generate the schema from the resolvers. Code-first libraries are much closer to tRPC in terms of Developer Experience but still more challenging than using a GraphQL-as-a-service like StepZen.

Then you also have a wide choice of various GraphQL client libraries. You can use GraphQL client library like Apollo Client or urql that helps you with caching and state management, or use a library that only handles the HTTP requests. There are many choices, which could be unclear when you're new to GraphQL.

Conclusion

In this blog post, I explained the differences between GraphQL and tRPC. I hope this blog post helped you understand the differences between the two and that you can now make a better decision on which one to use for your next project. The main questions to ask yourself when choosing between GraphQL and tRPC are:

• Do you want to query multiple data sources in a single query and keep your services decoupled? If so, GraphQL is a perfect choice. If you want end-to-end type safety and don't care about decoupling your frontend and backend, tRPC is a better fit.
• Are you planning to work with multiple programming languages? Go for GraphQL, as it's programming language agnostic. If you want to use TypeScript throughout your entire application, tRPC might be a better fit.

There are many other things to consider when choosing between GraphQL and tRPC, but these are the main ones in my opinion. I'd love to hear your thoughts on this, so please let me know via LinkedIn, X or Bluesky.

Click the image below to watch the YouTube video version of this blog post:

Installing Create React App

Today, Create React App is the most popular way to create a React project. It's a tool that allows you to create a React project without having to worry about the configuration. It's a great way to get started with React and TypeScript. You can create a new project with Create React App using npx with the following command:

npx create-react-app my-app

This will create a new React project in the my-app directory. Now that your React project is set up, it's time to run the application. You can then run the project with the following command:

cd my-app
npm start

This will start the development server and open the application in your browser in http://localhost:3000. You can now start developing your React TypeScript project!

Note: npx is installed on your machine when you install Node.js.

Installing TypeScript

To use TypeScript in your Create React App project, you need to add a tsconfig.json file that holds the TypeScrupt configuration. You can do this by running the following command:

touch tsconfig.json

And add this configuration to the tsconfig.json file:

{
  "compilerOptions": {
    "outDir": "dist",
    "rootDir": "src",
    "sourceMap": true,
    "noImplicitAny": true,
    "allowJs": true,
    "moduleResolution": "node",
    "module": "commonJS",
    "lib": ["es6", "dom"],
    "target": "ES5",
    "jsx": "react"
  },
  "exclude": ["node_modules", "dist"]
}

To use TypeScript in your project, you only need to restart the development server by running npm start again. This will now compile your TypeScript code to JavaScript and run the application.

Every file in your application can be renamed from js to tsx to use TypeScript. You can also add the ts extension to your files, but it's needed to use tsx for React components as these files contain JSX.

You can now start developing your React TypeScript project!

Allowing synthetic default imports

In your IDE you might see some errors highlighted about synthetic default imports. This is because TypeScript doesn't know how to import the default export from a module. By default, imports in TypeScript have the following syntax:

import * as React from 'React';

If we want to keep importing our modules as we did with Babel, we need to change some settings in our tsconfig.json file:

{
  "compilerOptions": {
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    ...
  }
}

After this, we can deconstruct our imports again and avoid the obligatory asterisk *:

import React, { FC } from 'react';

This will allow us to import our modules as we did before. But there are more things we should do to make our TypeScript project more robust.

Adding global type definitions

Another highlighted error in your IDE (I'm using VS code) is that it cannot find the type definitions for the SVG files we're importing.

Cannot find module './logo.svg' or its corresponding type declarations.

To fix this, we need to add this type definition to our project. We can do this by creating a global.d.ts file in the src directory and adding the following code:

declare module '*.svg' {
  const content: string;
  export default content;
}

This will allow us to import SVG files in our project without any errors.

Creating a TypeScript React component

Now that we've set up our project, it's time to create our first TypeScript React component. We can do this by creating a components/Link.tsx file in the src directory and adding the following code:

import * as React from 'react';

type LinkProps = {
  href: string;
  targetBlank: boolean;
  children: React.ReactNode | string;
};

export default function Link({
  href,
  targetBlank = false,
  children,
}: LinkProps) {
  return (
    <a
      className='App-link'
      href={href}
      target={targetBlank ? '_blank' : ''}
      rel={targetBlank ? 'noopener noreferrer' : ''}
    >
      {children}
    </a>
  );
}

This will create a simple Link component that we can use in our application. We can now import this component in our App.tsx file and use it in our application.

For example, we can replace the a tag in the App.tsx file with our Link component:

import * as React from 'react';
import logo from './logo.svg';
import './App.css';
import Link from './components/Link';

function App() {
  return (
    <div className='App'>
      <header className='App-header'>
        <img src={logo} className='App-logo' alt='logo' />
        <p>
          Edit <code>src/App.js</code> and save to reload.
        </p>
        <Link href='https://reactjs.org' targetBlank>
          Learn React
        </Link>
      </header>
    </div>
  );
}

export default App;

This will now render the Link component in our application. You can now start developing your React TypeScript project by adding more components!

Conclusion

By the end of this blog post, you should have all the information you need to get started on React TypeScript development. We've discussed how to set up an environment, create a project structure and run the application. And that’s it! With this comprehensive guide in hand, you now have all the information you need to set up and run your React TypeScript project from scratch. I hope this guide was helpful and wish you luck on your React TypeScript journey!

Good luck and happy coding!

P.S. Follow Roy Derks on LinkedIn, X or Bluesky for more React, GraphQL and TypeScript tips & tricks. And subscribe to my YouTube channel for more React, GraphQL and TypeScript tutorials.