Rivenris
Explore posts from serversTTCTheo's Typesafe Cult
•Created by Rivenris on 1/12/2025 in #questions
What are you all looking for in typesafety of storage library?
So I am working on an SDK for a headless CMS API. The idea is that you are setting up data structures on dashboard, and then you can use them in your TS/JS project with an SDK library.
I drafted an idea of a library, that works like this:
- Typing is not required, you can use the SDK without your data types
- Once types are generated with your API key, they are saved into single d.ts file, that can be referenced both in JS and in TS. Depending on your workflow, you can add it to git, or generate dynamically on localhosts/during CI.
- No code changes (apart type referencing) is needed to add/remove types from the project
I wanted to know, what are you all most focused on when looking for types from ORM/API SDK?
So far I landed on the following benefits of what I made:
- Easy code writing with autocomplete
- Ability to dynamically influence data types based on request made (e.g. when related objects are joined within the response based on param)
- Ability to fix whatever the typegen messed up - you have your d.ts file and cann add/remove from it as you wish.
- Type safety (duh) - you will be yelled at if you use something that doesn't exist, or if anyone changes data structure on the production project space.
What are other benefits any of you is looking for from ORM/dynamic data SDK? I'm kinda fishing for an ideas, that will improve the library further and improve DX.
Just for a context: Up to this point the product used OpenAPI schema with openapi schema generator. I hated the idea, because there are no generators to support all the intricacies of the OpenAPI/JSON schema (e.g. joining related data with a param). I hated the overall DX of working with this kind of generated code, so I drafted a prototype of something custom made, that will be smaller, faster and easier to use. And yeah, I am omitting the product/the library deliberately - I'll be happy to share the results later on on showcase room, but for now, I prefer to get some independent ideas first.
2 replies
DTDrizzle Team
•Created by Rivenris on 9/26/2024 in #help
Supporting multiple engines in one app that uses db migrations
Hi,
I am mid-execution of my project which I'd like to release as Open Source. With this in mind, I want users to be able to choose their db - e.g. use SQLite on Cloudflare, postgres on Kubernetes deployments etc.
This leads me to the following assumptions:
1. The application must be able to update both schema and data safely between versions - for this schema migrations sound great, but...
2. Whoever deploys the app must be able to run the app with the chosen DB engine.
3. Switching between DB engines would require running a custom migration tool.
4. Switching DB will not happen on runtime, so the app doesn't have to load different Drizzle context
Can Drizzle support such a scenario? I imagine on each release I'd have to have separate migrations per supported dialect - that's not fun, but I'm willing to accept this as a development cost. But can I have one schema used with different configs (I imagine some schema parts would have to have minor changes between engines)? Did anyone do something similar? What tips would you have for this workflow not to become a pain for long-term development? For example, would there be an easy way to generate migrations for multiple engines with one command? Or can the studio work on multiple connections based on one schema?
I'm experienced developer, so I'm not afraid of getting things done with CI and my automation scripts, but I've not yet had a chance of working with Drizzle, so I'm looking for good tips before I start writing any kind of code around.
1 replies