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.
0 Replies