Array<string> vs Record<key, true>?
So, this is a call for mental help lol. First this is a taste question, is not a necesary question and is clearly a dum question, but i wanna ask any way.
In my lastest months i been working usually in backend stuff, and primary using Prisma for schema and some queries, because is VPS not serverless, Kysely for some complex queries, and Zod for validation (DTO and others stuffs). All is good, everything work perfectly (ignoring the lack of some query functionalities in Prisma). But there is something that really BOTHER me when i read the code. For example
when picking fields in a prisma query, you do a something like this:
This kind of API is truly intuitive, feels nice. But then using Kysely is something like this:
This also feels nice, but when the query grow too much, usually when conditionals are added or too much select fields added, i feel that the kysely way it feels more verbose.
Another case is validation library like zod, i really love zod, too much hahaha.
Again, they use the Record<key, true> approach to pick/omit/required/partial objects, just like prisma does.
But then most utility libraries like lodash, or remedajs use Array<string> approach, this make me create my own libraries to have similar approach to Record<key, true> approach
So, my question is, is healthy and good that i wanna choose only one way of doing picking/omit in objects? I been building my own alternatives to Remeda or Kysely but Record<key, true> approach, what do you think? Do you like it? I'm just testing.
![No description](https://cdn.answeroverflow.com/1141611622260023386/photo_2023-08-17_01-04-59.jpg)
![No description](https://cdn.answeroverflow.com/1141611622717206628/photo_2023-08-17_01-03-33.jpg)
11 Replies
Let me clarify that in the Kysely approach, i'm not recreating Kysely from scratch, this is just a test functions and clases that wrap kysely API to give this Record<key, true> API and still work on progress. I'm not so crazy to try to rebuild kysely myself alone lol.
Seems a little obsessive to me. Could you make a wrapper around kysely that basically does things in the way prisma does and then maps it to kysely?
i don't know yet if i can do everything that kysely does, but i already did some basics stuffs, is a work on progress (like i showed in one of the pictures). My point with this question is that, it feel hugly to have differents APIs for all my cases,
Prisma -> Record based,
Zod -> Record based
Kysely -> Array of string based
Remedajs -> Array of strings based
It feels ugly to have so different APIs for this similars things in only single codebase.
One advantage of having the same kind of API in all proyect codebase, is copy and paste. This is why i love prisma and zod working together, because i can copy and paste select statements so ez. But yeah, is clearly obsessive from my part, that's why i'm asking 😂
One advantage of having the same kind of API in all proyect codebase, is copy and paste. This is why i love prisma and zod working together, because i can copy and paste select statements so ez. But yeah, is clearly obsessive from my part, that's why i'm asking 😂
I get why you don't like it, what are the use cases that prisma doesnt support? Perhaps you can find another way round it or make a PR to the library to support it
Prisma don't support aggregate functions with conditions on relations, example,
Select all clients that have an order count > 8, or sum order.total_price > 200
Would you be able to do it in seperate queries? I know thats a pain, but might be a bit easier than using kysely and rebuilding it in a prisma way XD
yeah, but is hard to make those findMany in two queries, because i would have to omit pagination for the first query and ended pulling thousand of records or more just to do another filter and then manually grouping, with Kysely is way simpler and clearly more performant, but yeah, it break the same feel of using prisma like for everyting
I could try to make PR for prisma to fix those issues, but already exist issues/proposals that suggest this in their repo from months or years and they/anybody haven't fix them, so maybe is not easy to do, maybe i'm wrong.
GitHub
Search by relation count eq | gt | lt · Issue #8935 · prisma/prisma
Problem I think the issue should be related with #3821 model Topic { id Int @id @default(autoincrement()) title String @db.MediumText content String @db.LongText voters VotersOnTopics[] watchers Wa...
a year without fixing. I really give up, excepting that the Prisma Client would be fixed in any time soon, that's why i choose Kysely, is better, more control and features, but is more verbose in my opinion, that's why i was trying that wrapper idea
Fair, you could have a go at creating that feature in the Prisma codebase, or just accept that you'll have different syntax for some queries. I've heard good things about kysely, could also just switch over to that if its better
yeah, currently i'm using both, and in this proyect i won't chage that, but i'm trying to build/PR something to fix this ''code style issue'' so in the future i could use both in similar ways or even use kysely always.