Three months ago, my close friend and colleague @mikependon pitched-in the idea of creating our own Object/Relational Mapping tool. Our ORM is a core component of our services could be a costly adventure to change, I immediately sense the risks there. Yes, I am skeptical but I also don’t want to immediately scrap this innovative idea.
Fast forward… In past 2-weeks, me and Mike we’re pairing to make the first stable release of RepoDB; the ORM tool we have just debated. I thought it would be interesting to share an opinion piece that I have written in response to his pitch :)
Would you build another ORM framework?
– begin message 02-Apr-2018–
7:00 AM and it’s holiday in DK so I took time to discern this and I guess you will remember me for what I have to say.
I thought what we have here is what the entire Dapper community has tried to build and mature over the years. One of my primary concerns with these internal APIs is continuity and maintenability. Over the years, I have seen so many internal APIs that has been built but fail to sustain when developer leaves the project or the company. Using something with large community base makes the API at least future-proof. Also, the time for next developer to understand the new API is just as much as re-writing it. So the next super-developer would rather pick-up from github and replace this or write his own. And the wheel goes on…
Now, let’s look at the problem statement and solution alternatives: Missing feature(s) from our existing ORM. If a feature is lacking we can try to find alternatives this way and re-writing would be our last option. We can:
Option 1: Fork-out existing library and improve it. This way we can have our own build, have it reviewed and committed. In Github our fork lives on until it’s pulled, reviewed and accepted by community of code reviewers.
Option 2: Create a library on top of existing one as dependency. This the Contrib project. We have done this in supporting BulkInsert via SqlBulkCopy in our API.
Option 3: Find alternative libraries that better fit. EFCore or PetaPoco maybe? PetaPoco supports Expando. EFCore took out what we hate from EF.
Option 4: Re-write everything and build something ourselves. We need as much test coverage and use cases.
Is this an case “Reiventing the wheel” or “Not Invented Here” (NIH)? And is re-inventing the wheel bad?
Well…When Jeff Atwood thought we need better Q&A for developers, he built his own different from Yahoo Answers or1 Quora. We now known this as stackoverflow.com. Interestingly, same group thought EF is too heavyweight, so they built Dapper.Net :)
Meanwhile, someone thought Notepad and Paint is not enough so they built Notepad2 and Paint.NET. So far large users still would prefer Notepad and Paint.
LinkedIn developed Kafka because their existing streaming platform is limiting their ability to scale out. So far, Kafka is now the preferred data platform for high throughput messaging systems.
From here, we can see at least two motivations to re-invent. First, when we cannot extend existing solutions (due to commercial constraints, company policies & complexity). Second, when existing solutions are clearly deficient or insuficient.
Where does RepoDB fit? Would you re-write to solve an (8+2) problem? Where 2 is what’s just missing from existing?
P.S. some old piece from my idol, Joel Spolsky
– end of message –