Thoughts on Using Remix for Data-Focused Applications

[ThiamLee]

I’ve been exploring different approaches for building web applications that work with data-heavy workflows, and I recently came across Remix as an interesting option.

What I like about Remix is its focus on server-side data loading, forms, and handling application state without requiring everything to be managed on the client side. It seems like this approach could be useful for applications where users frequently interact with data.

I’m curious about how others approach this kind of setup.

For those who have worked with Remix or similar frameworks:

• How has your experience been with data fetching and server-side logic?
• Do you find the approach easier to maintain as an application grows?
• Are there any challenges you’ve faced when connecting a Remix application with data platforms or APIs?

Would be interested to hear different experiences and opinions

[balajij8]

@ThiamLee 

Remix is a solid framework with well designed server side loaders and action patterns but it generally isn't currently a standard option for Databricks Apps. When connecting a standalone framework to Databricks, the main overhead usually lies in manually implementing workspace authentication, token handling and SDK lifecycle management compared to the native toolchain.

AppKit is one of the intended route if you need a React and TypeScript architecture tailored to the platform. It provides the native SDK with built in OAuth, connectivity to SQL warehouses and native access to other features. If you are well versed in Python first data applications and doing light internal tooling and dashboards, you can consider Streamlit, Dash and Gradio as they are the standard choices. Flask and Fast API offer granular control for custom microservices. Reflex is also worth looking at since it generally transpiles to a TypeScript and React frontend under the hood but worth validating it fully.

The main advantage of the other supported frameworks is the tight integration with the broader workspace architecture. When hosted as Databricks Apps, they manage authentication and integrate directly with Unity Catalog governance seamlessly. You can generally query the tables through SQL warehouses or Lakebase without requiring external network plumbing or custom reverse proxies.

[srini_ve]

@ThiamLee 

I’ve actually worked on a similar use case in one of my projects, where we used:

React → FastAPI → Databricks SQL → Unity Catalog (Delta tables)

From my experience, this worked quite well for a data-heavy application. React handled the UI, FastAPI took care of the application/business logic and APIs, and Databricks SQL provided access to the data in Unity Catalog.

What I liked about this approach was that the frontend didn’t need to deal directly with the Databricks data layer. It also gave us a clear separation between the application and data layers.

That’s why I find the Remix approach interesting as well. The server-side data loading and form handling could make things simpler for certain types of applications.

I think the choice really depends on how complex the application is expected to become. For a simpler application, having more of the server-side logic within Remix could be quite convenient. For applications that need more APIs, business logic, or integrations with other services, I’ve found having a separate FastAPI layer gives us more flexibility.

For data-heavy applications, I think one of the important things is making sure the UI isn’t directly doing expensive queries against large datasets and keeping a clean separation between the application and data layers.

I’d be interested to hear from others who have used Remix, particularly how it has worked for them with data-heavy applications.