Some time has passed after my last post and despite my solemn vow to blog more, that didn’t happen. That’s because I’ve been a busy bee and, again, too preoccupied with other stuff to write anything meaningful. The search for a new interesting job was - luckily - very short and left me in the company of the great guys at evopark. There I’m now responsible for the architecture, implementation and related sys-ops of their IT infrastructure. It’s loads of fun and I can finally work with Ruby On Rails full-time again.
And if there’s one thing to take away from the last couple of weeks, it’s that
the development process with Rails has become even more awesome since its
The surrounding ecosystem is huge, there are loads of stable, well-tested and documented gems to quickly develop complex, yet maintainable applications.
But there’s one subject that’s still… suboptimal: creating PDF reports. There are a couple of approaches that can roughly be divided into two categories: wkhtmltopdf and Prawn. Yet, when compared to mature reporting solutions from the Java world, like BIRT and JasperReports they all seem woefully inadequate.
What I want in a reporting engine is:
- Report-designer GUI so that non-developers can design and adapt reports
- Control over page breaks (not that easy when going via HTML)
- High-quality PDF output with font-embedding and optional PDF/A support
So my solution was to create a micro-service based on JavaXT HTTP Server and the JasperReports library. The Rails application creates a JSON representation of the report data and sends a HTTP request to the Report Server. The report server then generates the PDF, optionally overlaying it onto onto another letterhead PDF and making sure that it’s PDF/A compatible in a few lines of code using the fabulous iText library. And everything in less than 650 lines of code (plus a couple of integration tests).
So, it turned out that reporting in Rails is still best done in Java. Not that optimal but I’m sure we’ll get there eventually.