> Users expect near-native responsiveness, even when offline
Do they? I think users are amazed if anything works without internet with modern applications.
cdaringe 1 days ago [-]
The two are not mutually exclusive!
williamcotton 1 days ago [-]
I've got a similar project that includes a React component for the search input. The React component is actually a Monaco text editor so you get syntax highlighting, error highlighting, tab completion and more.
There's an animated GIF of the demo so you can get a very quick idea of how it works!
FrustratedMonky 2 days ago [-]
Seems a lot like FSharp Type Providers? Is that a good analogy?
2 days ago [-]
gitroom 2 days ago [-]
Nice, Ive bounced around between Prisma and Kysely too. I get nervous about locking too much into one thing, you ever worry if leaning on too much codegen or magic ends up biting you down the road?
tehlike 2 days ago [-]
LINQ or PRQL.
hu3 2 days ago [-]
Looks good.
For a more database specific, type-safe, data querying solution, I like to use https://kysely.dev
damidekronik 2 days ago [-]
I am using both prisma and kysely in the same codebase with a great success. The db schema is driven by SQL, not prisma. It is then introspected by both kysely and prisma, prisma is used in 95% of the places while kysely is used whenever performance is critical or when prisma doesn't support the SQL features we need.
tough 2 days ago [-]
any underlying negative consequences on letting prisma schema handle the underlynig model/migrations
I found out about stackzen yesterday, really like the RBAC/ABAC backed up into the models/codegen stuff, been thinking about just using that for our custom logic and maybe add RLS pg a la supabase but also codegen from the same .zmodel from zenstack model that generates prisma models/migrations have it generate RLS sql migrations code
thoughts??
also maybe postgres views to handle field/attribute level security since rows is mostly about whole columns
main goal is to secure the data at all the levels of the stack from db to api to app so there's no footguns in the future where someone with a pg user or modifying our clients can see data they shouldn't etc
damidekronik 1 days ago [-]
Prisma doesn't cover plenty of SQL features. custom types, more complex indexes (like where clause). It is also a VC backed biznes, need to be ready to drop it at almost any time, SQL/postgres on the other hand is here to stay.
RLS is hard to work with, hard to debug, hard to reason about, cumbersome. It is however powerful.
tough 1 days ago [-]
Right! for RLS i found out about atlasgo, which lets you do Schemas as Code including RLS stuff,
so my mind went to leverage the .zmodel to generate not only the prisma schemas through it and the client api codegen sdk, but also the RLS stuff either with plain sql migrations or a specific framework for rls.
all in all this is probably too much and as long as the app-api level is secure with zenstack and i dont use pg directly anywhere else it should be 'safe' i just wanted to harden all the stack speaking of sorts... idk
The same should apply to configuration, we have prisma for sql, we should have something like this for JSONs, like https://typeconf.dev (I’m one of the founders)
2 days ago [-]
Rendered at 20:58:16 GMT+0000 (Coordinated Universal Time) with Vercel.
Do they? I think users are amazed if anything works without internet with modern applications.
Check it out here: https://github.com/williamcotton/search-input-query
There's an animated GIF of the demo so you can get a very quick idea of how it works!
For a more database specific, type-safe, data querying solution, I like to use https://kysely.dev
I found out about stackzen yesterday, really like the RBAC/ABAC backed up into the models/codegen stuff, been thinking about just using that for our custom logic and maybe add RLS pg a la supabase but also codegen from the same .zmodel from zenstack model that generates prisma models/migrations have it generate RLS sql migrations code
thoughts??
also maybe postgres views to handle field/attribute level security since rows is mostly about whole columns
main goal is to secure the data at all the levels of the stack from db to api to app so there's no footguns in the future where someone with a pg user or modifying our clients can see data they shouldn't etc
RLS is hard to work with, hard to debug, hard to reason about, cumbersome. It is however powerful.
so my mind went to leverage the .zmodel to generate not only the prisma schemas through it and the client api codegen sdk, but also the RLS stuff either with plain sql migrations or a specific framework for rls.
all in all this is probably too much and as long as the app-api level is secure with zenstack and i dont use pg directly anywhere else it should be 'safe' i just wanted to harden all the stack speaking of sorts... idk