Andre Landgraf

Most software projects fail, but shipping fast improves your chances of success. That’s why focusing on iteration velocity is so important and you should design your application architecture accordingly. Full stack frameworks like Next and Remix give you full control over the web experience with access to a dedicated web server. With Next and Remix, you expose custom endpoints for your UI (server actions, Remix actions and loaders) and use special-purpose payloads (e.g., via RSC or turbo-stream) tailored for the web frontend. But what if you need to add another frontend to your project? With LLM applications growing in popularity and the Model Context Protocol (MCP) gaining adoption, it’s becoming more likely that you’ll need to serve both third-party LLM applications and your existing frontend app. How can we best serve LLM apps with our existing full stack architecture? Let’s talk Backend for Frontend, full stack app architectures, and MCP!

Remix provides amazing flexibility and can be deployed anywhere where JavaScript is running. But how does Remix fit into the bigger application landscape of an organization? Remix provides great utility, but how to best take advantage of it? What things should be handled inside of Remix, and what things are better off done elsewhere? Should we use the express adapter to add a WebSocket server or should that be a standalone microservice? How will enterprise organizations integrate Remix into their current stacks? Let’s talk architecture patterns! In this talk, I want to share my thoughts about how to best integrate Remix into a greater (enterprise) stack.