Chad Burggraf from Assetbots, graciously agreed to do a Q&A with us about how Replicache has helped him deliver a high-quality UX as a one-person startup.
Hi Aaron! Assetbots is a tool that helps businesses keep track of their valuable equipment — think computers, tools, or vehicles. You can maintain records of everything you have, and what happens to it over time. For example, who it’s assigned to, when it’s repaired, and how it depreciates. Kind of like a CMS but for stuff instead of people.
Yep!
I’m able to deliver an incredible user experience as a one-person operation. Here’s a quote that I just received yesterday that wouldn’t have been possible without Replicache: “This looks genuinely amazing … like a mix of Notion and Docusaurus.”
Right. During demos, my customers love the offline capabilities. But when users are driving the product themselves, they fall in love with the way it feels. Nothing in my space comes close to matching the feel and speed Assetbots offers. There is no way I could have made as good of a product by myself without Replicache.
I was thinking about working offline because I noticed the lack of offline support was a recurring complaint about competitor products. I’ve never built an offline-capable web application, but I had experience doing it for mobile and remembered how difficult it was, even for a medium-sized and capable development team.
My first pass used Lovefield, which is a SQL abstraction layer on top of IndexedDB. This worked okay for my offline use-case, but I never really fell in love with the architecture that started to surface in my app.
I stumbled on Replicache, and realized that I should be getting real-time updates (a.k.a., multiplayer) for free if I’m going to build for offline anyway. That’s because once you commit to an offline architecture, you’re going to be merging changes in one way or another, and distributing those changes among clients is the easy part. The Replicache design fit my mental model, so I went with it.
Assetbots is mostly a Single Page Application using React on the client and .NET 6 on the server. Like a lot of “spreadsheet” SaaS applications, it’s basically a nice UI on a set of lists.
On the client, Replicache acts as my source of truth. In other words, it replaces Redux. I have a React context provider that sits near the root of my app tree, and from that you can get an object that gives you access to the global data store. It ends up feeling like a cross between React Query and Redux, for those familiar with React apps. That’s because Replicache is async, so data access and manipulation needs to be turned into reactive state rather than done directly.
An interesting side effect of accessing all your data async is that you can do things that would be hard in a traditional Redux context. For example, I provide full text search on most of our data. Moving full text indexing and the Replicache data store into a Web Worker doesn’t change the API surface for my components at all, which is cool.
Yeah, the fact that Replicache works in Workers is key here. I use the Fuse.js library and store its indexes in IndexedDB (separate from Replicache), but use APIs from Replicache to keep the text index in sync with primary data.
On the server, Assetbots is a standard .NET/SQLServer app. For real-time updates, I’m using SignalR, which is the standard in the .NET world. Assetbots is built this way because my stack already existed from a previous endeavor, and I just kept building Assetbots on top of it. Replicache required a relatively tiny amount of architectural work for the benefits it brought.
It’s been great! I’m typically very conservative with my technology choices. I tend to wait for the “winner” to emerge in a space before wading in. I remember going out for oysters with my wife and talking to her about this technology I found that might enable me to build an experience that is typically only delivered by best-in-class apps with tons of resources. We talked about the risks but quickly realized that my excitement and enthusiasm were going to make the decision for us.
Of course, there are some growing pains. I’ve had to run a fork periodically to work around browser issues (thanks, Safari). Async is not a first-class citizen in React right now, so there is more boilerplate around error handling and loading states than there will be when Suspense for data fetching is standardized.
I can picture ways to make most of the projects I've built in my career work with Replicache. But the best matches are projects where interactivity is important, and where the data set can be easily partitioned. So, collaborative editing, games, etc.
Assetbots is a traditional SaaS with a very relational data model. This kind of app requires a little more thought but is clearly do-able, as long as the dataset can be partitioned in such a way that it can be synced to the client in reasonable (<100MB) chunks.
I think I would struggle with how to implement Replicache with very large data sets (for example, if Assetbots had a customer that wanted to track 1M assets), or graph-like data models for e.g., a social network. Of course, you could solve those problems, but the benefits might not be worth it. One of the key benefits of Replicache is having all your data available on the client. This alone unlocks so much that developers should think about architecting their data model to make it feasible.
Thanks for building a great tool! As with any tech I rely on, my main concerns moving forward revolve around roadmap, stability and pricing. So as much clarity as often as possible in those areas would be great.