apollographql

apollo-tooling

TypeScript2017–2018

apollographql / apollo-tooling

apollo-tooling

✏️ Apollo CLI for client tooling (Mostly replaced by Rover)

Explore on GitHub Read Hacker News discussions

5Distinct people

5Mentions

0Explicit recommenders

3KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

✏️ Apollo CLI for client tooling (Mostly replaced by Rover)

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month5 dated mentions

Observed mentions: 2017-08-02 05:57:09 UTC to 2018-12-26 11:20:29 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
Aug 2017	2017-08-01 00:00:00 UTC	2017-09-01 00:00:00 UTC	1	1
Sep 2017	2017-09-01 00:00:00 UTC	2017-10-01 00:00:00 UTC	0	0
Oct 2017	2017-10-01 00:00:00 UTC	2017-11-01 00:00:00 UTC	0	0
Nov 2017	2017-11-01 00:00:00 UTC	2017-12-01 00:00:00 UTC	0	0
Dec 2017	2017-12-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	1	1
Jan 2018	2018-01-01 00:00:00 UTC	2018-02-01 00:00:00 UTC	1	1
Feb 2018	2018-02-01 00:00:00 UTC	2018-03-01 00:00:00 UTC	0	0
Mar 2018	2018-03-01 00:00:00 UTC	2018-04-01 00:00:00 UTC	0	0
Apr 2018	2018-04-01 00:00:00 UTC	2018-05-01 00:00:00 UTC	0	0
May 2018	2018-05-01 00:00:00 UTC	2018-06-01 00:00:00 UTC	0	0
Jun 2018	2018-06-01 00:00:00 UTC	2018-07-01 00:00:00 UTC	0	0
Jul 2018	2018-07-01 00:00:00 UTC	2018-08-01 00:00:00 UTC	0	0
Aug 2018	2018-08-01 00:00:00 UTC	2018-09-01 00:00:00 UTC	0	0
Sep 2018	2018-09-01 00:00:00 UTC	2018-10-01 00:00:00 UTC	0	0
Oct 2018	2018-10-01 00:00:00 UTC	2018-11-01 00:00:00 UTC	0	0
Nov 2018	2018-11-01 00:00:00 UTC	2018-12-01 00:00:00 UTC	0	0
Dec 2018	2018-12-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	2	2

What Hacker News says

5 sources

fro0116·Dec 26, 2018

The first thing that popped in my head was also how this compares to Apollo CLI's type generation (https://github.com/apollographql/apollo-tooling, formerly apollo-codegen). On a cursory glance, it seems like with this tool, you write a JS object in the same shape as the query, manually specifying the type of each field in that object, and then it generates the query for you to pass to graphql clients, as well as the types associated with the result of that query for you to use in your app. Whereas with Apollo's codegen, you write the query in graphql syntax, then run a CLI command to generate the types associated with that query for you to import and use. It seems with this tool, you'd still have to manually state the type of each field (when that information can be perfectly inferred from the schema as demonstrated by Apollo's codegen),

Read the rest

and you'd lose the ability to take advantage of tools that work with the graphql syntax to provide things like autocomplete based on your graphql schema while you're writing the query itself (https://github.com/apollographql/vscode-graphql, for instance). Unfortunately I'm not yet able see any benefits you'd get over Apollo's codegen in return. Happy to be enlightened if I'm missing anything.

In Show HN: TypeScript to GraphQL conversion tool with type inference

fantalamera·Dec 26, 2018

Doesn’t Apollo’s Codegen tool already solve this? Works like a charm https://github.com/apollographql/apollo-tooling?files=1#apol...

In Show HN: TypeScript to GraphQL conversion tool with type inference

adamkl·Jan 21, 2018

>GraphQL is amazing when your service has to respond to unpredictable queries, like with a public API. But if the queries can be predicted, like in-between services, you lose a lot of database performance by opening your service up to literally any query pattern imaginable. I agree that you have to be careful when it comes to performance, but ultimately, that has to be balanced with the needs of the internal environment. One-off RPC interfaces are easy to set up between systems, but can lack the flexibility to adapt to the requirements of unknown future consumers (I'm thinking large enterprise with multiple lines-of-business). This can lead to a lot of rework and regression testing in the best case, or multiple copy/paste variations with minor differences in the worst. >GraphQL also doesn't play well with strongly typed languages. Its com

Read the rest

pletely fundamental to how GraphQL works. Your best, safest bet is to have pre-written queries with types associated with those queries, but at that point its questionable exactly what benefit you're getting from GraphQL. I'm not sure I follow you here. GraphQL's schema definition and introspection capabilities are very similar to SOAP/XML and WSDL's, and those play very well with typed languages. Its possible to generate type definitions off the GraphQL schemas to use on the server side to ensure compile time safety, and there are multiple libraries that will do the same on the client side. [1][2][3] As for the benefit, flexibility of consumption. Again, I'm thinking enterprise scale where services have long lifespans, and the consumers aren't always known in advance. >its incredible to me that you're already using schema-stitching in a production app when it was released just a month or two ago Nothing in production yet. An approach like this will definitely have to be vetted more thoroughly before it gets to that point. >We're not about to force services to adopt Node just for Apollo Only required for the schema-stitching layer. The individual GraphQL services can be developed with any language/platform that has an implementation. [1]https://github.com/avantcredit/gql2ts [2]https://github.com/apollographql/apollo-codegen [3]https://github.com/Shopify/graphql_java_gen

In Rejoiner: Unified GraphQL schema from gRPC microservices

lewisl9029·Dec 15, 2017

If you use Apollo as your GraphQL client, there's apollo-codegen [0], which supports generating both Flow and TypeScript type definitions. Relay Modern's query compiler also generates Flow types AFAIK. But that's only for the client side. I suppose if you'd like to use typed JavaScript on the server side, something like the library you've posted might be your best bet, since client side solutions like apollo-codegen generate types based on the exact set of queries in your client-side app, which might not be all that useful for implementing the GraphQL server itself (unless maybe your API is private and you can afford to implement some form of persisted queries?). Having access to all the individual base types specified in your schema would probably be more useful for that purpose. [0] https://github.com/apollographql/apollo-codegen

In RESTyped: End-To-end Typing for REST APIs with TypeScript

jahewson·Aug 2, 2017

My personal take on this is that TypeScript has surpassed Flow in its feature set and the availability of typings for existing libraries. The features which previously made Flow unique have been incorporated into TypeScript, two particular favourites of mine being string literal types and tagged unions. You can indeed generate TypeScript types from a GraphQL schema, using apollo-codegen: https://github.com/apollographql/apollo-codegen Generative testing from types in TypeScript isn't something I've seen. With a static type system, if the code compiles then you know it's correct with respect to the types - no amount of automated testing would prove otherwise. In a dynamic language like Clojure where there are no types then you need generated values and tests to try and get some (still incomplete) safety. So you want a rich type system whic

Read the rest

h can capture as much information about your data as possible - TypeScript does a nice job of this, on the whole . Having said that, if you wanted to provide testing data or constraints along side your types, @decorators provide a means of adding custom annotations - so you, or someone could certainly generate test for data beyond the richness of the type system, e.g. a valid email.

In TypeScripts Type System Is Turing Complete