And that's something that Remix and now built to really like even couple the client side and the backend side more closely together. So with Turbostream, which is streaming HTTP, you now can pass down promises and evade the promises or defer the promises on the client and show a suspense, some kind of loading spinner while it's still being fetched on the server, right? You can see how Remix and also Next.js, for that matter, React.js components, really take one step further of building transports and protocols on top of React to really tightly couple the frontend and backend, right? So like the full stack frameworks are even becoming more tailored in that way. I mentioned React Server Components, right? React Server Components is its own protocol that has its own payloads that it's sending to the client that is also not just regular JSON, but something that React on the client understands to understand how to handle different use cases when it comes to React Server Components. And here I have to mention BFF. BFF obviously is a very old pattern that has nothing to do with React Server Components or Remix, but it's a pattern where you say one frontend should have one dedicated server that takes all its requests and handles them in a very specific matter for that frontend and abstracts away all the other backend and downstream databases, microservices, and whatever craziness is within your corporation and company. So the BFF pattern comes from this microservice world landscape, but we can definitely say that Next.js and Remix are implementing the BFF pattern, right? So if you're deploying a Next.js application, it is a full stack app that serves a client, and then for that client, the Next.js backend is implementing or is a specific backend for the Next.js frontend. That kind of makes it the frontend's best friend. Cool. So all of this is, I guess, table stakes. I mean, React Server Components is still very new and we're all trying to figure it out. And obviously, Remix, aka React Router and Next.js are still changing, right? So like TurboStream is a very newer-ish change in Remix. It was JSON before, but still I think most people have accepted that the DX, or full stack web frameworks, is amazing, and it's a really great way to ship fast when you want to build for the web. But that's also just where things start, right? Like even if you have a great full stack web framework already in production, so say I have a new side project, I'm starting with Remix, right? Then a lot of the adventure still just starts, right? We still have to think about the requirements of our application, what we want to actually play, do we want to have offline support, multiplayer features, right? Like should it feel native? There's a lot of expectations for applications in 2025, right? So our job isn't done. If anything, it's just getting started. And this is kind of the state where I was in with my side project. This time I decided to go with Next.js. I generated the first prototype with V0, and V0 is just so good at building Next.js sites, and I wanted to try React Server Components. And then Chatsy, and Tavern, right? So like, I have this really cool stack, and I'm iterating on my project. It's all just crud in the end of the day. Really happy though. And then MCP comes around the corner, and I get confused. Am I still building the right thing? So what is MCP? MCP is the Model Context Protocol, and it enables large language models, LLMs, to integrate with third party services and tools. So if you have some kind of chat interface that is connected with a large language model, we call that an MCP client in the MCP protocol. So let's say Cloud Desktop or Cursor can be our MCP client. And then we're connecting, or want to connect that chat interface with a lot of different third party services. And those services can provide the LLM this context, but also provide tools that the LLM can execute. So let's, for instance, let's say we have a to-do MCP server, right? So in the chat, we can say, I'm working on refactoring the thing, please write me a to-do. Or like, hey, cursor, what are my to-do's for the day, right? You immediately see how integrating all these services kind of makes the chat interface more powerful, right? Like in the end of the day, you want to connect it with all your tools. What I'm showcasing here is just like some examples, right? Like say there's a Slack MCP, an email MCP. What I mean by that is that every service you want to utilize kind of should expose their own MCP server.
Comments