Following some great people on Twitter I’ve often seen people search for, and also searched for myself, examples of real world Blazor apps. They still seem quite hard to find and I thought we could do our part and let you know of our own app being based on Blazor.
Oxceed is a decently sized real world SaaS web app for financial performance management. It connects, and keeps updated, seamlessly with clients accounting systems and lets you monitor real-time how your company is doing. Onboarding is simple and you get a smorgasbord of reports, key performance indicators and other assets ready for consumption in minutes. Budgets & forecasts are easily crafted, and you may customize most elements to suit your own specific needs.
We have been in business for 6 years and was originally built on ASP.Net MVC 5, with quite a lot of JavaScript to help in user experience. Blazor caught our interest about 2 years ago as there seemed to be a lot of good stuff we could use (we all have .Net backgrounds), not only to make our user experience better (more SPA:ish), but also improve developer productivity and lessen the workload on the backend. So, January 2020 we decided to port the MVC app over to Blazor.
Oxceed has been running the Blazor app in production since January 2021 and we see great benefits in all areas we expected. New features are built quicker than before, the component architecture is solid, developers happier by working on the latest and greatest stack and we can even see improved backend resource consumption. The client app runs on WebAssembly and our internal administration app runs Blazor on the server.
The way we approached the porting was to start off from File – New project and for the first few months we dealt a lot with nailing the basics such as how we lay out the code into projects, routing, what goes into pages vs. components, authentication, theming, localization and more.
Once started and having gotten a grip on how we would compose the Blazor implementation it has been amazing to see the benefits the framework provides. For example, we render many types of financial reports and by breaking it down into reusable components it gets easy to implement new report types, one by one.
Another example is the ease with which we may use a component in multiple places to make the user experience intuitive. A popular feature in Oxceed is dashboards, you may assign a dashboard to a company from either the dashboard design area, subscription settings or simply when visiting a dashboard, all using the same component for dashboard assignment.
What about challenges, weren’t there any? Oh yes, but we tend to look at them from a positive perspective and we think we have gained good experience and understanding of Blazor, which is very important for us to keep improving Oxceed and stay relevant and competitive.
Some challenges we had:
– On a large app, make sure you have a good state handling setup early. We started by keeping a bit of the MVC state implementation and gradually threw away piece by piece when we most possibly would have had less refactoring if we had just thrown it all out from the start.
– Read up on, and test in detail how component disposal and component life cycle events work. We did not get it early enough and ran into hard to repro bugs spending much time understanding the causes and the fixes.
– Components are awesome. However, performance may be impacted when going to deep in componentizing your pages. In our case we saw issues in rendering speed improve a lot by removing some levels of component nesting.
– Security is important, very important, pay attention when building your client app API:s.
– Cancellation tokens, you should use them. We did not, until real users started navigating quicker than API responded.
– The initial download is big, yes, but has not been a concern among customers.
Torulf Lundgren, CTO and co-founder, Oxceed
Take a look at our demo videos below to get a glimpse of what Oxceed looks like from the inside.
