ai VS nitro

The Vercel AI SDK is built for OpenAI APIs and includes a range of tools for utilizing OpenAI APIs.

The AI is calling a function (https://platform.openai.com/docs/guides/function-calling) that is mapped to developer-controlled logic. The easiest thing to do is render specific UIs for every function call, but you can render however you'd like.

We kept the code snippets in the blog post brief, but you can see the full code for the demo here: https://github.com/vercel/ai/tree/main/examples/next-ai-rsc

In this blog post, we'll build a Next.js chatbot that runs on your computer. We'll use Ollama to serve the OpenHermes 2.5 Mistral LLM (large language model) locally, the Vercel AI SDK to handle stream forwarding and rendering, and ModelFusion to integrate Ollama with the Vercel AI SDK. The chatbot will be able to generate responses to user messages in real-time.

I recently set up the Next-Langchain-starter from Vercel, and it is phenomenal: Easy to setup, easy to modify. So far I've only done a few modifications:

Vercel AI SDK Playground Documentation

I used infrastructure as code (IaC) to provision and deploy Vercel's next-openai example. IaC is useful because it applies the same rigor of application code development to infrastructure provisioning. Instead of manual point and click in a cloud console which can be unrepeatable or error-prone, you just store and change all infrastructure configurations as code in source control .

You can use LLM providers other than hugging face such as Anthropic, Langchain adn OpenAI as well. Follow this doc to change the route handler(/api/chat/route.ts) and refer to the section of your chosen LLM provider.

**References: If you got stuck anywhere feel free to reach out. The Vercel documentation is excellent and the Github repo is also easily clonable if you don't have time to code from the start and just want to get stuck in customising.

Nitro is a nice https webserver that you can deploy everywhere. Comparing it to express, it doesn't need weird middlewares for json, it has a simple way to support caching, a file system router, tasks and scheduled tasks that avoid quite a few shell scripts, db:migrations etc, plugins, KV storages, SQL connectors, websockets...

Vinxi is really a kind of Meta-Router / Router Manager (built on the dev-server and bundler-toolkit Vite and the http-server Nitro). Vinxi uses various routers of your choosing as a core primitive, and allows you to compose them in a centralized config so that they work together. Be it server or client routers.

Analog allows you to deploy anywhere, literally. It uses Nitro toolkit which has options for anything while working with Vite.

For additional reading, please explore the Nitro docs at: https://nitro.unjs.io

Not to be confused with https://nitro.unjs.io the server tech behind Nuxt and SolidStart

Nuxt is powered by an internal server called Nitro. You can see its manifestation in the terminal console right after you start your local dev server:

Until it support websocket, I think it is simply a no.

https://github.com/unjs/nitro/issues/678

It's 2023 and there is a web framework that "can't" handle websocket at all. (Not even just proxying and doing nothing else.) Feels like a joke to me.

Last week, my first actual contribution into a public open source project has been merged. Its actually only a small changes into Unstorage library, which is used by Nitros server engine, which in turn used by the popular NuxtJs framework. At the time, I was stuck in one of my side project which used Nuxt because Unstorage is lacking some functionalities that I need. However because Unstorage is 2 layers deep in the dependency tree, its not trivial for me to change the code there.