DEV Community: Sangeet Agarwal

Streamlining Routine ML Tasks with LangChain: A Hacker News Comment Analysis Example

Sangeet Agarwal — Wed, 05 Mar 2025 00:07:33 +0000

Introduction

LangChain and its companion framework LangGraph are synonymous with building autonomous "agents" capable of complex interactions -- retrieving external data, chaining multiple tools together, to name just a few. While that's certainly the case, I noticed they streamline more mundane day-to-day ML tasks.

One example is a Hacker News comment-analysis notebook I put together. There’s nothing earth-shattering about the underlying code, but I appreciate how LangChain abstracts away the complexity of interacting with large language models (LLMs). You can see the complete notebook in the langchain_hn_comment_analysis Jupyter notebook, available here in my GitHub repo.

Below, I’ll walk you through some of the key pieces—starting with how we define our LLM with structured output, then how we handle prompt templates to direct the model’s responses.

Setting up the LLM

from langchain_ollama import ChatOllama

llm = ChatOllama(
    model="qwen2.5",
    temperature="0.0",
    verbose=False,
    keep_alive=-1,
)

llm = llm.with_structured_output(PostCommentEvaluation, method="json_schema")

Here, ChatOllama integrates with the Ollama chat model. The parameters control various aspects:

model: Which LLM to use (e.g., “qwen2.5”).
temperature: How “creative” the model is (0.0 means very deterministic).
verbose: Toggles detailed logging.
keep_alive: Manages the LLM’s session or connection.

By calling llm.with_structured_output(PostCommentEvaluation, method="json_schema"), we tell LangChain that any response we get from the LLM should conform to the structure defined by our PostCommentEvaluation class. This eliminates the need to manually parse unstructured text or JSON—LangChain handles that for us. And if you ever switch to another chat model, LangChain’s chat model integrations let you do it with minimal code changes.

Defining the Output Schema

The PostCommentEvaluation class looks like so

from typing import List, Literal, Optional, ForwardRef
from pydantic import BaseModel, Field

class PostCommentEvaluation(BaseModel):
    """
    A class to represent the evaluation of comments.

    Attributes:
    summary (str): Summary of comments into a few sentences.
    key_points (List[str]): Key points from the comments.
    topics (List[str]): Main topics discussed in the comments.
    controversies (List[str]): Controversial takeaways from the comments.
    sentiment (Literal): Overall emotional sentiment of the comments.
    """
    summary: str = Field(..., description="Summary comments into a few sentences")
    key_points: List[str] = Field([], description="Key points from the comments")
    topics: List[str] = Field([], description="Main topics discussed in the comments")
    controversies: List[str] = Field([], description="Controversial takeaways from the comments")
    sentiment: Literal[
        "happiness", "anger", "sadness", "fear", "surprise", "disgust", "trust", "anticipation"
    ] = Field(..., description="Overall emotional sentiment of the comments")

The PostCommentEvaluation is a Pydantic class and it provides data validation out of the box. With this the LLM's response will be in the shape of the PostCommentEvaluation class.

Crafting the Prompt

The next bit is the prompt template—let’s call it EVALUATE_POST_COMMENTS_PROMPT. This is where LangChain really clicks for me. Here’s what happens:

I define a string template with placeholders like {post}, {comments}, and {user_question}.
LangChain’s PromptTemplate lets me fill those placeholders with real data (the HN post details, a chunk of comments, and my specific query).
Because I’m using f-string formatting by default, I don’t have to worry about weird template injection issues.

A snippet might look something like:

EVALUATE_POST_COMMENTS_PROMPT = PromptTemplate.from_template(
    """
    Analyze the comments:

    {post}

    <comments>
    {comments}
    </comments>

    Please summarize, highlight key points, identify controversies, and provide an overall sentiment. 
    Respond in JSON format with the following fields:
    summary, key_points, topics, controversies, sentiment.

    <user_question>
    {user_question}
    </user_question>
    """
)

If you’re curious about more advanced prompt patterns or want to see prompts that other folks are using, check out the LangChain Hub. It’s basically a marketplace where the community shares their custom prompt templates.

