TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Show HN: TypeScript to GraphQL conversion tool with type inference

90 点作者 acro5piano超过 6 年前

12 条评论

altschuler超过 6 年前
An alternative to this and Apollo codegen is GraphQL Code Generator[1]. Like codegen it takes the opposite approach by generating typescript from graphql. It&#x27;s similar to codegen, with the main two differences being 1) it&#x27;s not centered around queries, it will generate types for all schema parts as well as queries defined client-side. This is useful for getting typescript types for all the individual schema parts without being &quot;wrapped&quot; in the type of a query, and 2) it&#x27;s template based and relatively easy to extend modify how the code is generated.<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;dotansimha&#x2F;graphql-code-generator" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dotansimha&#x2F;graphql-code-generator</a>
评论 #18762512 未加载
评论 #18762668 未加载
arthens超过 6 年前
What&#x27;s the advantage of using this tool instead of apollo-cli&#x2F;apollo-codegen?<p>&gt; The main idea is to have only one source of truth by defining the schema using GraphQL-like object and a bit of helper class.<p>The source of truth already exists, and it&#x27;s the schema.<p>Why do I need to specify the type in every query? What happens if I make a mistake and write the wrong type? What happens if the schema changes after I write the query? Will it somehow fail and force me to update it?
lf-non超过 6 年前
This is very interesting.<p>I have been writing a library [1] to bridge relational databases efficiently to GraphQL APIs, and adopted a similar approach towards eliminating the redundancy in the schema definitions.<p>I currently rely on io-ts [2] which I also use for runtime verification of configuration options in an attempt to facilitate type verification to both JavaScript and Typescript consumers.<p>[1] <a href="https:&#x2F;&#x2F;gql-dal.github.io&#x2F;greldal&#x2F;" rel="nofollow">https:&#x2F;&#x2F;gql-dal.github.io&#x2F;greldal&#x2F;</a> [2] <a href="https:&#x2F;&#x2F;lorefnon.tech&#x2F;2018&#x2F;03&#x2F;25&#x2F;typescript-and-validations-at-runtime-boundaries&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lorefnon.tech&#x2F;2018&#x2F;03&#x2F;25&#x2F;typescript-and-validations-...</a>
评论 #18762591 未加载
mwilliamson超过 6 年前
The solution we use at work is to put all of the GraphQL strings in separate `.graphql.ts` files. A script then scans the code base for such files, requires them, and converts queries&#x2F;fragments into TypeScript types in a corresponding `.graphql.types.ts` file using apollo-codegen.<p>The advantage of this over plain .graphql files, or statically extracting queries, is that you can use all of the normal tools of TypeScript for composing queries (mainly imports and template literals), and you don&#x27;t need to have globally unique names for all your queries and fragments. Having said that, I haven&#x27;t looked at the recommended Apollo workflow in a little while, so I&#x27;m not sure if those issues still exist.
评论 #18762623 未加载
acro5piano超过 6 年前
&gt; What&#x27;s the advantage of using this tool instead of apollo-cli&#x2F;apollo-codegen?<p>&gt; Unfortunately I&#x27;m not yet able see any benefits you&#x27;d get over Apollo&#x27;s codegen in return<p>&gt; Doesn’t Apollo’s Codegen tool already solve this?<p>I am sorry for my late response.<p>I add the section to README.md which explains why I created this library even there is Apollo CLI&#x27;s codegen.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;acro5piano&#x2F;typed-graphqlify#why-not-use-apollo-clientcodegen" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;acro5piano&#x2F;typed-graphqlify#why-not-use-a...</a><p>In short,<p>- Simplicity make this tool works as expected<p>- Can handle multiple schemas<p>- Works without schema file<p>I wrote a lot there, but I just wanted to try the paradigm TypeScript -&gt; GraphQL conversion, because there are no tools to do that, unlike GraphQL -&gt; TypeScript conversion tools.<p>However, this is not just a hobby project, cause I use this in my current real world project, and it reduces a lot of boilorplate. So I submit here.<p># I thought Apollo codegen needs .graphql extension and webpack loader, but it reads .ts files too... Awesome.
drostie超过 6 年前
This is actually really interesting and mirrors a more general effort that I am pursuing[1] to build runtime representations of type in TypeScript, though my context is not so much GraphQL but rather just a more traditional HTTP API.<p>It looks like you try to keep it so that the runtime type object itself has the correct TypeScript type? That is, I would expect that under the hood you either have `types.number = 0`, `types.string = &#x27;&#x27;`, and so on and then you just use `typeof runtimeTypeObject` to derive this, or something more sinister like `types.number = (&#x27;number&#x27; as any) as number`. Either way that&#x27;s fairly clever and I like it. I probably won&#x27;t do it that way in `tasso` because one of my abstract points of power is that `tasso` should be able to validate that a given type object is a valid `tasso` schema, so there should be a metaschema. But it is really nice to have this thing saying just `typeof runtimeTypeObject` and not `ValueOfSingleType&lt;typeof runtimeTypeObject&gt;` to derive, from the schema&#x27;s type, the instances&#x27; type.<p>I may steal one thing for `tasso` from this library, and that is the way your `constant()` works without specifying type metadata; I was under the impression that even with the `&lt;t extends string&gt;` TypeScript would still say &quot;well `const x = constant(&#x27;abc&#x27;)` doesn&#x27;t say anything else about `&#x27;abc&#x27;` so I am going to infer that it is a `string` and then string does extend string so `x` has type `string`,&quot; much like it does when you just write `const x = &#x27;abc&#x27;`. I didn&#x27;t realize that you can &quot;hint&quot; that you want the more generic type for the thing. In tasso this manifests when you are writing self-recursive schemas, like<p><pre><code> &#x2F;&#x2F; the following line is a sort of hack const refs = tasso.refs&lt;&#x27;cell&#x27; | &#x27;list&#x27;&gt;(); &#x2F;&#x2F; but then we can write stuff like this const schema = { cell: tasso.number, list: tasso.maybe(tasso.object({ head: refs.cell, rest: refs.list })) }; </code></pre> It will be nice to replace that with `tasso.refs(&#x27;cell&#x27;)` and `tasso.refs(&#x27;list&#x27;)` without that &quot;refs object&quot;, I think.<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;crdrost&#x2F;tasso" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;crdrost&#x2F;tasso</a>
评论 #18762658 未加载
lars_francke超过 6 年前
Definitely looks interesting. I started with Apollo only a few weeks ago and am already tired of the redundancy and the verbosity.<p>I wonder how schema information&#x2F;introspection from the back end could be used to improve this further.<p>Apollo has the codegen tool which uses the schema to automatically generate the required classes.
评论 #18761657 未加载
评论 #18762449 未加载
fantalamera超过 6 年前
Doesn’t Apollo’s Codegen tool already solve this? Works like a charm <a href="https:&#x2F;&#x2F;github.com&#x2F;apollographql&#x2F;apollo-tooling?files=1#apollo-clientcodegen-output" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;apollographql&#x2F;apollo-tooling?files=1#apol...</a>
YorkianTones超过 6 年前
See also <a href="https:&#x2F;&#x2F;github.com&#x2F;convoyinc&#x2F;ts2gql" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;convoyinc&#x2F;ts2gql</a>
bitflower超过 6 年前
Couldn‘t `json-schema` play major role in modeling the redundant things? FeathersJS goes this way....
评论 #18762607 未加载
picardo超过 6 年前
Is there a similar conversion tool for Flow types?
bdr超过 6 年前
This looks great. Thanks!
评论 #18762608 未加载
评论 #18761857 未加载