ts-simple-type
openapi-typescript-codegen
ts-simple-type | openapi-typescript-codegen | |
---|---|---|
3 | 9 | |
35 | 2,655 | |
- | - | |
0.0 | 9.6 | |
about 1 year ago | 8 days ago | |
TypeScript | TypeScript | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
ts-simple-type
-
tRPC – Move Fast and Break Nothing. End-to-end typesafe APIs made easy
We use an internal validator library that we infer request types from. It’s similar to Zod (but also predates it by a year).
I’ve also spent some time on a Typescript type to X compiler. My first prototype is open source and targets Thrift, Proto3, Python, and JSON schema: https://github.com/justjake/ts-simple-type/tree/main/src/com...
I’m not happy with the design decision in that codebase to try to “simplify” Typescript types before compiling, and probably won’t continue that implementation, but we have a few internal code generators that consume TS types and output test data builders and model clases we use in production.
- Ezno
-
Ultra-minimal JSON schemas with TypeScript inference
After some frustration with the TypeScript schema library ecosystem, I've decided that I'd prefer to declare my types using TypeScript's excellent type syntax, so I can take advantage of generics, mapped types, etc. Then, I'll take those TypeScript types and compile them to whatever alternative schema format I need.
There are many libraries that claim to convert your Typescript types to other formats, such as ts-json-schema-generator, ts-to-zod, or typeconv/core-types-ts. These libraries work by interpreting the Typescript AST, essentially re-implementing a bare-bones type system from scratch. Most do not support advanced Typescript features like generic application, mapped types, or string literal types. So, what's the point? To avoid those limitations, I use Typescript's first-party ts.TypeChecker API to analyze types, and an existing library called ts-simple-type (which I've forked) to convert from ts.Type to a more usable intermediate format. Then, I recurse over the intermediate format and emit "AST nodes". It's pretty simple, but seems promising.
So far, I have compilers from TypeScript type to Python 3 and Thrift. But I plan to add OpenAPI/JSONSchema, Protobuf (Proto3), Kotlin, Swift, and maybe Zod and Avro. Each target language is around ~300 LoC so they're pretty easy to put together.
Repo: https://github.com/justjake/ts-simple-type
Compiler input and output: https://github.com/justjake/ts-simple-type/blob/jake--compil...
Thrift compiler: https://github.com/justjake/ts-simple-type/blob/jake--compil...
Python compiler: https://github.com/justjake/ts-simple-type/blob/jake--compil...
openapi-typescript-codegen
-
Django 5.0 Is Released
I’d also add that if you use Typescript with an OpenAPI client generator (https://github.com/ferdikoomen/openapi-typescript-codegen) it can immensely alleviate some of the biggest pain points of seperate backend and front-end. It always used to be a major pain in the ass with the amount of overhead an API change would incur - updating documentation, postman, constant communication between backend and front-end devs, etc. Now I just npm run generate, I see new API changes in my Git client and Typescript errors for code that needs updating.
Also, using a library like Tanstack Query or Rdtk Query can almost completely eliminate manual state management, and kinda makes the whole development experience feel almost like SSR.
-
Ask HN: What would you use to build a mostly CRUD back end today?
I have been in love with Loopback.io since v2 even though it was a bit of a rollercoaster.. Loopback v4 is a beautiful library. Its been around longer than nestjs but that's the easiest thing to compare it too. I recently have been creating lb4 servers that interface nextjs and react native clients. Initially, I identify my entities and use cases that I want to build. I then use the lb4 cli to auto generate models, relations, controllers, datasources, interceptors (add logic on methods/classes). I can start testing them with the OpenAPI explorer. With the openapi-typescript-codegen library I can generate services from my lb4 OpenAPI spec that I can use on the client side. From there, you can really query data easily with the loopback filter (which can be used on the client too). I initially started doing this with angular1/2+ but its been pleasant using many clients. Even though I have been leveraging it for years in production, I am still learning and exploring. There are many other awesome things I can expand on or explain if you are interested!
https://loopback.io/doc/en/lb4/
https://github.com/ferdikoomen/openapi-typescript-codegen/tr...
-
tRPC – Move Fast and Break Nothing. End-to-end typesafe APIs made easy
In our current project with a TS frontend and Python backend, we use an OpenAPI schema as the source of truth and openapi-typescript-codegen [0] to interface with it on the client side. While not perfect, it provides a very nice interface to our API with request/response typings.
I also wrote a 10-line mock API wrapper that you can call as mockApi((request) => response), and it will type-check that your mock function implements the API correctly.
[0]: https://github.com/ferdikoomen/openapi-typescript-codegen
-
Is it possible to create a dynamic type/interface from API response
Second step is to generate typescript types from the backend's spec. You can use a library like this.
- Voi va generați modele automat pe FE?
-
A minimalist backend REST API in NodeJS
openapi-typescript-codegen Generates a Typescript client with interfaces from an OpenAPI spec.
-
Merging duplicate interfaces
I'm not familiar with all the options openapi-generator has. I tried it awhile ago and found it quite buggy, and more of a pain to run, especially if you're not already doing Java development. I ended up preferring OpenAPI Typescript Codegen, which is written in Typescript. One option it has which would solve the problem you're running into here, is that you can tell it to use union types instead of enums. So your interfaces would be generated as
-
Don't make me think, or why I switched to Rails from JavaScript SPAs
I'm currently working on two separate projects, the first is a Django project with DRF and I codegen with drf-spectacular [1] and openapi-typescript-codegen [2]. The other project also uses Django, with the API through Hasura and codegen with graphql-codegen [3]. In both of these cases I've been able to largely avoid duplicating my models clientside, or at least it isn't manual.
1: https://github.com/ferdikoomen/openapi-typescript-codegen
2: https://drf-spectacular.readthedocs.io/en/latest/
3: https://github.com/dotansimha/graphql-code-generator
-
Need some advice on how do do my webapp (front + backend)
For typescript client code generation, I typically use something like openapi-typescript-codegen, but there are a lot more generators (like the openapi-generator project) that are imperfect in their own ways, I'm sure you can find one that works for you.
What are some alternatives?
fern-java - Generate Java models, clients, and server interfaces from your API definition.
openapi-client-axios - JavaScript client library for consuming OpenAPI-enabled APIs with axios
telefunc - Remote Functions. Instead of API.
orval - orval is able to generate client with appropriate type-signatures (TypeScript) from any valid OpenAPI v3 or Swagger v2 specification, either in yaml or json formats. 🍺
ts-to-zod - Generate zod schemas from typescript types/interfaces
SvelteKit - web development, streamlined
stytch-t3-example - An example app demonstrating how to use Stytch within the T3 stack
Devise Token Auth - Token based authentication for Rails JSON APIs. Designed to work with jToker and ng-token-auth.
vellum-client-python - Python SDK for Vellum API
graphql-code-generator - A tool for generating code based on a GraphQL schema and GraphQL operations (query/mutation/subscription), with flexible support for custom plugins.
vellum-client-generator - Vellum’s Fern API which is used to generate SDKs.
openapi-generator - OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)