Putting It All Together
So how does this fit into the Hacker News pipeline?

Fetch Data: I grab a Hacker News post’s metadata plus its comments (including nested replies) via the Hacker News Firebase API.
Format Data: I have small utility functions to convert the post info and comments into a neat, template-friendly format.
Generate Prompt: Using those details, I fill in {post}, {comments}, and whatever user question I have (like “What’s the overall sentiment here?”).
Invoke the Model: Call llm.invoke(...) with the final prompt.
Validate & Use Results: LangChain returns a structured Python object that matches my PostCommentEvaluation. For instance:

{
  "summary": "Several commenters discussed the pros and cons of open sourcing…",
  "key_points": ["Open-source concerns", "Security vulnerabilities…"],
  "topics": ["Open source", "Security", "Community engagement"],
  "controversies": ["Whether it should remain private or not"],
  "sentiment": "anticipation"
}

Summary

LangChain may be best known for its advanced agent-based workflows, but this Hacker News project demonstrates its usefulness for simpler, day-to-day ML tasks. Not only did Pydantic schemas make it straightforward to enforce a well-defined output format, but working through the LangChain documentation also highlighted important best practices—like employing f-string templates for secure prompt construction. These lessons transfer directly to real-world ML pipelines, saving you both time and trouble when working with LLMs.

Securing SPA React app with Duende BFF

Sangeet Agarwal — Thu, 27 Feb 2025 16:19:56 +0000

Introduction

Storing access tokens in the browser was never a good idea. Unfortunately, implicit flow is based on storing access token in the browser. That is the reason implicit flow is not recommended anymore.

In this flow the access token is returned as part of the url and access token in urls is extremely leaky, they end up in

browser history
log files
Reverse proxies
Browser extensions
Referrer headers, so say you access a cdn and the cdn via the referer http request header can acquire the access token.

Shown below is a schematic of the implicit flow.

To prevent access tokens from being returned in the url, the authorization code flow was used where the client app receives an auth code and then exchanges it for an access token. Shown below is the schematic of the authorization code flow.

The problem of storing and managing access tokens in the browser will still remain though. Code injections attacks allow for exfiltration of storage contents. Injection attacks is OWASP top ten list ¹

In addition, browser vendors have been debating phasing out 3rd party cookies for some time now. It seems they’ve finally decided to bite the bullet per this article from developer chrome site. This would break any application that uses the implicit flow.

In implicit flow the client app receives the access token and then via the silent renew mechanism calls the IDP from an iframe to return a new token passing the cookie in the header. But now with 3rd party cookie disallowed, the iframe will not have access to this cookie anymore. So, essentially, the client is not able to maintain a session with the server and the server says "hey, client, you aren't even logged in".²

Using BFF architecture to solve the problem

BFF architecture introduces an intermediary layer that runs on the server and since it runs on the server it can manage tokens encrypted in HttpOnly cookies. The client app which now runs on the browser is absolved of all the responsibility of managing tokens. The client app via a reverse proxy simply proxies over any API calls to the intermediary layer and the intermediary layer can access the tokens stored in the HttpOnly cookie and make any calls to the external API sending the access tokens in the header or these calls can be to the local API within the intermediary layer itself and here too the access token will be sent in the header.

Shown below is the schematic of the BFF architecture.

Creating the backend part of the backend for frontend (BFF)

The entire source code is available here

But, I'll walk through the specific pieces we added so it is easy to see the additions we made.

Start by adding the Duende.BFF nuget package ³ to a fresh dot net core web api project.

First you have to register the BFF services with the DI container and add services required for YARP http forwarding.

builder.Services.AddBff()
    .AddRemoteApis();

Next, just as we would do with any other server side client that requires authentication, you'll add the AddAuthentication to register the
services required for authentication. Optionally, we can explicitly specify the cookie scheme where the access token will be stored.
Finally, we must register the AddOpenIdConnect handler to handle the authentication.

