DEV Community: Yohan Lasorsa

Host Your Node.js MCP Server on Azure Functions in 1 Simple Step

Yohan Lasorsa — Tue, 09 Dec 2025 15:44:53 +0000

Building AI agents with the Model Context Protocol (MCP) is powerful, but when it comes to hosting your MCP server in production, you need a solution that's reliable, scalable, and cost-effective. What if you could deploy your regular Node.js MCP server to a serverless platform that handles scaling automatically while you only pay for what you use?

Let's explore how Azure Functions now supports hosting MCP servers built with the official Anthropic MCP SDK, giving you serverless scaling with almost no changes in your code.

Grab your favorite hot beverage, and let's dive in!

TL;DR key takeaways

Azure Functions now supports hosting Node.js MCP servers using the official Anthropic SDK
Only 1 simple configuration needed: adding host.json file
Currently supports HTTP Streaming protocol with stateless servers
Serverless hosting means automatic scaling and pay-per-use pricing
Deploy with one command using Infrastructure as Code

What will you learn here?

Understand how MCP servers work on Azure Functions
Configure a Node.js MCP server for Azure Functions hosting
Test your MCP server locally and with real AI agents
Deploy your MCP server with Infrastructure as Code and AZD

Reference links for everything we use

Model Context Protocol - Official MCP documentation
Azure Functions - Serverless compute platform
Anthropic MCP SDK - Official TypeScript SDK
Azure Developer CLI - One-command deployment tool
Full sample project - Complete burger ordering system with MCP
Simple example - Minimal MCP server starter
GitHub Copilot prompt helper - Automated setup by Anthony Chu

Requirements

