4 ms·
That's interesting. I use Knex a lot and I agree that it's very easy to end up just writing what is basically an ORM on the spot. I haven't quite decided if I t
by kristiandupont 4y ago
That's interesting. I use Knex a lot and I agree that it's very easy to end up just writing what is basically an ORM on the spot. I haven't quite decided if I think it's a real problem though.
I created and use Kanel ([link redacted]) to generate Typescript types from my Postgres database which helps a lot. Knex itself has some attempt at type safety but it gets confused quite quickly, so that's where it's tempting to override things.
- sally_glance 4y agoI'm currently observing the same with a client, also using Knex with Typescript. They're trying to work with the Knex-provided types, and built a (currently still small) set of functions for shared logic like wrapping into a transaction. Those require a non-trivial amount of type-juggling and I'm not sure yet whether I like it. I've seen both plain SQL and ORMs in larger code bases, choosing between those and the "query builder with some custom abstractions" is hard. Compared to plain SQL, the obvious advantage is that you don't have to work with string replacements, but a bit of readability/maintainability is lost because of emerging complexity. Compared to an ORM there is much less working around it's quirks, but also the danger of re-inventing a good part of it. Btw they also wrote up a sizeable number of record types, Kanel looks interesting for auto-generating those - thanks!
- gmac 4y agoCheck out Zapatos too: https://jawj.github.io/zapatos/ https://jawj.github.io/zapatos/
- sally_glance 4y agoThanks, we will!
- seer 4y agoI really hope the community converges on just one common solution to this as I see soo many different approaches to the same “there’s no great modular ORM for typescript” problem. I myself went the route of “lets just have raw sql queries” but extract distinct and specific types from them automatically- https://github.com/ivank/potygen https://github.com/ivank/potygen Great thing is that it handles sql of any complexity - CTEs, views, nested selects/joins/unions/custom functions you name it. All tools you can use to encapsulate logic in sql itself (what ORM were supposed to be for) and then have it be statically validated at compile time thus saving you the need for righting all those trivial unit tests that was also one of the key benefits of ORMs. Admittedly if there was something like LINQ I would probably not have ventured into building potygen, but I’m glad I did as I learned so much about SQL as a language and what it had to offer - its silly how much logic I used to rely on writing in code that could easily be handled by sql in a much mode concise way.
- kristiandupont 4y agoThat looks very neat! I use libpg_query to parse view definitions to create type information from there, but it's quite basic so far. Are you doing something similar, or did you implement the parser from scratch?
- seer 4y agoI started the project mostly as a way to play around recursive decent parsers, and then it actually turned into a useful tool. So yeah its all pure JS, and not produced from a parser generator.
- kristiandupont 4y agoThat's impressive! I will try to see if and how I can incorporate your tool into my workflow.
- sally_glance 4y agoLooks nice and I appreciate the README - those comparison tables are much more elaborate than my sibling comment, though looking at the single con in the table for potygen itself does make me wonder if they might be a little biased ;-)
- gmac 4y agoWould it be fair to say that Kanel is similar to half of my library Zapatos, which generates TS types from Postgres, but then also gives you some simple tools to use them in querying the database? https://jawj.github.io/zapatos/ https://jawj.github.io/zapatos/
- kristiandupont 4y agoThey do indeed look very similar, yes!