builder.Services.AddAuthentication(options =>
{
    options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = "oidc";
    options.DefaultSignOutScheme = "oidc";

})
.AddCookie(CookieAuthenticationDefaults.AuthenticationScheme, options =>
{
  options.Cookie.Name = "__Host-ReactSPA";
})
.AddOpenIdConnect("oidc", options =>
{
    options.Authority = identityServerConfiguration.BaseUrl.ToLower();

    options.ClientId = clientConfiguration.ClientId;
    options.ClientSecret = clientConfiguration.ClientSecret;
    options.ResponseType = "code";

    options.Scope.Add("roles");
    options.Scope.Add("subscriberSince");
    options.Scope.Add("notesapi.write");
    options.Scope.Add("notesapi.read");
    options.Scope.Add("notesapi.fullaccess");

    options.ClaimActions.Remove("aud");
    options.ClaimActions.DeleteClaim("sid");
    options.ClaimActions.DeleteClaim("idp");

    options.ClaimActions.MapJsonKey("role", "role");
    options.ClaimActions.MapJsonKey("subscriberSince", "subscriberSince");

    options.TokenValidationParameters = new TokenValidationParameters
    {
        RoleClaimType = "role",
        NameClaimType = "given_name"
    };
    options.SaveTokens = true;
    options.GetClaimsFromUserInfoEndpoint = true;
});

Next, we'll add the bff middleware by calling UseBff.

MapBffManagementEndpoints adds support for login, logout and logout notifications.

AsBffApiEndpoint adds support for local APIs. This includes anti-forgery
protection as well as suppressing login redirects on authentication failures and
instead returning 401 and 403 status codes under the appropriate circumstances.

Finally, MapRemoteBffApiEndpoint proxies any local calls to the actual remote api passing the access token.

app.UseAuthentication();
app.UseBff();
app.UseAuthorization();

app.MapControllers().AsBffApiEndpoint();

app.MapBffManagementEndpoints();

app.MapRemoteBffApiEndpoint(
        "/api/notes", "https://localhost:7094/api/Note/GetNotes")
    .RequireAccessToken(TokenType.User);

Let's now test to see if we have configured everything properly.
Set the startup projects as MakeBitByte.IDP and ReactClientAppBFF and run the solution.

Once ReactClientAppBFF starts up, call the https://localhost:7249/bff/login endpoint. This should redirect you to the
MakeBitByte.IDP login page. And once you login using say appa with password P@ssw0rd you should get redirected back
the index page.

If you open your developer tools and look at the cookies you should see the __Host-ReactSPA cookie.

If you attempt to access the https://localhost:7249/bff/user endpoint then you'll get an 401 error. If you look at the logs then you'll see the following error.

fail: Duende.Bff.Endpoints.BffMiddleware[1]
      Anti-forgery validation failed. local path: '/bff/user'

The bff middleware adds anti-forgery protection to all calls and since we didn't add the anti-forgery token "X-CSRF": '1' to the header we get this error.

Notes API with authorization

This is just a regular dot net core web api project who's endpoints are behind an IDP. In other words these require an access token.

The source code for this api is available here
It requires an access token issued by the MakeBitByte.IDP.

React client app

Finally, we'll add the frontend for the backend for frontend (BFF). This now is the react client app.

The source code for this app is available here.

I created the app with vite using the following command.

npm create vite@latest reactclientappbff -- --template react-ts

Then I added Tailwind CSS to the app using this guide.

I added react query as well as axios to the app.

npm install react-query axios

update the main.tsx to look like so

import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App.tsx";
import "./index.css";
import { QueryClient, QueryClientProvider } from "react-query";
import { BrowserRouter } from "react-router-dom";

// Create a client
const queryClient = new QueryClient();

ReactDOM.createRoot(document.getElementById("root")!).render(
  <React.StrictMode>
    {/* Provide the client to your App  */}
    <QueryClientProvider client={queryClient}>
      <BrowserRouter>
        <App />
      </BrowserRouter>
    </QueryClientProvider>
  </React.StrictMode>
);

Wrapping the App component with QueryClientProvider makes the queryClient available to all the components in the app.

