Successfully reported this slideshow.
You’ve unlocked unlimited downloads on SlideShare!
Good evening everyone, my name is Nico. I’m here to talk about how we at Vin65 used YAML’s to build our new reporting engine. Sorry about the bad image, there aren’t any good memes for YAML’s unfortunately.
Vin65 is a Wine eCommerce platform with features and products for Point of Sale, Wine Club management, compliance, etc. And our motto is: [SWITCH]
Which we’ve been doing pretty well on.We’ve been selling a lot of wine for a lot of wineries to a lot of people. And as a consequence, we’ve also been producing a lot of… anyone?
A lot of data. And we get that data to our customers using reports. Wineries use these reports for everything from figuring out their best sales person, which club has the most members, or which bottles are running low.As a result, we had a lot of kinds of reports. More than 60 actually.
Which brings us to the challenge we were facing 6 months ago:
Our original product, though fully performant, was reaching the limits of its extendability. It’s a monster of a monolith, and as is currently the rage - in need of some microservicing As mentioned, we needed to convert literally dozens of reports All of which needed to be accurate .. because of course what use is data unless it’s correct And while all of this happening, we also needed to build new features that would work on all of these reports.. Like scheduling and background processing Finally, we needed to do this with a relatively young team which, while composed of talented and motivated devs, were still learning Ruby and Rails
And what we came up with was:
This is not a presentation about best practices per se and I wholly acknowledge that there are numerous other ways of skinning this particular cat. What this approach did provide was a way for a team with disparate levels of Ruby and/or Rails expertise to churn out a lot of reports.
So in cW@: Vin65 accepts no responsibility for any bugs, injuries, dismemberments and/or deaths that occur from using this presentation as an architecture guide.
- Transition into a micro-service based architecture
- Port literally dozens of reports
- Which all needed to be accurate
- ..while building new features that should work on all of them
- ..with no abundance of developer bandwidth