Robbin Chen
Posted on
Hey , this is brand new library to access database
For further actions, you may consider blocking this person and/or reporting abuse
Posted on
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (1)
Building your own DB-access library is a great learning project, and the design question that decides whether it's pleasant to use is where you sit on the abstraction spectrum: a thin query-builder (you write close to SQL, full control, minimal magic) vs a full ORM (objects, relations, migrations, but you fight the abstraction on anything complex). Most of the pain people have with data layers is libraries that pick the heavy end and then leak - the 90% is lovely and the 10% (a gnarly join, a window function) forces you to drop to raw SQL anyway, so the abstraction added ceremony without removing the hard case. The libraries that age well keep an escape hatch to raw SQL as a first-class feature, not an afterthought.
The thing I'd build in early since it's a data library: SQL-injection safety by construction (parameterized by default, hard to misuse) - that's the boring-but-critical part where a footgun is catastrophic, and it should be the default, not a thing the user remembers. That "make the safe path the default" instinct is core to how I think about generated code in Moonshift, the thing I work on (a multi-agent pipeline that takes a prompt to a deployed SaaS) - secure-by-default, because relying on remembering is how vulnerabilities ship. Multi-model routing keeps a build ~$3 flat, first run free no card. Cool to see a new entrant. Where does it sit - thin query-builder or full ORM, and is there a clean raw-SQL escape hatch? That escape hatch is what I'd check first.