We'll now create a custom useAuthUser hook. Within this hook we'll use the useQuery hook from react-query to fetch the claims from the /bff/user endpoint.

So, our custom useAuthUser hook will look like so, if you need a quick refresher on what custom hooks are or how to create them then check out this article.

import axios from "axios";
import { useEffect, useState } from "react";
import { useQuery } from "react-query";

interface AuthUser {
  given_name: string | undefined;
  family_name: string | undefined;
  email: string;
  sub: string;
  roles: string[];
  bffLogoutUrl: string;
}

const config = {
  headers: {
    "X-CSRF": "1",
  },
};

export const fetchClaims = async () => {
  const response = await axios.get("/bff/user", config);
  return response.data;
};

function useClaims() {
  const { isLoading, error, data } = useQuery("claims", fetchClaims, {
    retry: false,
  });
  return { isLoading, error, data };
}

export function useAuthUser() {
  const { isLoading, error, data } = useClaims();
  const claims = data as [{ type: string; value: string }];

  const [user, setUser] = useState<AuthUser | null>(null);

  useEffect(() => {
    if (claims) {
      const given_name =
        claims.find((c) => c.type === "given_name")?.value ?? "";
      const family_name =
        claims.find((c) => c.type === "family_name")?.value ?? "";
      const email = claims.find((c) => c.type === "email")?.value ?? "";
      const sub = claims.find((c) => c.type === "sub")?.value ?? "";
      const roles = claims.filter((c) => c.type === "role").map((c) => c.value);
      const bffLogoutUrl =
        claims.find((c) => c.type === "bff:logout_url")?.value ?? "";
      setUser({ given_name, family_name, email, sub, roles, bffLogoutUrl });
    }
  }, [claims]);
  return { isLoading, error, claims, user };
}

But how do we get to this /bff/user endpoint? We are routing to this endpoint as if this exists in our local app when in fact it exists in the ReactClientAppBFF project. This is where the reverse proxy comes in. We'll add a reverse proxy to the vite.config.ts.

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react-swc";
import basicSsl from "@vitejs/plugin-basic-ssl";
// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react(), basicSsl()],
  server: {
    proxy: {
      "/bff": {
        target: "https://localhost:7249",
        secure: false,
        configure: (proxy, _options) => {
          proxy.on("error", (err, _req, _res) => {
            console.log("proxy error", err);
          });
          proxy.on("proxyReq", (proxyReq, req, _res) => {
            console.log("Sending Request to the Target:", req.method, req.url);
          });
          proxy.on("proxyRes", (proxyRes, req, _res) => {
            console.log(
              "Received Response from the Target:",
              proxyRes.statusCode,
              req.url
            );
          });
        },
      },
      "/signin-oidc": {
        target: "https://localhost:7249",
        secure: false,
      },
      "/signout-callback-oidc": {
        target: "https://localhost:7249",
        secure: false,
      },
      "/api/notes": {
        target: "https://localhost:7249",
        secure: false,
        configure: (proxy, _options) => {
          proxy.on("error", (err, _req, _res) => {
            console.log("proxy error", err);
          });
          proxy.on("proxyReq", (proxyReq, req, _res) => {
            console.log("Sending Request to the Target:", req.method, req.url);
          });
          proxy.on("proxyRes", (proxyRes, req, _res) => {
            console.log(
              "Received Response from the Target:",
              proxyRes.statusCode,
              req.url
            );
          });
        },
      },
      "/local/identity": {
        target: "https://localhost:7249",
        secure: false,
      },
    },
  },
});

So, now all calls to /bff/user will be proxied to https://localhost:7249/bff/user.

This virtual endpoint https://localhost:7249/bff/user is added by the app.MapBffManagementEndpoints() statement in the program.cs file of the ReactClientAppBFF project. Here's the extension method's implementation.

   public static void MapBffManagementEndpoints(this IEndpointRouteBuilder endpoints)
    {
        endpoints.MapBffManagementLoginEndpoint();
        endpoints.MapBffManagementSilentLoginEndpoints();
        endpoints.MapBffManagementLogoutEndpoint();
        endpoints.MapBffManagementUserEndpoint();
        endpoints.MapBffManagementBackchannelEndpoint();
        endpoints.MapBffDiagnosticsEndpoint();
    }

