Hacker News new | ask | show | jobs
by StackOverlord 1033 days ago
You will be the judge.

I was tasked of enabling us to backtrack on our decision of building a microservice rather than a library. The service was using postgres, and was connected to multiple website, one of which was targeted to use the service as a library. The challenge lied in the fact we used JSON to store some metadata as a shallow tree of depth 2-3, and the targeted website used mysql (which did not support JSON data at the time). Concretely it required to introduce edits in more than 300 files and manually take care of parsing a couple datetimes. Maybe there were other gotchas I have forgotten but it was hard enough with respect to the test suite I decided to write an ORM adapter to add support for json in mysql (dump it as a string, retrieve it, parse the string as native datastructures, walk the tree to convert datetime strings). I know this sounds crude, but it was enough for these tiny JSON data we only looked at when investigating problems at the command line. I took the steps to isolate this adapter as an independent library so that we could take the same decision of transforming the microservice as a library dependency on other websites we maintained ... basically at the cost of adding a library dependency in the project config.

After a code review that astutely pointed out my adapter ran at every loading of an object from the database (which I corrected by running it lazily upon accessing specific fields), it was decided my code was a gas factory and the CTO proceeded to do the right thing, get rid of that perky – but working and ready to go in production ! – library (took me 2 days to write) and just update the damn code. 3 days later he still wasn't finished with the 300 files edits, and he ended up abandoning and splitting the library in two. One would be used by the microservice, and the other as a library on the website. He traded treewalking our datastructures with treewalking our codebases, program efficiency with programmers efficiency (we were 15 on the team while our competitors had 50 devs). This way any modification brought to that service/library: - is not transferred to the other version, leading to organizational complexity - is transferred and the time it takes to dev a features is multiplied by a number between 1 and 2. - or there are complex surprises under the surface and this factor is greater than 2.