Node.js 22 or higher
Azure account (free signup, or if you're a student, get free credits here)
Azure Developer CLI (for deployment)
GitHub account (optional, for using Codespaces)

What is MCP and why does it matter?

Model Context Protocol is an open standard that enables AI models to securely interact with external tools and data sources. Instead of hardcoding tool integrations, you build an MCP server that exposes capabilities (like browsing a menu, placing orders, or querying a database) as tools that any MCP-compatible AI agent can discover and use. MCP is model-agnostic, meaning it can work with any LLM that supports the protocol, including models from Anthropic, OpenAI, and others. It's also worth noting that MCP supports more than just tool calls, though that's its most common use case.

The challenge? Running MCP servers in production requires infrastructure. You need to handle scaling, monitoring, and costs. That's where Azure Functions comes in.

🚨 Free course alert! If you're new to MCP, check out the MCP for Beginners course to get up to speed quickly.

Why Azure Functions for MCP servers?

Azure Functions is a serverless compute platform that's perfect for MCP servers:

Zero infrastructure management: No servers to maintain
Automatic scaling: Handles traffic spikes seamlessly
Cost-effective: Pay only for actual execution time (with generous free grant)
Built-in monitoring: Application Insights integration out of the box
Global distribution: Deploy to regions worldwide

The new Azure Functions support means you can take your existing Node.js MCP server and deploy it to a production-ready serverless environment with minimal changes. This comes up as an additional option for native Node.js MCP hosting, but you can still use the Azure Functions MCP bindings that were available before.

1 simple step to enable Functions hosting

Let's break down what you need to add to your existing Node.js MCP server to run it on Azure Functions. I'll use a real-world example from our burger ordering system.

If you already have a working Node.js MCP server, you can just follow this to make it compatible with Azure Functions hosting.

Step 1: Add the `host.json` configuration

Create a host.json file at the root of your Node.js project:

{
  "version": "2.0",
  "configurationProfile": "mcp-custom-handler",
  "customHandler": {
    "description": {
      "defaultExecutablePath": "node",
      "arguments": ["lib/server.js"]
    },
    "http": {
      "DefaultAuthorizationLevel": "anonymous"
    },
    "port": "3000"
  }
}

Note: Adjust the arguments array to point to your compiled server file (e.g., lib/server.js or dist/server.js), depending on your build setup. You can also change the port if needed to match your server configuration.

The hosts.json file holds metadata configuration for the Functions runtime. The most important part here is the customHandler section. It configures the Azure Functions runtime to run your Node.js MCP server as a custom handler, which allows you to use any HTTP server framework (like Express, Fastify, etc.) without modification (tip: it can do more than MCP servers! 😉).

There's no step 2 or 3. That's it! 😎

Note: We're not covering the authentication and authorization aspects of Azure Functions here, but you can easily add those later if needed.

Real-world example: Burger MCP Server

Let's look at how this works in practice with a burger ordering MCP server. This server exposes 9 tools for AI agents to interact with a burger API:

get_burgers - Browse the menu
get_burger_by_id - Get burger details
place_order - Place an order
get_orders - View order history
And more...

Here's the complete server implementation using Express and the MCP SDK:

import express, { Request, Response } from 'express';
import { StreamableHTTPServerTransport } from '@modelcontextprotocol/sdk/server/streamableHttp.js';
import { getMcpServer } from './mcp.js';

const app = express();
app.use(express.json());

// Handle all MCP Streamable HTTP requests
app.all('/mcp', async (request: Request, response: Response) => {
  const transport = new StreamableHTTPServerTransport({
    sessionIdGenerator: undefined,
  });

  // Connect the transport to the MCP server
  const server = getMcpServer();
  await server.connect(transport);

  // Handle the request with the transport
  await transport.handleRequest(request, response, request.body);

  // Clean up when the response is closed
  response.on('close', async () => {
    await transport.close();
    await server.close();
  });

  // Note: error handling not shown for brevity
});

// The port configuration
const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Burger MCP server listening on port ${PORT}`);
});

The MCP tools are defined using the official SDK:

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

export function getMcpServer() {
  const server = new McpServer({
    name: 'burger-mcp',
    version: '1.0.0',
  });

  server.registerTool(
    'get_burgers',
    { description: 'Get a list of all burgers in the menu' },
    async () => {
      const response = await fetch(`${burgerApiUrl}/burgers`);
      const burgers = await response.json();
      return {
        content: [{
          type: 'text',
          text: JSON.stringify(burgers, null, 2)
        }]
      };
    }
  );

  // ... more tools
  return server;
}

As you can see, the actual implementation of the tool is forwarding an HTTP request to the burger API and returning the result in the MCP response format. This is a common pattern for MCP tools in enterprise contexts, that act as wrappers around one or more existing APIs.

Current limitations

Note that this Azure Functions MCP hosting currently has some limitations: it only supports stateless servers using the HTTP Streaming protocol. The legacy SSE protocol is not supported as it requires stateful connections, so you'll either have to migrate your client to use HTTP Streaming or use another hosting option, like using containers for example.

For most use cases, HTTP Streaming is the recommended approach anyway as it's more scalable and doesn't require persistent connections. Stateful MCP servers comes with additional complexity challenges and have limited scalability if you need to handle many concurrent connections.

Testing the MCP server locally

First let's run the MCP server locally and play a bit with it.

If you don't want to bother with setting up a local environment, you can use the following link or open it in a new tab to launch a GitHub Codespace:

Create Codespace

This will open a VS Code environment in your browser with the repo already cloned and all the tools installed and ready to go. Otherwise you can just clone the repo.

Once you have the code ready, open a terminal and run:

# Install dependencies
npm install

# Start the burger MCP server and API
npm start

This will start multiple services locally, including the Burger API and the MCP server, which will be available at http://localhost:3000/mcp. This may take a few seconds, wait until you see this message in the terminal:

🚀 All services ready 🚀

We're only interested in the MCP server for now, so let's focus on that.

Using MCP Inspector

The easiest way to test the MCP server is with the MCP Inspector tool:

$ npx -y @modelcontextprotocol/inspector

Open the URL shown in the console in your browser, then:

Set transport type to Streamable HTTP
Enter your local server URL: http://localhost:3000/mcp
Click Connect

After you're connected, go to the Tools tab to list available tools. You can then try the get_burgers tool to see the burger menu.

Using GitHub Copilot (with remote MCP)

Configure GitHub Copilot to use your deployed MCP server by adding this to your project's .vscode/mcp.json:

{
  "servers": {
    "burger-mcp": {
      "type": "http",
      "url": "http://localhost:3000/mcp"
    }
  }
}

Click on "Start" button that will appear in the JSON file to activate the MCP server connection.

Now you can use Copilot in agent mode and ask things like:

"What spicy burgers do you have?"
"Place an order for two cheeseburgers"
"Show my recent orders"

Copilot will automatically discover and use the MCP tools! 🎉

Tip: If Copilot doesn't call the burger MCP tools, try checking if it's enabled by clicking on the tool icon in the chat input box and ensuring that "burger-mcp" is selected. You can also force tool usage by adding #burger-mcp in your prompt.

(Bonus) Deploying to Azure with Infrastructure as Code

Deploying an application to Azure is usually not the fun part, especially when it involves multiple resources and configurations.
With the Azure Developer CLI (AZD), you can define your entire application infrastructure and deployment process as code, and deploy everything with a single command.

If you've used the automated setup with GitHub Copilot, you should already have the necessary files. Our burger example also comes with these files pre-configured. The MCP server is defined as a service in azure.yaml, and the files under the infra folder defines the Azure Functions app and related resources.

Here's the relevant part of azure.yaml that defines the burger MCP service:

name: mcp-agent-langchainjs

services:
  burger-mcp:
    project: ./packages/burger-mcp
    language: ts
    host: function

While the infrastructure files can look intimidating at first, you don't need to understand all the details to get started. There are tons of templates and examples available to help you get going quickly, the important part is that everything is defined as code, so you can version control it and reuse it.

Now let's deploy:

# Login to Azure
azd auth login

# Provision resources and deploy
azd up

Pick your preferred Azure region when prompted (if you're not sure, choose East US2), and voilà! In a few minutes, you'll have a fully deployed MCP server running on Azure Functions.

Once the deployment is finished, the CLI will show you the URL of the deployed resources, including the MCP server endpoint.

Example projects

The burger MCP server is actually part of a larger example project that demonstrates building an AI agent with LangChain.js, that uses the burger MCP server to place orders. If you're interested in the next steps of building an AI agent on top of MCP, this is a great resource as it includes:

AI agent web API using LangChain.js
Web app interface built with Lit web components
MCP server on Functions (the one we just saw)
Burger ordering API (used by the MCP server)
Live order visualization
Complete Infrastructure as Code, to deploy everything with one command

But if you're only interested in the MCP server part, then you might want to look at this simpler example that you can use as a starting point for your own MCP servers: mcp-sdk-functions-hosting-node is a server template for a Node.js MCP server using TypeScript and MCP SDK.

What about the cost?

Azure Functions Flex Consumption pricing is attractive for MCP servers:

Free grant: 1 million requests and 400,000 GB-s execution time per month
After free grant: Pay only for actual execution time
Automatic scaling: From zero to hundreds of instances

The free grant is generous enough to allow running a typical MCP server with moderate usage, and all the experimentation you might need. It's easy to configure the scaling limits to control costs as needed, with an option to scale down to zero when idle. This flexibility is why Functions is my personal go-to choice for TypeScript projects on Azure.

Wrap up

Hosting MCP servers on Azure Functions gives you the best of both worlds: the simplicity of serverless infrastructure and the power of the official Anthropic SDK. With just one simple configuration step, you can take your existing Node.js MCP server and deploy it to a production-ready, auto-scaling platform.

The combination of MCP's standardized protocol and Azure's serverless platform means you can focus on building amazing AI experiences instead of managing infrastructure. Boom. 😎

Star the repos ⭐️ if you found this helpful! Try deploying your own MCP server and share your experience in the comments. If you run into any issues or have questions, you can reach for help on the Azure AI community on Discord.

Serverless MCP Agent with LangChain.js v1 — Burgers, Tools, and Traces 🍔

Yohan Lasorsa — Tue, 21 Oct 2025 16:09:46 +0000

AI agents that can actually do stuff (not just chat) are the fun part nowadays, but wiring them cleanly into real APIs, keeping things observable, and shipping them to the cloud can get... messy. So we built a fresh end‑to‑end sample to show how to do it right with the brand new LangChain.js v1 and Model Context Protocol (MCP). In case you missed it, MCP is a recent open standard that makes it easy for LLM agents to consume tools and APIs, and LangChain.js, a great framework for building GenAI apps and agents, has first-class support for it.

This new sample gives you:

A LangChain.js v1 agent that streams its result, along reasoning + tool steps
An MCP server exposing real tools (burger menu + ordering) from a business API
A web interface with authentication, sessions history, and a debug panel (for developers)
A production-ready multi-service architecture
Serverless deployment on Azure in one command (azd up)

Yes, it’s a burger ordering system. Who doesn't like burgers? Grab your favorite beverage ☕, and let’s dive in for a quick tour!

TL;DR key takeaways

New sample: full-stack Node.js AI agent using LangChain.js v1 + MCP tools
Architecture: web app → agent API → MCP server → burger API
Runs locally with a single npm start, deploys with azd up
Uses streaming (NDJSON) with intermediate tool + LLM steps surfaced to the UI
Ready to fork, extend, and plug into your own domain / tools

What will you learn here?

What this sample is about and its high-level architecture
What LangChain.js v1 brings to the table for agents
How to deploy and run the sample
How MCP tools can expose real-world APIs

Reference links for everything we use

Use case

You want an AI assistant that can take a natural language request like “Order two spicy burgers and show me my pending orders” and:

Understand intent (query menu, then place order)
Call the right MCP tools in sequence, calling in turn the necessary APIs
Stream progress (LLM tokens + tool steps)
Return a clean final answer

Swap “burgers” for “inventory”, “bookings”, “support tickets”, or “IoT devices” and you’ve got a reusable pattern!

Sample overview

Before we play a bit with the sample, let's have a look at the main services implemented here:

Service	Role	Tech
Agent Web App (`agent-webapp`)	Chat UI + streaming + session history	Azure Static Web Apps, Lit web components
Agent API (`agent-api`)	LangChain.js v1 agent orchestration + auth + history	Azure Functions, Node.js
Burger MCP Server (`burger-mcp`)	Exposes burger API as tools over MCP (Streamable HTTP + SSE)	Azure Functions, Express, MCP SDK
Burger API (`burger-api`)	Business logic: burgers, toppings, orders lifecycle	Azure Functions, Cosmos DB

Here's a simplified view of how they interact:

There are also other supporting components like databases and storage not shown here for clarity.

For this quickstart we'll only interact with the Agent Web App and the Burger MCP Server, as they are the main stars of the show here.

LangChain.js v1 agent features

The recent release of LangChain.js v1 is a huge milestone for the JavaScript AI community! It marks a significant shift from experimental tools to a production-ready framework. The new version doubles down on what’s needed to build robust AI applications, with a strong focus on agents. This includes first-class support for streaming not just the final output, but also intermediate steps like tool calls and agent reasoning. This makes building transparent and interactive agent experiences (like the one in this sample) much more straightforward.

Quickstart

Requirements

GitHub account
Azure account (free signup, or if you're a student, get free credits here)
Azure Developer CLI

Deploy and run the sample

We'll use GitHub Codespaces for a quick zero-install setup here, but if you prefer to run it locally, check the README.

Click on the following link or open it in a new tab to launch a Codespace:

Create Codespace

This will open a VS Code environment in your browser with the repo already cloned and all the tools installed and ready to go.

Provision and deploy to Azure

Open a terminal and run these commands:

# Install dependencies
npm install

# Login to Azure
azd auth login

# Provision and deploy all resources
azd up

Follow the prompts to select your Azure subscription and region. If you're unsure of which one to pick, choose East US 2.
The deployment will take about 15 minutes the first time, to create all the necessary resources (Functions, Static Web Apps, Cosmos DB, AI Models).

If you're curious about what happens under the hood, you can take a look at the main.bicep file in the infra folder, which defines the infrastructure as code for this sample.

Test the MCP server

While the deployment is running, you can run the MCP server and API locally (even in Codespaces) to see how it works. Open another terminal and run:

npm start

This will start all services locally, including the Burger API and the MCP server, which will be available at http://localhost:3000/mcp. This may take a few seconds, wait until you see this message in the terminal:

🚀 All services ready 🚀

When these services are running without Azure resources provisioned, they will use in-memory data instead of Cosmos DB so you can experiment freely with the API and MCP server, though the agent won't be functional as it requires a LLM resource.

MCP tools

The MCP server exposes the following tools, which the agent can use to interact with the burger ordering system:

Tool Name	Description
`get_burgers`	Get a list of all burgers in the menu
`get_burger_by_id`	Get a specific burger by its ID
`get_toppings`	Get a list of all toppings in the menu
`get_topping_by_id`	Get a specific topping by its ID
`get_topping_categories`	Get a list of all topping categories
`get_orders`	Get a list of all orders in the system
`get_order_by_id`	Get a specific order by its ID
`place_order`	Place a new order with burgers (requires `userId`, optional `nickname`)
`delete_order_by_id`	Cancel an order if it has not yet been started (status must be `pending`, requires `userId`)

You can test these tools using the MCP Inspector. Open another terminal and run:

npx -y @modelcontextprotocol/inspector

Then open the URL printed in the terminal in your browser and connect using these settings:

Transport: Streamable HTTP
URL: http://localhost:3000/mcp
Connection Type: Via Proxy (should be default)

Click on Connect, then try listing the tools first, and run get_burgers tool to get the menu info.

Test the Agent Web App

After the deployment is completed, you can run the command npm run env to print the URLs of the deployed services. Open the Agent Web App URL in your browser (it should look like https://<your-web-app>.azurestaticapps.net).

You'll first be greeted by an authentication page, you can sign in either with your GitHub or Microsoft account and then you should be able to access the chat interface.

From there, you can start asking any question or use one of the suggested prompts, for example try asking: Recommend me an extra spicy burger.

As the agent processes your request, you'll see the response streaming in real-time, along with the intermediate steps and tool calls. Once the response is complete, you can also unfold the debug panel to see the full reasoning chain and the tools that were invoked:

Tip: Our agent service also sends detailed tracing data using OpenTelemetry. You can explore these either in Azure Monitor for the deployed service, or locally using an OpenTelemetry collector. We'll cover this in more detail in a future post.

Wrap it up

Congratulations, you just finished spinning up a full-stack serverless AI agent using LangChain.js v1, MCP tools, and Azure’s serverless platform. Now it's your turn to dive in the code and extend it for your use cases! 😎 And don't forget to azd down once you're done to avoid any unwanted costs.

Going further

This was just a quick introduction to this sample, and you can expect more in-depth posts and tutorials soon.

Since we're in the era of AI agents, we've also made sure that this sample can be explored and extended easily with code agents like GitHub Copilot.
We even built a custom chat mode to help you discover and understand the codebase faster! Check out the Copilot setup guide in the repo to get started.

If you like this sample, don't forget to star the repo ⭐️! You can also join us in the Azure AI community Discord to chat and ask any questions.

Happy coding and burger ordering! 🍔

Using DeepSeek-R1 on Azure with JavaScript

Yohan Lasorsa — Thu, 13 Feb 2025 13:20:00 +0000

Using DeepSeek-R1 on Azure with JavaScript

The pace at which innovative AI models are being developed is outstanding! DeepSeek-R1 is one such model that focuses on complex reasoning tasks, providing a powerful tool for developers to build intelligent applications.

We recently announced its availability on GitHub Models
as well as on Azure AI Foundry. In this article, we’ll take a look at how you can deploy and use the DeepSeek-R1 models in your JavaScript applications.

TL;DR key takeaways

DeepSeek-R1 models focus on complex reasoning tasks, and is not designed for general conversation
You can quickly switch your configuration to use Azure AI, GitHub Models, or even local models with Ollama.
You can use OpenAI Node SDK or LangChain.js to interact with DeepSeek models.

What you'll learn here

Deploying DeepSeek-R1 model on Azure.
Switching between Azure, GitHub Models, or local (Ollama) usage.
Code patterns to start using DeepSeek-R1 with various libraries in TypeScript.

Reference links

Requirements

GitHub account. If you don't have one, you can create a free GitHub account. You can optionally use GitHub Copilot Free to help you write code and ship your application even faster.
Azure account. If you're new to Azure, get an Azure account for free to get free Azure credits to get started. If you're a student, you can also get free credits with Azure for Students.

Getting started

We'll use GitHub Codespaces to get started quickly, as it provides a preconfigured Node.js environment for you. Alternatively, you can set up a local environment using the instructions found in the GitHub repository.

Click on the button below to open our sample repository in a web-based VS Code, directly in your browser:

Once the project is open, wait a bit to ensure everything has loaded correctly. Open a terminal and run the following command to install the dependencies:

npm install

Running the samples

The repository contains several TypeScript files under the samples directory that demonstrate how to interact with DeepSeek-R1 models. You can run a sample using the following command:

npx tsx samples/<sample>.ts

For example, let's start with the first one:

npx tsx samples/01-chat.ts

Wait a bit, and you should see the response from the model in your terminal.
You'll notice that it may take longer than usual to respond, and see a weird response that starts with a <think> tag. This is because DeepSeek-R1 is designed to be used for task that need complex reasoning, like solving problems or answering math questions, and not for you usual chat interactions.

Model configuration

By default, the repository is configured to use GitHub Models, so you can run any example using Codespaces without any additional setup. While it's great for quick experimentation, GitHub models limit the number of requests you can make in a day and the amount of data you can send in a single request. If you want to use the model more extensively, you can switch to Azure AI or even use a local model with Ollama. You can take a look at the samples/config.ts to see how the different configurations are set up.

We'll not cover using Ollama models in this article, but you can find more information in the repository documentation.

Deploying DeepSeek-R1 on Azure

To experiment with the full capabilities of DeepSeek-R1, you can deploy it on Azure AI Foundry. Azure AI Foundry is a platform that allows you to deploy, manage and develop with AI models quickly. To use Azure AI Foundry, you need to have an Azure account.

Let's start by deploying the model on Azure AI Foundry. First, follow this tutorial to deploy a serverless endpoint with the model. When it's time to choose the model, make sure to select the DeepSeek-R1 model in the catalog.

Once your endpoint is deployed, you should be able to see your endpoint details and retrieve the URL and API key:

Then create a .env file in the root of the project and add the following content:

AZURE_AI_BASE_URL="https://<your-deployment-name>.<region>.models.ai.azure.com/v1"
AZURE_AI_API_KEY="<your-api-key>"

Tip: if you're copying the endpoint from the Azure AI Foundry portal, make sure to add the /v1 at the end of the URL.

Open the samples/config.ts file and update the default export to use Azure:

export default AZURE_AI_CONFIG;

Now all samples will use the Azure configuration.

Explore reasoning with DeepSeek-R1

Now that you have the model deployed, you can start experimenting with it. Open the samples/08-reasoning.ts file to see how the model handles more complex tasks, like helping us understand a well-known weird piece of code.

const prompt = `
float fast_inv_sqrt(float number) {
  long i;
  float x2, y;
  const float threehalfs = 1.5F;

  x2 = number * 0.5F;
  y  = number;
  i  = *(long*)&y;
  i  = 0x5f3759df - ( i >> 1 );
  y  = *(float*)&i;
  y  = y * ( threehalfs - ( x2 * y * y ) );

  return y;
}

What is this code doing? Explain me the magic behind it.
`;

Now run this sample with the command:

npx tsx samples/08-reasoning.ts

You should see the model's response streaming piece by piece in the terminal, while describing its thought process before providing the actual answer to our question.

Brace yourself, as it might take a while to get the full response! At the end of the process, you should see the model's detailed explanation of the code, along with some context around it.

Leveraging frameworks

Most examples in this repository are built with the OpenAI Node SDK, but you can also use LangChain.js to interact with the model. This might be especially interested if you need to integrate other sources of data or want to build a more complex application.

Open the file samples/07-langchain.ts to have a look at the setup, and see how you can reuse the same configuration we used with the OpenAI SDK.

Going further

Now it's your turn to experiment and discover the full potential of DeepSeek-R1! You can try more advanced prompts, integrate it into your larger application, or even build agents to make the most out of the model.

To continue your learning journey, you can check out the following resources:

DeepSeek-R1 JavaScript starter (GitHub): a complete starter project including to use DeepSeek-R1 models in JavaScript, including infrastructure as code for secure deployment on Azure.
Generative AI with JavaScript (GitHub): code samples and resources to learn Generative AI with JavaScript.
Build a serverless AI chat with RAG using LangChain.js (GitHub): a next step code example to build an AI chatbot using Retrieval-Augmented Generation and LangChain.js.

Generative AI with JavaScript FREE course

Yohan Lasorsa — Wed, 16 Oct 2024 08:58:50 +0000

Generative AI has come a long way in just two years, revolutionizing industries and unlocking new possibilities for developers across the globe. What initially started as a niche field primarily dominated by research and Python-based machine learning has quickly become a mainstream technology that’s reshaping how we approach creativity, automation, and interaction. But what’s even more exciting is how accessible this technology has become for developers from all backgrounds—especially JavaScript developers! 🎉

Today, generative AI isn’t just about building complex models in Python. The real magic happens when these models are integrated into applications that users interact with every day, and that’s where JavaScript comes in. As the web’s most widely used programming language, JavaScript plays a pivotal role in how developers build and scale generative AI-powered apps for the browser, mobile, and even server-side environments.

Introducing Generative AI with JavaScript

We built our new content series, Generative AI with JavaScript, to help you harness this power. Whether you’re a web developer curious about AI or an experienced coder looking to leverage generative AI in your projects, this series will walk you through everything you need to know: from connecting to APIs and working with large language models (LLMs), to building sophisticated, AI-driven applications using popular tools like LangChain.js and Azure.

You can access the full series for free on our YouTube playlist, where you’ll find videos around 10 minutes long, each focusing on a specific topic.

📺 Generative AI with JavaScript

We've made each video self-contained, so you can watch them in any order that suits your learning style, though we chose and ordered them to provide a smooth learning curve if you're new to generative AI.

Learn, share & teach

The videos are only one part of the learning experience! 😉

We tried to pair each topic with interactive demos, code samples, and additional resources to help you dive deeper into the subject. You can find all these resources in the video descriptions but we also gathered everything in a dedicated GitHub repository: https://github.com/microsoft/generative-ai-with-javascript

In this repo, you'll find:

📚 Links to all the videos in the series
📄 Slides and transcripts for all sessions, to use as foundation for your own talks
📦 Demo and code samples to get hands-on experience
🚀 Project examples and starter kits to help you get use Gen AI in your projects
🌟 Additional resources to learn more about generative AI

We wanted to make sure you have everything you need to learn the concepts, share your knowledge with others, and even teach your own workshops or courses. Feel free to reuse any of the content in your own presentations, blog posts, or videos!

Want more?

What if I tell you this is just the beginning? 😏

We have plently more content coming, this is just the first part of the series. We have more advanced topics, in-depth tutorials and even more use cases and tools to help you master generative AI with JavaScript. Stay tuned for more updates and new videos!

If you want to keep the new content coming, don't forget to star the repo, like the videos, subscribe to the channel, yada yada... and share the series with your friends and colleagues! The more we see you're interested, the more we'll be able to create new content for you.

Tell us your feedback!

We're here to help you learn and grow, so we'd love to hear your feedback on the series. What did you like? What could be improved? What topics would you like to see covered next? Let us know by opening an issue in the GitHub repository or by commenting on the videos. We're always listening, and we love to hear back from you! 🙌

You can also join the discussion on the AI Community #JavaScript channel on Discord to chat with other developers, ask questions, and share your own projects.

THANK YOU for taking this journey with us, I'm excited to see what you'll build!

TL;DR

Generative AI, from your local machine to Azure with LangChain.js

Yohan Lasorsa — Tue, 18 Jun 2024 14:58:00 +0000

The generative AI landscape moves at a fast pace, and it can be challenging to keep up with the latest developments, even for seasoned developers. There are in particular two questions that often come up when starting a new AI project:

How can I quickly validate an AI app idea, without investing too much time and resources?
If I have a working prototype, how fast can I scale it to production?

You don't want to be outpaced by competitors or newer technologies, and you want to be able to quickly iterate on your ideas or pivot to new ones. This is where LangChain.js comes in. It's a framework that allows you to build AI applications very little adherence to the underlying AI technologies and tools. It abstracts some of the complexity of AI development, allowing you to focus on the business logic of your application.

In this article, we'll take you through the development journey, starting from an idea and progressing towards production. We'll explore how LangChain framework together with Azure AI building blocks allows you to quickly build complex AI applications at the various stages of development.

Note: If you prefer to watch a video version of this article, you can find it on YouTube here.

TL;DR key takeaways

AI is not only reserved to Python developers: JavaScript developers also have everything they need to build AI applications.
LangChain.js provides useful abstraction over AI models and APIs, allowing you to switch between them easily. This is particularly useful when you're experimenting with different models or when you want to scale your application, moving from a local SLM model to a cloud-based LLM.
Ollama is allow you to experiment with AI models and embeddings locally, at no cost (if you have a powerful enough machine).
Azure provides many AI building blocks and services that you can use to scale your application to production.

Here's the source code on GitHub of the project we use as an example in this article.

If you like the project, don't forget to give it a star ⭐️!

Working locally with Ollama

Ollama is a command-line tool that allows you to run AI models locally on your machine, making it great for prototyping. Running 7B/8B models on your machine requires at least 8GB of RAM, but works best with 16GB or more. You can install Ollama on Windows, macOS, and Linux from the official website: https://ollama.com/download.

Once you have Ollama installed, let's first download some models. You can find a list of available models on the Ollama website. For this example, we'll use the Phi-3 Mini model. Open a terminal and run the following command:

ollama pull phi3

Note: This will download a few gigabytes of data, so make sure you have enough space on your machine and a good internet connection.

Once the model is downloaded, you can start interacting with the Ollama server. For example, you can use the ollama run command to generate text based on a prompt:

ollama run phi3 "What is artificial intelligence? Explain it to a 5 years old child."

You can also have a minimal ChatGPT-like experience right from you terminal by just running:

ollama run phi3

You can then chat with the model interactively. Once you're done, you can stop the server by pressing Ctrl+D.
Ollama also provides a REST API that you can use to interact with the model. The API provides many options, like streaming, JSON mode, and more. Here's an example of how you can use the API:

curl http://localhost:11434/api/generate -d '{
  "model": "phi3",
  "prompt": "What is artificial intelligence? Explain it to a 5 years old child.",
  "stream": false
}'

After running this command you should see a JSON response from the model
Ollama even provides an OpenAI compatible API, so you can use it as drop-in replacement for OpenAI models in your applications. And as Ollama runs entirely on your machine, it means you don't even need a network connection to use it.

While Ollama is great for experimentation and prototyping, keep in mind that smaller models are not as powerful as the larger models available in the cloud. While it might be enough to validate your idea, you'll probably want to switch to cloud-based models for production to get better results.

Prototyping with LangChain.js

Now that we know how to run AI models locally, let's see how we can use LangChain.js to quickly prototype an AI application. LangChain.js is a JavaScript framework that provides a high-level API to interact with AI models and APIs with many built-in tools to make complex AI applications easier to build.

Let's start with a simple example project from scratch. Open a terminal and run the following commands:

# Creates a new folder and initializes a new Node.js project
mkdir langchain-demo
cd langchain-demo
npm init es6 -y
npm i langchain @langchain/core @langchain/community pdf-parse faiss-node
touch index.js

Now open the index.js file in your favorite code editor and add the following code:

import { HumanMessage, SystemMessage } from "@langchain/core/messages";
import { ChatOllama } from "@langchain/community/chat_models/ollama";

const model = new ChatOllama({ model: "phi3" });
const response = await model.invoke([
  new SystemMessage("You're a helpful assistant"),
  new HumanMessage("Say hello"),
]);

console.log(response.content);

Run the code with node index.js. You should see the response from the model in the console. Congrats, you've just built the hello world of AI chatbots!

A more complex example

What if I want to use RAG (Retrieval-Augmented Generation) to ground the answers using documents? Let's update our index.js file with the following code:

import { RecursiveCharacterTextSplitter } from "langchain/text_splitter";
import { createStuffDocumentsChain } from "langchain/chains/combine_documents";
import { createRetrievalChain } from "langchain/chains/retrieval";
import { ChatPromptTemplate } from "@langchain/core/prompts";
import { ChatOllama } from "@langchain/community/chat_models/ollama";
import { OllamaEmbeddings } from "@langchain/community/embeddings/ollama";
import { FaissStore } from "@langchain/community/vectorstores/faiss";
import { PDFLoader } from "@langchain/community/document_loaders/fs/pdf";

// 1. Initialize the models
const model = new ChatOllama({ model: "phi3" });
const embeddings = new OllamaEmbeddings({ model: "all-minilm:l6-v2" });

// 2. Load PDF document and split it into smaller chunks
const loader = new PDFLoader("terms-of-service.pdf", { splitPages: false });
const pdfDocument = await loader.load();
const splitter = new RecursiveCharacterTextSplitter({ chunkSize: 1000, chunkOverlap: 100 });
const documents = await splitter.splitDocuments(pdfDocument);

// 3. Put the documents into a vector store and convert them to vectors
const store = await FaissStore.fromDocuments(documents, embeddings, {});

// 4. Create the RAG chain that retrieves and combines the prompt with the documents
const combineDocsChain = await createStuffDocumentsChain({
  llm: model,
  prompt: ChatPromptTemplate.fromMessages([
    ["system", "You're a helpful assistant"],
    ["human", "Answer the question: {input}\nusing the following documents:\n\n{context}"],
  ]),
});
const chain = await createRetrievalChain({
  retriever: store.asRetriever(),
  combineDocsChain,
});

// 5. Generate the result
const response = await chain.invoke({ input: "What's our mission?" });
console.log(response);

This code will load a PDF document, split it into smaller chunks, convert them to vectors, and then use them in a multi-step workflow (chain) to perform a vector search and generate a response using the best results. Pheeew! This one is a more complex example, but it shows how LangChain.js can help you build more advanced AI scenarios in a few lines of code.

Before running this code, you first need to download this PDF document and put it in the langchain-demo folder.

We also need to download the embeddings model. You can do this by running the following command:

ollama pull all-minilm:l6-v2

This one is very small (~50MB), and helps converting text to vectors. Now you can run your code with:

node index.js

The resulting answer directly comes from the PDF document, you can open it and look at the original mission statement at the beginning of the document to see how the model used it in its response.

Using the same principles as this example, we've prototyped a chatbot for the Contoso Real Estate company: we’ve built an experience that allows customers to ask support questions about the usage of its products. You can find the full source code of the project on GitHub. The final results, with an added chat UI, look like this:

Now that we have a working prototype, let's see how we can deploy it to production using Azure.

Migrating to Azure

Azure provides many AI services that you can use for your applications, in our case we'll use Azure OpenAI for the models and Azure AI Search as our vector database. Thanks to LangChain.js abstraction, migrating your prototype to Azure for production is relatively straightforward, as you can swap the models and vector database without changing anything else in your code.

If you look at the chat API code, this is what we use to run the code locally with Ollama:

embeddings = new OllamaEmbeddings({ model: ollamaEmbeddingsModel });
model = new ChatOllama({
  temperature: 0.7,
  model: ollamaChatModel,
});
store = await FaissStore.load(faissStoreFolder, embeddings);

Switching to Azure OpenAI and Azure AI Search is as simple as changing the model and store initialization:

const credentials = getCredentials();

embeddings = new AzureOpenAIEmbeddings({ credentials });
model = new AzureChatOpenAI({
  temperature: 0.7,
  credentials,
});
store = new AzureAISearchVectorStore(embeddings, { credentials });

We use passworless authentication for increased security, so we don't need to store any secrets in our code. The implementation of the getCredentials was omitted for simplicity, but you can find it here.

And that's it for the migration, at least for the code part, as to make it work you still have to create the necessary resources in Azure. We'll cover this in the next section.

Azure Developer CLI

As developers, we know infrastructure is no fun, but it's a necessary part of deploying applications to the cloud. Azure provides a tool called Azure Developer CLI that makes it easier to create and manage resources in Azure. It allows you to use Infrastructure as Code to define your resources in a declarative way, and then deploy them with a single command.

We won't cover in details how to build the infrastructure templates, if you're curious though you can have a look at the infra folder and the azure.yaml file used to configure and deploy the resources.

The good news is that we have many samples that you can use as a starting point for your own project infrastructure. Once the configuration is done, you can create the resources and deploy the application with a few commands:

# Authenticate to Azure
azd auth login
# Provision and deploy the resources
azd up

You can try it with our Serverless AI Chat project we used as an example in this article.

Azure building blocks

We skipped a bit over the implementation details of our example project, but to build it quickly we used some of the already existing Azure AI building blocks. Here's a list of some components we used, that you can reuse in your own projects:

OpenAI Node.js SDK: we announced at Build a new integration of Azure OpenAI with the official OpenAI Node.js SDK, meaning it's now easier than ever to switch between OpenAI and Azure OpenAI models. The LangChain.js Azure OpenAI integration has also been updated to use this new SDK.
Azure integrations in LangChain.js: we've contributed support for many Azure services in LangChain.js, to make it easier to build your AI applications on top of Azure. This includes Azure OpenAI, Azure AI Search, Azure CosmosDB, and more. You can find more information in the LangChain.js documentation.
AI Chat protocol: we've defined an API schema for AI chat applications, to make the frontend and backend components communicate. This schema is implemented in many of our AI samples, making them interoperable and easy to extend. We also provide an NPM package that includes the TypeScript types for the data objects and a client library to interact with the API.
AI Chat UI components: if you want to focus on the backend part of your AI chat application, we provide a set of web components that implements the AI Chat protocol. You can use them to quickly build a chat UI for your application. And since most of our AI samples also implement the protocol, you can also reuse any of their frontend component if you prefer, like the one we used in our example project.

Conclusion

We've covered a lot of ground in this article, starting from running AI models locally with Ollama, to prototyping a chatbot with LangChain.js, and finally deploying it to production on Azure. In a fast-paced environment like AI development, using JavaScript with existing high-level frameworks like LangChain.js and building on top of off-the-shelf building blocks can help you iterate quickly on your ideas and eventually bring them to production.
you can quickly iterate on your ideas and bring them to production with the right tools and services.

Reference links

Here are some useful links to get you started with the tools and services we've mentioned in this article:

Build a serverless AI Chat with RAG using LangChain.js

Yohan Lasorsa — Wed, 10 Apr 2024 14:55:38 +0000

We're still at the beginning of exploring what we can do with generative AI, and the field is moving fast, very fast!

And when things move fast, you need to be able to experiment and iterate quickly. First to validate your ideas with a prototype, then to scale up to production if it works.

In this article, we'll show you how LangChain.js, Ollama with Mistral 7B model and Azure can be used together to build a serverless chatbot that can answer questions using a RAG (Retrieval-Augmented Generation) pipeline. We'll see first how you can work fully locally to develop and test your chatbot, and then deploy it to the cloud with state-of-the-art OpenAI models.

Here's a preview of the final project:

Grab your favorite beverage ☕, and let's dive in!

TL;DR key takeaways

LangChain.js provides abstraction over AI models and APIs, allowing you to switch between them easily. Built-in support for advanced chains components makes complex AI workflows like RAG easy to build.
Ollama is a powerful tool to experiment with AI models and embeddings locally.
Azure Cosmos DB for MongoDB vCore can be used as a vector database for AI workloads, in addition to your regular NoSQL storage.

Here is the final project source code on GitHub.

If you like the project, don't forget to give it a star ⭐️!

What will you learn here?

In this article, we will:

Install required tools and set up the project
Use Ollama to experiment with the Mistral 7B model on your local machine
Run the project locally to test the chatbot
Explain the RAG pipeline and how it can be used to build a chatbot
Walk through LangChain.js building blocks to ingest the data and generate answers
Deploy the chatbot to Azure Functions, using Azure Cosmos DB for MongoDB as a vector database (optional)

As you can see, we have a lot to cover so feel free to take your time and experiment with the code as you go through the article.

Reference links for everything we use

Requirements

A working Node.js v20+ environment
A machine with a GPU supported by Ollama
Git
A GitHub account
(Optional, for Azure deployment) An Azure account to create the resources and deploy the app. If you don't have an account, you can create one for free using this link. If you're a student, you can also get free credits with Azure for Students.

Getting started

First let's fork and clone the project repository on your machine. This will allow you to experiment with the code and make changes as you go through the article.

Open the following link, then select Create fork button: Fork on GitHub
On your forked repository, select the Code button, then the Local tab, and copy the URL of your forked repository.
Open a terminal and run this command to clone the repo: git clone <your-repo-url>

In a terminal, navigate to the project folder and install the dependencies with:

npm install

It's almost ready! Before running the app, we need first have to setup Ollama to have a local AI playground.

Install Ollama and local models

Ollama is a CLI tool that allows you to experiment with AI models and embeddings locally. It's a great tool to test and validate your ideas before deploying them to the cloud.

Go to Ollama's website and download the latest version for your platform. Once installed, you can use the ollama command in your terminal.

We'll start by downloading the models we need for this project. Run the following commands in your terminal:

ollama pull mistral
ollama pull all-minilm:l6-v2

This will pull the Mistral 7B model, a powerful language model that we'll use for the chatbot, and the All-MiniLM model, a small embedding model that we'll use to generate the vectors from the text.

Note: The mistral model with download a few gigabytes of data, so it can take some time depending on your internet connection.

Once the models are downloaded, you can test that the Ollama server is working correctly by running:

ollama run mistral

You should get an invite in your terminal, where you can chat with the AI model directly, like a minimal chatbot:

Try asking a few questions to the model, and see how it responds. This will give you a good idea of the capabilities of the model and how you can interact with it.

Once you're done, you can stop the Ollama server by pressing Ctrl+D in your terminal.

Running the project locally

Now that we have the models ready, we can run the project to test the chatbot. Open a terminal in the project root and run:

npm start

This will start a dev server for the frontend, and an Azure Functions runtime emulator for the backend. You can access and play with the chatbot at http://localhost:8000.

Note: The first time you run the project, it can take a few minutes to start the backend API as it will download the runtime dependencies.

You should end up with a familiar chat interface, where you can ask questions and get answers from the chatbot:

For this demo, we use a fictitious company called Contoso Real Estate, and the chatbot can answer support questions about the usage of its products. The sample data includes a set of documents that describes its terms of service, privacy policy and a support guide.

You can try using the suggested questions, or ask your own questions to see how the chatbot responds. Try also asking something completely out of context, like "Who won the latest football world cup?" to see how the chatbot handles it.

Understanding the RAG pipeline

The chatbot we built uses a RAG (Retrieval-Augmented Generation) pipeline to answer questions. But what is RAG?

RAG is a method used in artificial intelligence, particularly in natural language processing, to generate text responses that are both contextually relevant and rich in content using AI models.

At its core, RAG involves two main components:

Retriever: Think "like a search engine", finding relevant information from a knowledgebase, usually a vector database. In this sample, we're using Azure CosmosDB for MongoDB vCore as our vector database.
Generator: Acts like a writer, taking the prompt and information retrieved to create a response. We're using here a Large Language Model (LLM) for this task.

When you ask a question to the chatbot, the RAG pipeline works like this:

The question is sent to the retriever, which will find the most relevant documents in the knowledgebase.
We used the top N retrieved documents along with the question to generate a prompt for the generator.
The generator (here the AI model) will then use the prompt to generate a response, which is sent back to the user.

Exploring the LangChain.js building blocks

To build the RAG pipeline, we're using LangChain.js, a library that provides an abstraction layer over AI models but also comes with advanced chain components to build AI workflows, including RAG.

We'll now dive into the code to understand the various parts of the pipeline, and the components we used to implement it.

Our backend API is composed of two main endpoints:

/documents: This endpoint allows to upload a PDF documents in the database, performing text extraction and vectorization as part of the ingestion process.
/chat: This endpoint receives a list of messages, the last being the user query and returns a response generated by the AI model. It uses the documents stored in the database to generate the response.

The `/documents` endpoint

Here we use LangChain.js to extract the text from the PDF file, split it into smaller chunks, and generate vectors for each chunk. We store the text and the vectors in the database for later use in our RAG pipeline.

Open the file packages/api/src/functions/documents-post.ts in your code editor.
Let's analyse the main parts of postDocuments() function:

// Get the uploaded file from the request
const parsedForm = await request.formData();

if (!parsedForm.has('file')) {
  return badRequest('"file" field not found in form data.');
}

const file = parsedForm.get('file') as File;
const filename = file.name;

We start by parsing the form data to get the uploaded PDF file name and content. We use the standard MIME type multipart/form-data to handle file uploads here.

// Extract text from the PDF
const loader = new PDFLoader(file, {
  splitPages: false,
});
const rawDocument = await loader.load();
rawDocument[0].metadata.filename = filename;

// Split the text into smaller chunks
const splitter = new RecursiveCharacterTextSplitter({
  chunkSize: 1500,
  chunkOverlap: 100,
});
const documents = await splitter.splitDocuments(rawDocument);

Next we use LangChain.js components to perform the text extraction and splitting. We use the PDFLoader to extract the text from the PDF file, and the RecursiveCharacterTextSplitter to split the text into smaller chunks.

Splitting the text into smaller chunks is important to improve the retrieval performance, as it allows the retriever to find more relevant information in the documents. It also helps with the AI models' limitations on the prompt input size, and ultimately reduces the usage cost when using hosted cloud models.

// Generate embeddings and save in database
if (azureOpenAiEndpoint) {
  const store = await AzureCosmosDBVectorStore.fromDocuments(documents, new AzureOpenAIEmbeddings(), {});
  await store.createIndex();
  await store.close();
} else {
  // If no environment variables are set, it means we are running locally
  context.log('No Azure OpenAI endpoint set, using Ollama models and local DB');
  const embeddings = new OllamaEmbeddings({ model: ollamaEmbeddingsModel });
  const store = await FaissStore.fromDocuments(documents, embeddings, {});
  await store.save(faissStoreFolder);
}

Now is the most important part: we generate the embeddings for each chunk of text and store them in the database. LangChain.js abstracts a lot of the complexity here, allowing us to switch between different embeddings models easily. Here we use the Azure OpenAI embeddings for the cloud deployment, and the Ollama embeddings for the local development. You can see that it's easy to switch between the two as LangChain.js provides a common interface for both.

if (connectionString && containerName) {
  // Upload the PDF file to Azure Blob Storage
  context.log(`Uploading file to blob storage: "${containerName}/${filename}"`);
  const blobServiceClient = BlobServiceClient.fromConnectionString(connectionString);
  const containerClient = blobServiceClient.getContainerClient(containerName);
  const blockBlobClient = containerClient.getBlockBlobClient(filename);
  const buffer = await file.arrayBuffer();
  await blockBlobClient.upload(buffer, file.size, {
    blobHTTPHeaders: { blobContentType: 'application/pdf' },
  });
} else {
  context.log('No Azure Blob Storage connection string set, skipping upload.');
}

Finally, we upload the original PDF file to Azure Blob Storage. This is useful to keep a copy of the documents, and also to provide a way to download them later if needed. But it's not mandatory for the chatbot to work, so we can skip it entirely if we're running locally.

The `/chat` endpoint

In this endpoint we use LangChain.js components to connect to the database, load the documents and perform a vector search after vectorizing the user query. After that, the most relevant documents are injected into the prompt, and we generate the response. While this process seems complex, LangChain.js does all the heavy lifting for us.

Open the file packages/api/src/functions/chat-post.ts in your code editor.
Let's skip to the most interesting part of the postChat() function:

let embeddings: Embeddings;
let model: BaseChatModel;
let store: VectorStore;

if (azureOpenAiEndpoint) {
  // Initialize models and vector database
  embeddings = new AzureOpenAIEmbeddings();
  model = new AzureChatOpenAI();
  store = new AzureCosmosDBVectorStore(embeddings, {});
} else {
  // If no environment variables are set, it means we are running locally
  context.log('No Azure OpenAI endpoint set, using Ollama models and local DB');
  embeddings = new OllamaEmbeddings({ model: ollamaEmbeddingsModel });
  model = new ChatOllama({ model: ollamaChatModel });
  store = await FaissStore.load(faissStoreFolder, embeddings);
}

We start by initializing the AI models and the database. As you can see switching between the cloud and local models is straightforward, and the good news is that it's the only change needed!

// Create the chain that combines the prompt with the documents
const combineDocsChain = await createStuffDocumentsChain({
  llm: model,
  prompt: ChatPromptTemplate.fromMessages([
    ['system', systemPrompt],
    ['human', '{input}'],
  ]),
  documentPrompt: PromptTemplate.fromTemplate('{filename}: {page_content}\n'),
});

The first part of our RAG chain is using the createStuffDocumentsChain() function to combine the prompt with the documents. We use the templating features of LangChain.js to create the differents parts of the prompt:

The system prompt, which is a fixed message that we inject at the beginning of the prompt. You can have a look at it to understand the different parts of what it does and what it contains. The most important part is the {context} placeholder at the end, which will be replaced by the retrieved documents.
The human prompt, which is the user query. We use the {input} placeholder to inject the user query into the prompt.
The document prompt, which is used to format how we inject the retrieved documents into the system prompt. Our format is simple here, we just prepend the document filename to the content of the page.

// Create the chain to retrieve the documents from the database
const chain = await createRetrievalChain({
  retriever: store.asRetriever(),
  combineDocsChain,
});

The next part of our chain is the retrieval of the documents from the database. The createRetrievalChain() abstracts the process entirely: we just need to provide the retriever and the combineDocsChain, and it will take care of the rest. It will do a few things behind the scenes:

Convert the user query into a vector using the embeddings model.
Performs a vector search in the database to find the most relevant documents.
Injects the most relevant documents into the context of the chain.
Passes the context to our previous combineDocsChain to generate the prompt.

// Generate the response
const lastUserMessage = messages.at(-1)!.content;
const responseStream = await chain.stream({
  input: lastUserMessage,
});

return data(createStream(responseStream), {
  'Content-Type': 'application/x-ndjson',
  'Transfer-Encoding': 'chunked',
});

Finally, the last part of the chain is to generate the response using chain.stream() and passing the last user message, containing the question, as input. The response is then streamed back to the client.

We use a stream of newline-delimited JSON (NDJSON) for the response, following the AI Chat Protocol as our API contract between the frontend and the backend.

Deploying the chatbot to Azure (optional)

Now that we have a working chatbot locally, we can deploy it to Azure to make it accessible to the world. You've noticed how we handle the changes needed in the two endpoints to make the code work both locally and in the cloud.

When deployed, the project architecture will look like this:

We'll use Azure Functions to host the backend API, and Azure Static Web Apps to host the frontend. The Blob Storage will be used to store a copy of the original PDF documents, and Azure Cosmos DB for MongoDB vCore will be used as the vector database.

To deploy the application on Azure, you'll need a few things:

An Azure account. If you don't have an account, you can create one for free using this link. If you're a student, you can also get free credits with Azure for Students.
An Azure subscription with access enabled for the Azure OpenAI service. You can request access with this form.
Azure Developer CLI

Once you have everything ready, you can deploy the project with the following steps:

Open a terminal at the root of the project.
Authenticate with Azure by running azd auth login.
Run azd up to deploy the application to Azure. This will provision Azure resources, deploy this sample, and build the search index based on the files found in the ./data folder.
- You will be prompted to select a base location for the resources. If you don't know which one to choose, you can select eastus2.
- By default, the OpenAI resource will be deployed to eastus2. You can set a different location with azd env set AZURE_OPENAI_RESOURCE_GROUP_LOCATION <location>. Currently only a short list of locations is accepted. That location list is based on the OpenAI model availability table and may become outdated as availability changes.

The deployment process will take a few minutes. Once it's done, you'll see the URL of the web app in the terminal.

You can now open the resulting link for the web app in your browser and start chatting with the bot.

If you're curious about the resources created, you can check them in the Azure portal. You'll find a resource group with the following resources:

We used Infrastructure as Code to set up the resources, you can look into the infra folder to see the templates used to deploy the resources.

Cleaning up the resources

To clean up all the Azure resources created and stop incurring costs, you can run the following command:

Run azd down --purge
When asked if you are sure you want to continue, enter y

The resource group and all the resources will be deleted.

Going further

This was only an introduction to the possibilities of building AI-powered applications with LangChain.js and Azure (but still quite lengthy!). If you want to dig further into Generative AI or LangChain.js, here are some resources I recommend:

LangChain.js documentation: the official documentation for LangChain.js, with tutorials and examples to get you started.
Generative AI For Beginners: a collection of resources to learn about Generative AI, including tutorials, code samples, and more.
Azure OpenAI Service: the official documentation for the Azure OpenAI Service, which provides access to the latest AI models from OpenAI.
Ask YouTube: LangChain.js + Azure Quickstart sample: another LangChain.js sample project that uses RAG to answer questions from YouTube videos.
Chat + Enterprise data with Azure OpenAI and Azure AI Search: an enterprise implementation of the chatbot, using Azure AI Search
Revolutionize your Enterprise Data with Chat: Next-gen Apps w/ Azure OpenAI and AI Search: a blog post that explain the RAG approach using Azure OpenAI and Azure AI Search.

You can also find more Azure AI samples here.

Follow me on Twitter, I would be happy to discuss and take your suggestions!

A simpler and smaller Angular starter with ngLite

Yohan Lasorsa — Fri, 29 Jul 2022 13:02:18 +0000

A lot of complaints I heard when starting with Angular are about the sheer amount of files you get even on simple apps. When looking at the default starter template you get from Angular CLI's ng new command, it's true that it can be a bit overwhelming if you're not used to it.

But it doesn't have to always be that way. In this article, we'll explore how we can create a smaller and simpler template that's also easier to grasp for beginners, following the YAGNI principle.

Note: what we'll discuss here doesn't aim to be a new universal starter to replace the default one for all use cases, but rather an experiment on how it's possible to make things simpler.

Getting prepared

Make sure you have a recent Node.js runtime installed (at least v14), and let's start by installing the Angular CLI.

npm install -g @angular/cli

This command-line tool is used to initialize new projects, among other things. After installing, you usually use it to create a new Angular project with the ng new command, but hold off a bit!

If you're old enough, maybe you remember using nLite to slim down your Windows install, back in the day? We'll take a similar approach here with the Angular starter to create a "ngLite" template, making sure to keep the number of files to a minimum..

Note: In the following sections, we'll take some time to understand the base application template and how it can be slimmed down for simpler projects. If you want to skip directly to the end result, you can use the command npx degit sinedied/ng-lite-starter my-app that will use this pre-made github template, but you'll miss all the fun 😉.

Slimming down the starter template

Let's create our app with this (long) command:

ng new ng-lite --minimal --inline-template --inline-style --routing=false --style=css

Let's explain the options we used here:

--minimal: creates a minimal project, without any test tools. When we'll get there, we'll probably want to use a better test framework than the default one anyways.
--inline-template and --inline-style: enables single file components (SFC), including the HTML template and CSS styling directly into your TypeScript components. Instead of 3 files per component, you'll get only one.
--routing=false: disables the default routing system. We can always add it back later if needed.
--style=css: use standard CSS styling for our components. If you prefer other flavors like SCSS, you can adapt this option to suit your needs.

After the files are generated and the dependencies installed, let's hop into the ng-lite folder and start with some cleaning, removing dependencies we don't need.

cd ng-lite

# Remove the dependencies we don't need
# It's not because it's part of the framework that we have to use it :)
npm rm @angular/animations @angular/forms @angular/router @angular/platform-browser-dynamic

Now let's have a look at all the files we have:

.vscode/
|- extensions.json
|- launch.json
|- tasks.json
src/
|- app/
| |- app.component.ts
| |- app.module.ts
|- assets/
| |- .gitkeep
|- environments/
| |- environment.prod.ts
| |- environment.ts
|- favicon.ico
|- index.html
|- main.ts
|- polyfills.ts
|- styles.css
.browserslistrc
.gitignore
angular.json
package.json
README.md
tsconfig.app.json
tsconfig.json

The .vscode folder contains configurations related to the Visual Studio Code editor. It provides tasks to debug your app when pressing F5 key, and suggests you to install the must-have Angular language service extension when you open the project. If you don't use VS Code though, you can remove this folder.

Next, we'll slim down a bit the number of files at the root of the project. You can see two tsconfig.json files there, used for TypeScript configuration. This separation may be useful when you want to use a different configuration for your tests, which is the case for the default setup created by ng new, but we don't need it here. Add these lines coming from tsconfig.app.json at the bottom of the tsconfig.json file:

  "files": [
    "src/main.ts"
  ],
  "include": [
    "src/**/*.d.ts"
  ]

And remove tsconfig.app.json:

rm tsconfig.app.json

We'll need to change a bit the angular.json file before your app can build again, but let's keep that for later.

Now, there's another file that we can get rid of: .browserslistrc. It's a file that tells which browsers you want to support, and the Angular build system will adjust the CSS and JS output accordingly. Instead of having a separate file for that, you can add this entry at the end of the package.json file:

  "browserslist": [
    "last 1 Chrome version",
    "last 1 Firefox version",
    "last 2 Edge major versions",
    "last 2 Safari major versions",
    "last 2 iOS major versions",
    "Firefox ESR"
  ]

Then you can remove the .browserslistrc file.

rm .browserslistrc

Reworking the `src/` folder

In the src/ folder, you'll find a file named polyfills.ts that may contain polyfills, small pieces of code used to provide a compatibility layer for newer features. If you're targetting recent browsers, you can get rid of this file and just add the zone.js import at the top of main.ts:

// Add this at the top of main.ts
import 'zone.js';

Then, remove polyfills.ts:

rm src/polyfills.ts

Now, there's a folder named assets/ that you can use to put any assets (images, fonts, JSON files...) you want to be copied to the dist/ folder. It contains an empty .gitkeep to get the folder stored in the git repo, as git doesn't store empty folders. We can simplify this structure a bit, by also grouping our future assets with the base index.html and favicon file:

# Removes assets/ folder
rm -rf src/assets
# Creates a public/ folder instead
mkdir src/public
# Moves index.html and favicon.ico files into it
mv src/index.html src/favicon.ico src/public

This doesn't change much, but it's more in line with what you can find in almost all other web frameworks (React, Vue, Svelte...) and it means that you can easily add any new files to be placed at the root of the dist/ folder without having to edit angular.json every time, something we'll have to do once a bit later.

The next change we'll do here is get rid of src/app/app.module.ts. Starting with Angular 14, we can create apps using only components and that's perfect as it's all we need to get started.

⚠️ Keep in mind that Angular Standalone components are still in preview, so the API may still change in the future.

# Removes app.module.ts file
rm src/app/app.module.ts

Edit the file src/app/app.component.ts, our entry component, and add standalone: true at the top of the component properties:

@Component({
  // Add the line below
  standalone: true,
  ...

We'll finally update the entry point of the application located at src/main.ts, to bootstrap our app using our component. Replace the content of the file with this:

import 'zone.js';
import { enableProdMode } from '@angular/core';
import { bootstrapApplication } from '@angular/platform-browser';

import { AppComponent } from './app/app.component';
import { environment } from './environments/environment';

if (environment.production) {
  enableProdMode();
}

bootstrapApplication(AppComponent)
  .catch(err => console.error(err));

We'll keep the rest of the files as-is as they will be useful for our app:

src/styles.css is the global stylesheet for the app. You can use it to import any CSS lib you want to use, and put your global styling here.
src/environments/environment*.ts these files contain the environment configuration for the app. environment.ts will be used during development, and environment.prod.ts will replace it during production builds so it's an easy way to define any environment-specific settings, like your API URL.

Editing `angular.json`

The angular.json file is the (rather verbose) configuration file that tells the Angular CLI how to run your project's tasks, such as building your app. Since we changed a few things from the default app structure, our final step it to update this file to reflect our changes.

Replace the line "tsConfig": "tsconfig.app.json", with "tsConfig": "tsconfig.json",
Remove the line "polyfills": "src/polyfills.ts",
Replace the line "index": "src/index.html", with "index": "src/public/index.html",

Replace this:

"assets": [
  "src/favicon.ico",
  "src/assets"
],

with:

"assets": [
  {
    "glob": "**/*",
    "input": "src/public",
    "output": "."
  }
],

Finally, add the line "standalone": true, under the "@schematics/angular:component" key, as we'll use standalone components in our app:
```
// ...
"@schematics/angular:component": {
  "standalone": true,
  // ...
}
```

Wheew! That's a lot of changes, but we managed to simplify our starter template by quite a lot while still retaining essential Angular features. Look at this screenshot:

Also, a nice side effect of this work is the reduction of the initial bundle size, from a 150.91 kB total (46.20 kB gzipped) with the default ng new template to a 116.01 kB total (36.15 kB gzipped) with our starter.

Of course, that's a bit tedious and not something you want to do every time you start a new project! You can use this github template if you'd like to use this starter again in the future, or you can make your own.

What about testing?

You may have noticed that this template doesn't include any testing tools. This is fine for learning and personal projects, but it's not a good idea for a production app to skip unit testing.

While the default Angular starter includes unit tests, it makes use of the older and clunky Karma/Jasmine combo for unit testing.

When you need unit testing for your project, you can use the much better and faster testing framework Jest with our ngLite template by adding a few extra steps:

Run the command npm install --save-dev jest @angular-builders/jest @types/jest to install the dependencies.

Add a jest.config.js file to your project root with the following content:

module.exports = {
  clearMocks: true,
  collectCoverage: true,
  coverageDirectory: "coverage",
};

Add a tsconfig.spec.json file to your project root with the following content:

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "outDir": "./out-tsc/spec",
    "types": ["jest"],
    "esModuleInterop": true
  },
  "include": [
    "src/**/*.spec.ts",
    "src/**/*.d.ts"
  ]
}

In your angular.json file, add this after your serve configuration (under the architect key):
```
"test": {
  "builder": "@angular-builders/jest:run",
  "options": {
    "tsConfig": "tsconfig.spec.json"
  }
},
```
If you want to have tests generated by default when using the ng generate command, you can also remove all the "skipTests": true occurrences in this file.

Create your first test in src/app/app.component.spec.ts:

import { ComponentFixture, TestBed } from '@angular/core/testing';
import { AppComponent } from './app.component'; 

describe('AppComponent', () => {
  let component: AppComponent;
  let fixture: ComponentFixture<AppComponent>;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [AppComponent],
    }).compileComponents();

    fixture = TestBed.createComponent(AppComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

  it('should create the component', () => {
    expect(component).toBeTruthy();
  });
});

You can now run your tests with ng test or ng test --watch.

What's next?

If you followed closely, you've seen that we didn't even include some of Angular's core libraries like @angular/forms or @angular/router. Well, that's not because you're writing an Angular app that you have to use all of the provided libraries! For sure they're convenient, and you can always add them back later if you need them, but you can also build your entire app without them.

That's what we'll explore in a further article. Now that we have a simpler starter template, why not try building a complete app, and keeping the code as simple as it can?

In the meantime, you can have a look at this todo list app built from expanding on that idea.

Follow me on Twitter, I would be happy to discuss and take your suggestions!

New tips & tricks for your Azure Static Web Apps

Yohan Lasorsa — Mon, 23 May 2022 16:13:53 +0000

About a year ago, we published a series of videos to help you get the most out of Azure Static Web Apps. It's time to update it with fresh tips, as we got new exciting tools to improve your dev experience!

If you've never heard of Static Web Apps (or SWA for short), it's a web app hosting service provided by Azure, offering streamlined full-stack development with many built-in features like authentication, customizable routing, serverless functions and more. It also has a great free tier 😉

Tip #18: Run, build and deploy your apps with the new SWA CLI

With the release of the new SWA CLI, it's never been easier to get started with Azure Static Web Apps! With the new commands you can configure your project to test it locally with the emulator, and deploy it directly from the CLI in a few minutes. It also support multiple configurations, and it's compatible with monorepos. Watch the video to learn how to get started with the new commands.

Tip #19: End-to-end browser debugging of your Static Web Apps with VS Code

I love web development, but when you're trying to debug your app, whether it's the HTML, CSS or JavaScript, it always involves a lot of painful back and forth between your code editor and the browser. But thanks to this new VS Code extension, you can now preview and debug your apps without having to leave your editor, all from a single window! And it even comes with built-in hints and support for accessibility testing, so you won't have any excuses to not make your app accessible.

Tell us your feedback!

We're also here on dev.to to listen and help as much as we can! 🙂

Please tell us your experience, your difficulties and questions, and what videos you would like to see next in this series!

Deploy your Static Web Apps to Azure directly from the command line

Yohan Lasorsa — Fri, 20 May 2022 13:09:10 +0000

For this second article about the SWA CLI, we'll talk about the new deployment options. And yes, you can now deploy your apps straight from the command line! Who's better than the person who implemented it to talk about it? I'll let my friend Wassim explain it all to you.

Wassim CheghamFollow

Senior Developer Advocate at Microsoft ★ GDE for Google ★ Angular and Node.js contributor ★ BytecodeAlliance contributor & WebAssembly enthusiast

If you've never heard of Static Web Apps (or SWA for short), it's a web app hosting service provided by Azure, offering streamlined full-stack development with many built-in features like authentication, customizable routing, serverless functions and more. It also has a great free tier 😉

Logging in to Azure

In the new SWA CLI for Azure Static Web Apps, we introduced a new swa login command allowing you to log in to your Azure account, straight from the command line. This command will encrypt and store your credentials in your system's key Chain, so you don't have to enter them again.

In most common cases, the swa login will pick your current active Azure credentials from the following locations (in this order):

Your environment variables, if you have set one or all of following variables:
- AZURE_TENANT_ID
- AZURE_CLIENT_ID
- AZURE_CLIENT_SECRET
Your current Visual Studio Code, if you're using VS Code and is connected to Azure.
Interactive prompt using your browser.
The last fallback is the device code flow, which will prompt you to log in to your Azure account using a generated device code.

However, if you need, you can also provide any of these credentials from the command line, using the available flags:

Usage: swa login [options]

login into Azure

Options:
  -S, --subscription-id <subscriptionId>    Azure subscription ID used by this project
                                            (default: "process.env.AZURE_SUBSCRIPTION_ID")
  -R, --resource-group <resourceGroupName>  Azure resource group used by this project
  -T, --tenant-id <tenantId>                Azure tenant ID (default: "process.env.AZURE_TENANT_ID")
  -C, --client-id <clientId>                Azure client ID
  -CS, --client-secret <clientSecret>       Azure client secret
  -n, --app-name <appName>                  Azure Static Web App application name
  -cc, --clear-credentials                  clear persisted credentials before login (default: false)
  -u, --use-keychain                        enable using the operating system native keychain
                                            for persistent credentials (default: true)
  -nu, --no-use-keychain                    disable using the operating system native keychain

Once logged in, the SWA CLI will store your active Azure subscription ID and tenant ID in a local file called .env at the root of your project:

➜ swa login

Welcome to Azure Static Web Apps CLI (1.0.0)

Checking Azure session...
✔ Successfully logged into Azure!
✔ Saved project credentials in .env file.
✔ Successfully setup project!

This file will be used when deploying your project to Azure using the swa deploy command.

Deploying your app

The new SWA CLI makes it even more easier to deploy your apps to Azure. You can now deploy your app directly from the command line, using one single swa deploy command.

The swa deploy command is smarter enough to figure out if you already have an Azure Static Web Apps instance available, and if so, it will use it. Otherwise, it will create a new one on the fly - or prompt you to select one from a list of already available ones:

➜ swa deploy

Welcome to Azure Static Web Apps CLI (1.0.0)

Using configuration "thundr" from file:
  /home/wassimchegham/oss/@thundr-dev/thundr/swa-cli.config.json

Deploying front-end files from folder:
  /home/wassimchegham/oss/@thundr-dev/thundr/app/dist/thundr-ui

Deploying API from folder:
  /home/wassimchegham/oss/@thundr-dev/thundr/api

Checking Azure session...
✔ Successfully logged into Azure!

Checking project settings...
? Choose your Static Web App › - Use arrow-keys. Return to submit.
❯   >> Create a new application
    swa_samples/angular-web-bluetooth
    swa_samples/catsify
    swa_samples/hexa
    swa_samples/ngxtools
    swa_samples/nitrooo
  ↓ swa_samples/photobooth-teams

The swa deploy command is also able to detect if your existing Static Web Apps instance has already been deployed from a CI/CD pipeline and inform you about it!

Deploying from a CI/CD pipeline

Deploying from CI/CD pipelines is a common practice in many projects. You can use the swa deploy command to deploy your app to Azure from your CI/CD pipeline. You can accomplish this by setting a deployment token:

➜ swa deploy --print-token --app-name thundr --resource-group swa_samples

Welcome to Azure Static Web Apps CLI (1.0.0)

Checking project "thundr" settings...
✔ Successfully setup project!

Deploying to environment: preview

Deployment token:
7c3fc44b858164b677-truncated-8c80ace9-39a8-416c-ae22-864745c0470b003

swa deploy --deployment-token=7c3fc44b858164b677-truncated-8c80ace9-39a8-416c-ae22-864745c0470b003b003

You can also set the deployment token as an environment variable:

export SWA_CLI_DEPLOYMENT_TOKEN=7c3fc44b858164b677-truncated-8c80ace9-39a8-416c-ae22-864745c0470b003b003
swa deploy

Environment variables

The new SWA CLI introduced a new set of environment variables to make it easier for you to configure your experience. You can customize the behavior of the SWA CLI by setting the following environment variables:

General settings
Emulator settings
Deploy settings
Runtime settings
Login experience

You can read more about these environment variables in the Environment Variables section in our new documentation website.

Next steps

From the start of your project to its deployment to Azure, with all the needed local testing in-between, you should now be equipped to take care of your complete development process all from the command line. Now the main challenge remaining for you is to deploy and grow your app 😉.

If you'd like to learn some tips you can use when developing your app, you can check out the Static Web Apps - Tips & Tricks video series.

You can also learn more about all the new features of the SWA CLI and how to use them by looking at the new docs website.

Tell us your feedback!

We're also here on dev.to to listen and help as much as we can! 🙂

Please tell us your experience, your difficulties, your questions, and what features you would like to see in the next versions of the SWA CLI.

Get started with the new Azure Static Web Apps CLI

Yohan Lasorsa — Thu, 19 May 2022 14:46:06 +0000

You may have missed it, but the new Azure Static Web Apps CLI is now available!

It would take a whole post to describe all the changes and new features, but here are some of the highlights. With the new init, build, start and deploy commands, the complete developement cycle of your app is now available in a single tool, directly from the command line. To get started, make sur you have a recent Node.js version installed (>14) and type this command in your terminal:

npm i -g @azure/static-web-apps-cli

We'll now have a look at the new commands and the most important features.

If you've never heard of Static Web Apps (or SWA for short), it's a web app hosting service provided by Azure, offering streamlined full-stack development with many built-in features like authentication, customizable routing, serverless functions and more. It also has a great free tier 😉

`swa`

As the new CLI introduces a gazillion new options, it must quite a steep learning curve to get started? Quite the opposite!

Every command starts with swa, and now it might also be the only thing you'll need.

# yes, that's all you need to type
swa

This command is a macro shorcut for swa init, swa build, swa login and swa deploy. We'll get to the details of all these commands in a bit, the most important thing here is that swa is the only command you need to know to configure a new project for use with Static Web Apps, build it and deploy it. You don't have to worry about any options or flags, just type swa and you'll be on your way.

Creating the configuration

The first of the new commands is swa init. This commands with detect your project configuration and the frameworks you're using to suggest a configuration for you, so you won't have to read through the shiny new docs to figure out what options you need.

After asking a name for your project configuration, you can validate or edit the detected project settings. Once finished, it will create a swa-cli.config.json file in the current folder with your settings. You can commit this file in your project repository so everyone from your team can use it.

Building your project

After the configuration is created, you're all set to use other commands without having to bother with any options or flags.

Whether you need to build your front-end app, your API, or both, the swa build command will do the job. It also takes care of installing your NPM dependencies (if needed) detecting if you're using npm, Yarn or PNPM with your project.

Running your app locally

Historically, being able to run your app locally was the first feature of the SWA CLI. Of course it's still there, and swa start allows you to emulate the SWA runtime environment, along with the routing, authentication features and API. A few changes were made to improve the developer experience, and of course bugs were fixed to more closely match the real SWA runtime.

Previously, if you were using an API, you had to install Functions Core Tools and make sure to match the tools version with the Node.js version you're using, but now the whole process is automated for you. If you don't have the tools installed or if the wrong version is installed, you don't have to worry about it: it will be automatically installed for you when needed.

Next steps

With these new commands, you can already setup your project, build it and test it locally. Using swa start is also great for debugging your app and API in a live running environment. Once you're happy with the result, you can deploy it to Azure, and that's what we'll explore in the next post.

In the meantime, you can also head to the new docs website to learn more about the new features and how to use them.

Tell us your feedback!

We're also here on dev.to to listen and help as much as we can! 🙂

Please tell us your experience, your difficulties, your questions, and what features you would like to see in the next versions of the SWA CLI.

One simple command to improve your JavaScript workflow

Yohan Lasorsa — Tue, 15 Mar 2022 14:37:09 +0000

I don't know about you, but as a JavaScript developer, there's something I do hundreds of times a day: running NPM scripts to test, lint, build, serve, release and more.

And because I'm a CLI guy, that involves a lot of typing, which as a result involves a lot of typing mistakes. npm start or npm run build may seems short enough, but typing it hundreds of times is not.

That's why almost 4 years ago I've decided to find a better workflow. Ultimately, my goal have been to type the minimum amount of characters to run my scripts.

I've found a way to do that with fuzzy matching. I also found two existing tools that explored the same idea, fuzzy-npm-run and fuzzy-run. Both relied on the same library fuse.js which is not great for matching commands, as it doesn't weight properly specific features like subcommands separation (using characters like -, _, :) or first character of words. This led me to run the wrong scripts too many times to count...

Introducing `fuzz-run`

That's about when I've decided to spin my own runner tool. I benchmarked many fuzzy matching libraries, and kept the best one I found suited for the job, fuzzysort, as it solved all the issues I had with existing runners.

And this is what I've been using every day for the last years, running all my scripts with only a few characters:

You can install it with npm install -g fuzz-run, then its usage is dead simple:

If no arguments are provided, it will list all available scripts (no more digging in package.json).
Type nr <fuzzy_script_name> to run a script. You can even add options to the script, like nr b --watch. And no need for silly extra -- like with npm to pass those options.

The name of the script is fuzzy matched, this means that you either type only some letters of the script name, regardless of their position (first letters weights more), like t for the test script. For compound script names like test:ci, you can just type the first letters of each word, like tc. It will even match if you do simple typos, like ets for test.

Note that it will autodetect which package manager you're using in a project, and will run the script with the right commands whether you're using npm, yarn or pnpm.

That's it, you can now run your scripts with only a few characters, and you'll be as happy as I was when I started using it.

To be honest, I almost forgot about this tool, because well, it quickly become part of my dev habits, and I only think about it when I'm on a new setup and it's not there. That's also why I'm only writing this post now, almost 4 years later 😅

Bonus

My most frequent task being taken care of, I recently decided to think about how I could improve some other very common (and boring) tasks I do in almost every project I work on.

Updates, updates, updates

One of these tasks is updating dependencies. It often involves running npm outdated to check if there are any outdated dependencies, and then running npm update to update them within the allowed ranges in my package.json. Then most of the time, running npm outdated --long again to see the remaining ones with a link to their repository, so I can look at changelogs for possible breaking changes and decide if I want to update them, one npm install <package>@latest at a time.

When I remember the command, sometimes I use npm-check or npm-check-updates to save some time, but I most often don't remember which is the one I usually use and what's the syntax. Yarn has definitely an edge here with its yarn upgrade-interactive command.

So here comes a scripted action to tackle this task in a more automated way: nr --update or simply nr -u (because you know, the less characters to type the better 😉).

It will run this sequence of actions:

Run npm outdated to check for any outdated dependencies.
If there are any, ask if you want to run npm update to update them within the allowed ranges in package.json.
Finally, perform an interactive upgrade for packages outside your allowed ranges, with npx npm-check -u. You'll be able to choose which packages to upgrade, with a link to their repository to see the changelogs.

Of course, if you're within a Yarn or PNPM project, the commands will change accordingly.

With that, I won't have to remember the exact syntax of the commands, and I'll be able to run this task whatever package manager used for the project.

Fixing those install issues...

Another task I've been doing a lot more that I would like, is trying to fix those install issues that sometimes occur with npm install (and that includes Yarn, too).

You know, when the install fails or breaks for no apparent reason, and most often it's because the dependency tree could not be resolved properly after adding or updating a package. Which often results in rm -rf node_modules package-lock.json and npm install to try to fix the issue.

The nr --refresh or nr -r scripted action comes to the rescue, well doing exactly just that for you, with included adaptations for Yarn and PNPM. Again, less typing for me.

Final words

This is a very small tool that I've been using for a long time, and I hope it's useful to you even though I initially created it to scratch my own itch.

It's also completly open source, so you can contribute to it or fork it to make it your own.

Follow me on Twitter for more content, I would be happy to discuss about it and take your suggestions!

Instantly set up a new dev environment using containers and VS Code

Yohan Lasorsa — Thu, 30 Sep 2021 15:00:11 +0000

There are 3 things that make me waste a lot of time as a developer, and that can become a big source of frustration:

Set up a new development machine
Manage and update my development environment to work on a project
Reinstall everything again, because after many times installing and updating my dev tools everything broke :(

What if I told you that we can avoid these issues, and that it's possible to perfectly isolate each of your projects' environment? And to be able to share and update it easily, to have nothing to do when a newcomer joins your project?

It's now possible thanks to the Remote Development extension for VS Code and containers. In this post, I'll show you how to set up a complete dev environment inside a container and use it with your projects.

TL;DR key takeaways

You can quickly onboard a new developer in a project using dev containers, share it with your teammates, and update it with no hassle.
While nothing prevents you from using Docker and any IDE to do the same thing, the Remote Development extension provides seamless integration with VS Code to bootstrap and work with dev containers.
Dev containers also allow you to take your dev environment everywhere with online dev tools like GitHub Codespaces.

Why developing inside a container

In every software project, the developer story is (almost) always the same:

"Hey, welcome to the team! We're all excited to have you on board!" 🎉
"Here's the doc to set up your environment for the project. Let me know when you're ready!" (spoiler alert: sometimes there's no doc at all, and you'll have to ask your teammates to know what to install)

Most likely, a few hours/days later, the outcome is:

"Please help, I can't figure out why it's still not building/running properly" 😞

I've been that developer. A few times already.

After a while of spending time reviewing everything you installed, you'll eventually discover common issues usually are:

The environment setup doc is outdated (I bet you didn't see that one coming, right? Isn't that the newcomer's job to update it anyway?).
You installed the correct tools, but not the right version ("Sorry, We forgot to tell you'll have to use this specific version, as we have a few issues in our codebase").
You have some conflicts with the environment set up of other projects.

The thing is, we already know how to solve these problems, because that's the exact same issues we had with production environments when we ship our applications.

We solved all these problems by packaging the runtime environment of our applications into containers. Then, why not also use containers for our dev environment?

Requirements

You need to have these tools installed on your machine to get started:

Visual Studio Code
Docker (or any Docker-compatible client)
Remote Development Extension for VS Code

Getting started

Open VS Code on a new or existing project, then click on the bottom left
of the status bar, on the "opposing chevron" icon (let me know if you have a better name):

Once you do that, select Add Development Container Configuration Files..., and it will open a huge list of environments starters.

You'll find pre-made configurations for Node.js, Java, .Net, Go, Python, and more, most likely there is one that you can use as a starting point. Once you've made your choice, you'll notice that a new .devcontainer folder was created, containing 2 files:

We'll dig into these files just after, for now, let's reload the project to work inside a container.

Click again on that "opposing chevron" icon in the status bar, and select Reopen in container.

VS Code will reload the project's window and start building the container. Depending on your internet connection speed, this may take a while but don't worry, it's only needed the first time.

Once it's finished, you'll see that VS Code is connected to your dev container in the status bar. You can also open a terminal and play with your new dev environment (in my case, I've set up a new Node.js v14 environment).

Customizing the dev setup

Now that you have a working environment, you'll probably want to customize it for your project's needs. If you unfold the .devcontainer folder in the explorer, you'll see these 2 files that will allow you to do that:

Dockerfile: this file defines your container configuration, and is used to build the container image that will be used for your environment. If you need to install additional tools or configure scripts and environment variables for your dev environment, this is where you should look at.
devcontainer.json: this file allows to customize VS Code when the project is connected to a development container. In particular, you can specify VS Code settings, extensions, and port forwarding that will be enabled only in this project dev container.

Let's take a deeper look at how you can fine-tune your VS Code dev environment by editing your devcontainer.json file.

VS Code settings and overrides

You'll see something like this under the settings key:

// Set *default* container specific settings.json values
// on container create.
"settings": { 
  "terminal.integrated.shell.linux": "/bin/bash"
},

This key allows you to override any VS Code settings when it's connected to this container environment. For example, if you work on Windows and your default terminal is PowerShell, by connecting to the dev container the setting above with switch your default terminal to Bash instead, which will be run inside the Linux system of the dev container. With these settings, you can set a common code formatter for your team, or force GPG signing for your commits for example.

Another useful option is located under the extensions key:

// Add the IDs of the extension you want installed when
// the container is created.
"extensions": [
  "dbaeumeur.vscode-eslint"
],

This one allows specifying extensions that will be automatically installed within your dev container when it's run for the first time. Yes, you've read that well: these extensions won't pollute your global VS Code configuration, as they'll be available only when your dev container is started and connected to your project. No need to toggle your extensions anymore depending on your active project, no more having a useless C# extension active on your Java project!

One last essential option, forwardPorts, allows you to expose ports available from within your dev container and make them accessible by default from your local machine.

// Use 'forwardPorts' to make a list of ports inside the
// container available locally
"forwardPorts": [3000, 4200],

For example, if you run a web server within your dev container, without port forwarding you won't be able to access it in your browser. Note that it's also possible to add ports to forward on the fly, by clicking on the antenna icon in the status bar, then selecting Add Port:

Sharing and updating the environment

Once your container and VS Code configuration is finished, you only have to push these two files in your repository to make them available for your team. And it's one of the big benefits of this approach! To welcome a new developer to your project, you now only have to clone the project, reload VS Code to use the container config and that's it. Take a coffee (or many) while the container is downloading and installing tools on its first run, and your new developer will have a dev environment ready for work, without any effort.

Even better, if anyone updates the environment configuration, for example by upgrading a tool's version, everyone in the team will see this notification when pulling the changes:

You then only have to select Rebuild to update your environment to the latest version. No more difficulties building a project when coming back from vacation!

Where's the catch?

It almost seems too good to be true, so where's the catch?

I've been asking that to myself since I started using it from the first beta, and so far it's been a happy ride. If you wonder about the performance, yes doing everything inside a container is a bit slower than doing it on the host machine, but nothing to worry about. In some cases, you may face disk performance issues especially with lots of small files (looking at you, npm install) but there are tips to improve your filesystem performance with Docker.

The only issue I had at the beginning was with my git credentials as I'm using SSH keys, but once I've followed the guide to set up an SSH agent everything went smoothly.

You can have a look at the known limitations, but so far I've yet to have any issue with it.

What's next

This article is only a brief overview of what's possible with these tools, and of course, you can push it way further if needed, like creating a dev environment using multiple containers for example. You can have a look at the documentation for more advanced scenarios.

Going further, you could still argue that you have to install VS Code with the remote extension and a Docker-compatible runtime to make this work. It's also possible to get rid of that, using for example GitHub Codespace which makes use of the exact same tools and configuration to provide a cloud-based dev environment, accessible from any browser, without having to install anything (but a browser) on your machine.

Follow me on Twitter, I would be happy to discuss and take your suggestions!

DEV Community: Yohan Lasorsa

Host Your Node.js MCP Server on Azure Functions in 1 Simple Step

TL;DR key takeaways

What will you learn here?

Reference links for everything we use

Requirements

What is MCP and why does it matter?

Why Azure Functions for MCP servers?

1 simple step to enable Functions hosting

Step 1: Add the host.json configuration

Real-world example: Burger MCP Server

Current limitations

Testing the MCP server locally

Using MCP Inspector

Using GitHub Copilot (with remote MCP)

(Bonus) Deploying to Azure with Infrastructure as Code

Example projects

What about the cost?

Wrap up

Serverless MCP Agent with LangChain.js v1 — Burgers, Tools, and Traces 🍔

TL;DR key takeaways

What will you learn here?

Reference links for everything we use

Use case

Sample overview

LangChain.js v1 agent features

Quickstart

Requirements

Deploy and run the sample

Provision and deploy to Azure

Test the MCP server

MCP tools

Test the Agent Web App

Wrap it up

Going further

Using DeepSeek-R1 on Azure with JavaScript

Using DeepSeek-R1 on Azure with JavaScript

TL;DR key takeaways

What you'll learn here

Reference links

Requirements

Getting started

Running the samples

Model configuration

Deploying DeepSeek-R1 on Azure

Explore reasoning with DeepSeek-R1

Leveraging frameworks

Going further

Generative AI with JavaScript FREE course

Introducing Generative AI with JavaScript

Learn, share & teach

Want more?

Tell us your feedback!

TL;DR

Generative AI, from your local machine to Azure with LangChain.js

TL;DR key takeaways

Working locally with Ollama

Prototyping with LangChain.js

A more complex example

Migrating to Azure

Azure Developer CLI

Azure building blocks

Conclusion

Reference links

Build a serverless AI Chat with RAG using LangChain.js

TL;DR key takeaways

What will you learn here?

Reference links for everything we use

Requirements

Getting started

Install Ollama and local models

Running the project locally

Understanding the RAG pipeline

Exploring the LangChain.js building blocks

The /documents endpoint

The /chat endpoint

Deploying the chatbot to Azure (optional)

Cleaning up the resources

Going further

A simpler and smaller Angular starter with ngLite

Step 1: Add the `host.json` configuration

The `/documents` endpoint

The `/chat` endpoint

Reworking the `src/` folder

Editing `angular.json`

`swa`

Introducing `fuzz-run`