All calls to the /bff/user endpoint will have the HttpOnly cookie attached to the request and the bff middleware in the ReactClientAppBFF project will be able to extract the access token from the cookie and make the call to the IDP to get the claims.
We specify that the claims must fetched from the IDP's user info endpoint in the AddOpenIdConnect handler in the ReactClientAppBFF project.

.AddOpenIdConnect("oidc", options =>
{
  // code omitted for brevity
  options.GetClaimsFromUserInfoEndpoint = true;
});

We get this httpOnly cookie in our browser from the login procedure as follows. Once we call /bff/login endpoint we get redirected to the IDP's login page. When the user is sent to the IDP's login page, the redirect_uri is set to /signin-oidc on the origin of the react app since the react app initiates the login process, so this then translates to https://localhost:5173/signin-oidc.

In the vite.config.ts where we set the proxy, you'll see that /signin-oidc is proxied to https://localhost:7249/signin-oidc.

  "/signin-oidc": {
    target: "https://localhost:7249",
    secure: false,
  },

https://localhost:7249/signin-oidc is a virtual endpoint on our ReactClientAppBFF project. Once the user has successfully
logged in, they'll be returned to this endpoint with the tokens from the IDP. And, this where the bff middleware will wrap this access token in a HttpOnly cookie and set the HttpOnly cookie on the response. And we get routed back to the index page of our react app.

This is the reason why we must add these two endpoints to the list of allowed uris in the RedirectUris in the client configuration in the IDP's Config.cs file.

RedirectUris =
{
   "https://localhost:7249/signin-oidc",
   "https://localhost:5173/signin-oidc"
}

Alright, now that we have the HttpOnly cookie, we are free to make calls to other endpoints such as /api/notes which is proxied to https://localhost:7249/api/notes.
Again, take a look at the vite.config.ts file where we set the proxy.

 "/api/notes": {
   target: "https://localhost:7249",
   secure: false,
 }

Remember, this call will have the cookie set in the header.
If you remember, our ReactClientAppBFF project has the following in the Program.cs file

app.MapRemoteBffApiEndpoint(
        "/api/notes", "https://localhost:7094/api/Note/GetNotes")
    .RequireAccessToken(TokenType.User);

This means that any calls to /api/notes on the ReactClientAppBFF project which translates to https://localhost:7249/api/notes
will now be further proxied over to https://localhost:7094/api/Note/GetNotes and the access token which is extracted from the HttpOnly cookie will be sent in the header.

And the resultant json response will be returned to the react app which is encapsulated in the custom hook useNotes shown below.

import axios from "axios";
import { useQuery } from "react-query";

const config = {
  headers: {
    "X-CSRF": "1",
  },
};

const fetchNotes = async () => {
  const response = await axios("/api/notes", config);
  return response.data;
};

const useNotes = () => {
  const { isLoading, error, data } = useQuery("notes", fetchNotes, {
    retry: false,
  });
  return { isLoading, error, data };
};

export default useNotes;

Conclusion

Caveat emptor, goes without saying that this isn't production ready just yet, so for example, you'll want to add error handling so your app fails gracefully, and the vite reverse proxy is only good for local development. In a production scenario you'll probably want to add yarp, The primary intent of this article was to explain the main concepts behind the BFF architecture while securing a react app, and though the Duende BFF middleware makes
it easy to implement the BFF architecture for securing a browser based apps, there is a fair amount of complexity under the hood and this article delves into some of those so it doesn't seem like all magic, and it always helps to know what is going on beneath the surface especially when one is attempting to debug a rather intractable problem.

Lastly, if you go here then you see a short video that explains at a very high level what happens with the BFF pattern.

See the OWASP top ten list. ↩
Check out the Securing SPAs and Blazor Applications using the BFF (Backend for Frontend) Pattern - Dominick Baier ↩
See the license terms ↩