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

- In what way are RESTyped definitions lighter? A Swagger definition is just a JSON or YAML file and can be used without shipping any additional code (e.g. by https://github.com/swagger-api/swagger-js).

- Swagger only requires a build step when the definition is used to generate code. Definitions can be distributed via NPM (e.g. https://www.npmjs.com/package/appveyor-swagger).

Edit: I realized you were talking about RESTyped being lighter/nobuild compared to Swagger Codegen specifically for TypeScript because it is written in TypeScript. Seems reasonable.

I wrote an article about using apollo-codegen to generate all the Typescript types:

https://medium.com/@crucialfelix/bridging-the-server-client-...

It's still a few steps too many, but it's getting there.

I'm about to write up the second article which deals with mutations. This lets me import only one type:

    import { SetAptListOnWebProps } from "../mutations";

    (property) mutate: (options: MutationOptions<{
        apt: string;
        listOnWeb: boolean;
    }, {
        setAptListOnWeb: {
            apt: {
                id: string;
                listOnWeb: boolean;
                __typename: "Apt";
            };
            __typename: "SetAptListOnWebPayload";
        };
    }>) => Promise<{
        data: {
            setAptListOnWeb: {
                apt: {
                    id: string;
                    listOnWeb: boolean;
                    __typename: "Apt";
                };
                __typename: "SetAptListOnWebPayload";
            };
        };
        errors?: GraphQLError[];
        loading: boolean;
        networkStatus: NetworkStatus;
        stale: boolean;
    }>

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

The types are defined, so no need for documentation to explain the semantics. Oh, and if you don’t have the same tool stack, good luck getting the envelope header the way our server wants it.

Sometimes, there’s value in being able to add or omit attributes without some brittle (static) monstrosity messing itself.