JSON has a limited selection of data types; more complex types, such as dates, are often represented as strings. When writing code, we would prefer to use our programming language’s stronger, more expressive types (e.g. DateTimeOffset in C#) rather than strings.

For example, given the JSON:

{
    "name": "David",
    "favoriteDate": "2012-04-23T18:25:43.511Z"
}

quicktype generates this type and corresponding marshaling code in C#:

public partial class Person
{
    [JsonProperty("name")]
    public string Name { get; set; }

    [JsonProperty("favoriteDate")]
    public DateTimeOffset FavoriteDate { get; set; }
}

This allows the programmer to write safer, more expressive code:

const person = Person.FromJson(jsonString);
// This comparison would not compile if FavoriteDate were string:
if (person.FavoriteDate < DateTimeOffset.Now)
{
    Console.WriteLine($"{person.Name} is nostalgic");
}

Many JSON APIs even string-encode values for which JSON types exists, such as booleans: { “goodIdea”: “false” }. Here, too, we would rather use booleans and rely on JSON de/serialization to do the conversion for us transparently.

In this post, I'll show how we added two new transformed string types (TSTs) to C# and Python: UUIDs and booleans. With this, you can take your customization of quicktype a step further, and maybe contribute a PR or two!

The feature

You've probably seen JSON that looks like this:

{
    "name": "Mark",
    "weight": "215",
    "can-juggle": "true",
    "id": "8352a2a8-b0cb-4cb6-8484-357cbcb6d5aa"
}

Using strings for numbers and booleans isn’t ideal because there is more potential for error. JSON frameworks will treat them as regular strings, which means you have to write the code to do the conversion back and forth. If you ask quicktype to infer the type for the above data, however, it'll give you this C# class:

public partial class Person
{
   public string Name { get; set; }
   public long Weight { get; set; }
   public bool CanJuggle { get; set; }
   public Guid Id { get; set; }
}

Now it’s easy to manipulate those values directly, and if you let quicktype generate de/serializers as well, convert from and to JSON:

var person = Person.FromJson(jsonString);
person.Weight -= 5;
jsonString = person.ToJson();

Let's see how we implemented booleans and UUIDs!

Adding booleans

The code for these two TSTs (transformed string types) is split up into three commits each. In the first commit for booleans, we tell quicktype about stringified booleans and how they are represented as strings in JSON.

Teaching quicktype about the new TST is one line of code in Type.ts, adding a property to transformedStringTypeTargetTypeKinds:

"bool-string": { jsonSchema: "boolean", primitive: "bool" } as TransformedStringTypeTargets

What it says is that we want a new TST called bool-string, which has the JSON Schema “format” boolean, and which corresponds to quicktype's primitive type bool.

To detect stringified booleans in input JSON we modify the function inferTransformedStringTypeKindForString in StringTypes.ts:

/**
 * JSON inference calls this function to figure out whether a given string is to be
 * transformed into a higher level type.  Must return undefined if not, otherwise the
 * type kind of the transformed string type.
 *
 * @param s The string for which to determine the transformed string type kind.
 */
export function inferTransformedStringTypeKindForString(s: string): TransformedStringTypeKind | undefined {
    if (s.length === 0 || "0123456789-abcdeft".indexOf(s[0]) < 0) return undefined;

    if (isDate(s)) {
        return "date";
    } else if (isTime(s)) {
        return "time";
    } else if (isDateTime(s)) {
        return "date-time";
    } else if (isIntegerString(s)) {
        return "integer-string";
    } else if (s === "false" || s === "true") {
        return "bool-string";
    } else if (isUUID(s)) {
        return "uuid";
    }
    return undefined;
}

These two new lines do the actual business:

} else if (s === "false" || s === "true") {
   return "bool-string";

The first line of the function is an optimization: If the string is empty, or it doesn't start with one of the characters in that list then it can't be one of the string types we detect, so we bail out early. All we have to do for booleans is to add the letters f and t. If we wanted to also interpret the strings "no" and "yes" as booleans, we'd have to add the letters n and y, too.

At this point, if we ask quicktype to produce a JSON Schema for this JSON:

{
    "foo": "true"
}

we get this:

{
    "$schema": "http://json-schema.org/draft-06/schema#",
    "$ref": "#/definitions/TopLevel",
    "definitions": {
        "TopLevel": {
            "type": "object",
            "additionalProperties": false,
            "properties": {
                "foo": {
                    "type": "string",
                    "format": "boolean"
                }
            },
            "required": ["foo"],
            "title": "TopLevel"
        }
    }
}

Notice how the type for foo is string, with boolean as its format. That's what we specified as the jsonSchema property in the first part of the commit. format is an "assertion" that’s part of JSON Schema which allows string types to be constrained. An example for a format that’s part of the JSON Schema specification is ”date-time” for date-time strings. boolean isn’t in the spec, but we’re allowed to invent our own. Unfortunately, the JSON Schema verifier Ajv that we use in our test suite fails if it sees this new unknown format, which is why the last part of the commit tells Ajv to ignore it:

let ajv = new Ajv({ format: "full", unknownFormats: ["integer", "boolean"] });

C#

The commit that adds support for stringified booleans to C# starts out by adding a case to the function needTransformerForType:

if (t.kind === "integer-string" || t.kind === "bool-string") return "manual";

manual here means that when the renderer emits the C# code for a bool-string property, it adds a JsonConverterAttribute to the property that specifies a JsonConverter to convert said property. Since only some booleans are decoded from strings, this explicit attribute is required. Here is the code for one real boolean, and one converted from strings:

[JsonProperty("real-bool")]
public bool RealBool { get; set; }

[JsonProperty("string-bool")]
[JsonConverter(typeof(ParseStringConverter))]
public bool StringBool { get; set; }

The next part adds a line to stringTypeMapping:

mapping.set("bool-string", "bool-string");

All entries not explicitly set in mapping are treated as if they were set to string, which means that without this line, quicktype would make each bool-string in the input into a string for C#. You would get correct code, but stringified booleans would still just be handled like plain strings. You might think that mapping should just be a set of all types which are to be kept as-is, but sometimes types are mapped to other non-string types:

mapping.set("date", "date-time");
mapping.set("time", "date-time");
mapping.set("date-time", "date-time");

Dates, times, and date-times are all mapped to the same type date-time, which in C# is represented by DateTimeOffset. That's because C# doesn't have specialized types for dates and times, only a combined date-time type.

The last two pieces are about how to do the actual conversions between strings and booleans when your JSON is de/serialized at runtime. The code generators for the conversions are cases for the type bool in the transformers ParseStringTransformer and StringifyTransformer. C# does not have a type that corresponds to bool-string; it only has bool and string. Transformers are the pieces that convert between bool and string, and the CSharpRenderer has to generate the code for them. Here's the case for ParseStringTransformer:

case "bool":
   this.emitLine("bool b;");
   this.emitLine("if (Boolean.TryParse(", variable, ", out b))");
   this.emitBlock(() => this.emitConsume("b", xfer.consumer, targetType, emitFinish));
   break;

Here’s code that it generates:

bool b;
if (Boolean.TryParse(value, out b))
{
   return b;
}

variable is where the string to be converted is stored. emitBlock produces the curly-braces block, the insides of which are generated by emitConsume. xfer.consumer is an optional transformer for the result (the variable b) of this conversion. In this example, we don't have a consumer, but we'll see one later on. targetType is the type that is produced at the end of this transformer chain, i.e., once the consumer, and its consumer, and its consumer's consumer, etc., are done. It just has to be passed through. emitFinish emits the code for what needs to happen at that end of the transformer chain, which is the return statement in this example. There might be other transformers to try after this one, which is why if TryParse fails, the generated code just continues on. On the other hand, if this is the last hope of decoding this string, the code to throw an exception is generated automatically by the CSharpRenderer.

On to the last part of this commit to support stringified booleans in C#: the case for StringifyTransformer, which turns boolean values back into JSON string values! It looks similar to the switch case for ParseStringTransformer:

case "bool":
   this.emitLine("var boolString = ", variable, ' ? "true" : "false";');
   return this.emitConsume("boolString", xfer.consumer, targetType, emitFinish);

The first line does a switch on the boolean to get its string value, and the second line is almost identical to what we've seen before. The relevant difference is that the code returns the result of emitConsume. I mentioned above that the CSharpRenderer generates code for the case when the runtime transformation fails. This code is only generated, however, if the transformation can actually fail. How does the renderer know? The function we modified returns true if the transformation is guaranteed to succeed, i.e., never falls through. By default it returns false, signifying the transformation can fail, which is why we only had to break for the ParseStringTransformer. Here, we know that our part of the transformer chain always succeeds: a boolean can only be either false or true, and we handle both cases. However, the consumer might still fail, so we return the failability result of emitConsume.

That's all that's needed to make stringified booleans work in C#.

Python

Now let me explain how I implemented stringified boolean support in Python. The first part, which we've already seen above, lets quicktype know that PythonRenderer supports stringified booleans:

mapping.set("bool-string", "bool-string");

The next bit, in needsTransformerForType, is easier to explain than the C# version. In C# we have help from the Json.NET framework, which has lots of converters built in, but in Python our generated code has to do it all on its own, so it doesn’t distinguish between “manual” and “automatic” conversion. That’s why, for bool-string, we always return true:

return t.kind === "integer-string" || t.kind === "bool-string";

In Python, if we can express a transformer as a simple, short expression, we emit it inline; otherwise, we emit a function for it. As we'll see below, converting a boolean into a string is indeed a short expression, but the reverse is not, so we need a function. We only want to emit this function when we actually have stringified booleans in our JSON, which is why the PythonRenderer keeps track of which converter functions it has to emit. First, we have to add a new case to the type of all converter functions, ConverterFunction:

| "from-stringified-bool"

Next is the code that emits the converter function:

protected emitFromStringifiedBoolConverter(): void {
   this.emitBlock(
       ["def from_stringified_bool(x", this.typeHint(": str"), ")", this.typeHint(" -> bool"), ":"],
       () => {
           this.emitBlock('if x == "true":', () => this.emitLine("return True"));
           this.emitBlock('if x == "false":', () => this.emitLine("return False"));
           this.emitLine("assert False");
       }
   );
}

The calls to typeHint make sure that the type hints are only emitted when the user selects a Python version that supports types. Note another difference to C#: If the conversion fails, an exception is thrown.

The function emitConverter has a case for each converter function that just calls its emitter:

case "from-stringified-bool":
   return this.emitFromStringifiedBoolConverter();

Next up is producing code for the bool case of ParseStringTransformer:

case "bool":
   vol = this.convFn("from-stringified-bool", inputTransformer);
   break;

convFn emits a call to the function from_stringified_bool, and its argument is the result of the transformation inputTransformer: in Python we go the other way around to emitting a transformer chain: The consumers are generated first, with the producers (the transformers that preceded them) nested inside.

The case for StringifyTransformer doesn't have to produce a function call since we can do the conversion as a simple, inline expression:

case "bool":
   vol = compose(inputTransformer, v => ["str(", v, ").lower()"]);
   break;

The compose function emits code for the inputTransformer and then passes the result on to the expression that the arrow function emits. Here’s the line of code that’s generated for converting the boolean property foo to a string:

result["foo"] = from_str(str(self.foo).lower())

That's it for Python!

Adding UUIDs

UUIDs (universally unique identifiers) are strings that are commonly used to identify items, such as in primary keys for rows in a database table, or data items in REST APIs, and as such are often found in JSON data.

After having seen the code for booleans, most of the code for UUIDs doesn't hold any surprises, but there are still a few details that are different. Let's start at the first commit, which adds the uuid type. The main point of interest here is its entry in transformedStringTypeTargetTypeKinds:

uuid: { jsonSchema: "uuid", primitive: undefined },

Unlike bool-string, for which we set primitive to "bool", the uuid type doesn't have a primitive. That's because it doesn't correspond to any primitive type that's already in quicktype: it's a new type of its own.

More small differences await us in the commit that adds support for C#. To start with, uuid has been added to isValueType:

return ["integer", "double", "bool", "enum", "date-time", "uuid"].indexOf(t.kind) >= 0;

That's needed because the C# type for UUIDs, Guid, is a value type in C#. We didn't have to do this for booleans because we didn't introduce a new type in C#: bool was already there. Speaking of Guid, there's a new case that introduces it in csTypeForTransformedStringType:

if (t.kind === "uuid") {
    return "Guid";
}

One last little change that we didn't see with booleans above is that Guid is now a "forbidden name" for the global namespace, which essentially means that quicktype won't name a C# class Guid, which would result in a name collision:

protected forbiddenNamesForGlobalNamespace(): string[] {
   return ["QuickType", "Type", "System", "Console", "Exception", "DateTimeOffset", "Guid"];
}

In the Python commit we see similar changes, in particular a new case in pythonType to produce the UUID Python type:

if (transformedStringType.kind === "uuid") {
    return this.withImport("uuid", "UUID");
}

The withImport invocation returns UUID and imports the uuid package. The commit adds an identical case in typeObject, which returns the Python type object so the generated code can check whether a given value is an instance of that type.

The rest of the changes are very similar to those for booleans.

What we get for free

We only had to implement converting individual values, but data transformers use that building block to give us a lot more for free. To illustrate, let's quicktype this JSON input:

{
    "boolOrInts": ["true", 123]
}

quicktype generates this type for the array items of foo, which is a union of boolean and integer:

    public partial struct BoolOrInt
    {
        public bool? Bool;
        public long? Integer;

        public static implicit operator BoolOrInt(bool Bool) => new BoolOrInt { Bool = Bool };
        public static implicit operator BoolOrInt(long Integer) => new BoolOrInt { Integer = Integer };
    }

Taking a look at the code for converting array items we see these lines:

if (Boolean.TryParse(stringValue, out b))
{
   return new Foo { Bool = b };
}

This is an example of a consumer transformer: The consumer of this ParseStringTransformer is a UnionInstantiationTransformer, which generates code that takes the boolean value and makes a Foo out of it. There's much more to data transformers than this, a lot of which we'll get to in a future blog post.

How to contribute

quicktype is Open Source. If you'd like to see it improve, please consider contributing. When it comes to TSTs, there are two kinds of contributions that would be very helpful:

• Implement more TSTs. In particular null, floating point numbers, base64 blobs, and URLs. I hope I managed to convince you in this blog post that the scope of this is fairly manageable. It's a little tricky to understand at first, but once you do, you can contribute powerful features to quicktype, and we’re always there to help.

• Implement data transformers for other languages. Right now transformers are only implemented in C# and Python, with no other language getting the benefit of TSTs, or other future enhancements to transformers. I won't lie: this is quite a challenge, but if you're up for one, please talk to us on Slack; we're always delighted to help.

quicktype's first birthday, Python support, 'continuous mode' for VS Code, and a brand new product: autotune

quicktype turns one

quicktype celebrated its first birthday on July 12th. In its first year, quicktype generated over 1.2 billion lines of code, by rough estimate. Read the birthday post for more about quicktype's exciting first year.

Continuous mode for VS Code

We recently released 'continuous mode' for quicktype within VS Code, which generates code continuously as you type:

Install the quicktype extension, open a JSON file, then run the Open quicktype for JSON command to try it.

Python support

Python is our latest language, with support for Python 2.7 through 3.7, including data classes and typing. In this screenshot, quicktype generates typed Python models from TypeScript:

Try generating Python in the quicktype web app.

UUID and stringified integer+boolean detection

quicktype can now detect integers, booleans, and UUIDs (in addition to dates, times, and enums) within strings. quicktype will generate stronger types and code to convert JSON string values to the stronger types. In this screenshot, a strongly typed Person model is inferred from a JSON object with only string values:

These features are fully supported in Python and C# for now, and we're seeking contributors for other languages

Announcing autotune

We've just launched autotune, a tool that uses machine learning to automatically optimize apps and web sites. It's made for developers (rather than marketers) and has already improved quicktype in unexpected ways.

While building quicktype, we'd often come up with ideas for experiments for the quicktype web app and homepage. For example:

• Should we show code samples on our homepage?
• How should we encourage users to sign up in the app?
• What message should we ask users to tweet about quicktype?

We found that implementing these tests with traditional A/B testing tools was not trivial—especially tests that affected application behavior or tests with many possible values—so we tended to only test straightforward and seemingly consequential facets.

We suspected that there were many, many more aspects of quicktype that could be optimized via A/B testing, so we created autotune to make adding tests and options as easy as adding a line of code.

For example, here's how we let autotune pick the best title for the button that opens the quicktype web app on quicktype.io:

import { autotune } from "autotune";

function render() {
    let buttonTitle = autotune.oneOf("Open button title", [
      "Launch",
      "Try now",
      "Open app",
      "Generate code",
      "Open quicktype"
    ]);
    
    function launch() {
        autotune.complete();
        window.location.href = "https://app.quicktype.io";
    }

    return <Button onClick={launch} title={buttonTitle} />;
}

At first, autotune picked buttonTitle randomly, but soon it determined that "Generate code" performed best—14% better than "Open quicktype"—so autotune caused "Generate code" to be picked more often, increasing the number of users who open app.quicktype.io from quicktype.io.

Check out autotune.xyz to try autotune for free today, and please let us know how it goes!

Today quicktype is one year old. After generating one billion lines of code, here's a look back on quicktype's first year.

How quicktype started

A year ago, I was writing some Swift to parse and represent JSON when I was struck by how mind-numbingly tedious the process was (especially before Codable was introduced in Swift 4). I had seen some simple JSON-to-code translators, but they were always buggy, had terrible UX, and were hard-coded for a single programming language.

"Mark, I need your big brain," I said to my big-brained friend Mark, before explaining the problem and what I thought a good solution would be like: paste JSON on the left, instantly get lovely code in any language on the right, with functions for marshaling to-and-from JSON strings. The goal would be to generate the same code that a person would write by hand, so the style had to be impeccable and we'd have to infer intuitive names for types and properties.

Mark agreed it would be a fun project, so we started hacking, and within a day or two, the world got its first look at a crude prototype:

quicktype was implemented as 700 lines of purely-functional PureScript, generating C# and Go from an intermediate representation. Here's the code that rendered C# classes:

renderCSharpClass :: IRClassData -> Doc Unit
renderCSharpClass (IRClassData { names, properties }) = do
  line $ words ["class", csNameStyle $ combineNames names]
  lines "{"
  indent do
    for_ (Map.toUnfoldable properties :: Array _) \(Tuple.Tuple pname ptype) -> do
      line do
        string "[JsonProperty(\""
        string pname
        string "\")]"
      line do
        string "public "
        graph <- getGraph
        string $ renderTypeToCSharp graph ptype
        words ["", csNameStyle pname, "{ get; set; }"]
      blank
    
    -- TODO don't rely on 'TopLevel'
    when (names == Set.singleton "TopLevel") do
      lines """// Loading helpers
           public static TopLevel FromJson(string json) => JsonConvert.DeserializeObject<TopLevel>(json);
           public static TopLevel FromUrl(string url) => FromJson(new WebClient().DownloadString(url));"""
  lines "}"

Then we continuously deployed updates and new features for a year.

quicktype today

quicktype has come a long way in that time. quicktype now has:

• Generated over 1.2 billion lines of code, by rough estimate. In San Francisco, you'd have to hire 76 developers at a cost of $7.9 million to write this code, assuming no sick days and all programmers type 40 WPM for 6 hours per day!
• 30k lines of TypeScript in core libraries
• 13k lines of TypeScript in the web app
• Support for C#, Go, Rust, C++, Objective-C, Java, TypeScript, JavaScript, Flow, Swift, Kotlin, Elm, JSON Schema, Ruby, and now Python
• Support for GraphQL, JSON Schema, and TypeScript as input, so you can more formally specify desired output types
• Many language-specific options, like typesafe HTTP request handlers in Swift or runtime type checking in JavaScript
• Integer, enum, and map inference
• Stringified number, boolean, date, and UUID inference with automatic parsing in C# and Python
• Extensions for Xcode, VSCode, and Visual Studio

We recently released 'continuous mode' for the VSCode extension, which generates code from JSON, schema, and TypeScript as you type:

Python is our latest language, with support for Python 2.7 through 3.7, including data classes and typing:

If you look carefully at the Python above*, you'll notice some subtle sophistications:

• people is inferred to be a map using a Markov chain that discerns class property names from arbitrary keys
• fav number is legalized as fav_number, automatically translated to-and-from JSON, and stringified numbers are detected and parsed
• has friends is inferred as a sometimes-stringified boolean, and is automatically translated from string to bool
• class is reserved in Python, so it's legalized as person_class and automatically translated
• born is inferred to be a date and automatically parsed as a datetime
• nickname is inferred as optional, and expressed as Optional[str]

* quicktype generates additional code to implement the automatic translations, omitted from the screenshot

As you can see, quicktype has evolved into something quite powerful from its simple beginnings.

Thank you!

Thank you for using quicktype and giving us feedback! Nothing motivates us more than interacting with you on Twitter, GitHub, Intercom, or Slack. If you'd like to support our work, please blog, screencast, tweet, or demo quicktype to your friends. 😊

In this post I’ll show you how to customize quicktype’s output. Suppose we’re building a mobile game in C# that the player can pick up on their Android phone in the morning, continue in their web browser in the afternoon and finish on their iPad in the evening. We have to send the state of the game over the network to a server, which is written in Go, and we’d like to use JSON to serialize and deserialize the state. quicktype already does a great job generating classes with serialization functionality for us, but we have a few extra requirements for the C# code:

1. Some of the types will represent objects in the game, so quicktype will have to generate them as subclasses of GameObject.

2. We'd like to specify default values for some properties, such as the hit points of a player or monster. We want quicktype to generate those property assignments.

Out of the box quicktype has neither of those two features, so we'll implement them in this blog post, making quicktype generate customized C# code from a JSON Schema model.

Before writing code to generate other code, we should design the desired generated code by hand to see what works and what doesn't, and to have a more specific idea of what the generated code should look like. Here is the code we want quicktype to generate for us:

public partial class Player : GameObject
{
    public long HitPoints { get; set; } = 100;
    public string Name { get; set; } = "Emmerich";
    public Position Position { get; set; }
}

public partial class Position
{
    public double X { get; set; }
    public double Y { get; set; }
}

As you can see, the Player class is a subclass of GameObject while Position is not. The properties HitPoints and Name in Player also have default values. quicktype can generate neither of those two out of the box, but it's customizable enough to make it happen.

This is the JSON Schema definition that we would like to use as an input to quicktype to generate the sample code above:

{
    "$schema": "http://json-schema.org/draft-06/schema#",
    "$ref": "#/definitions/Player",
    "definitions": {
        "Player": {
            "type": "object",
            "properties": {
                "name": { "type": "string", "default": "Emmerich" },
                "position": { "$ref": "#/definitions/Coordinates" },
                "hitPoints": { "type": "integer", "default": 100 }
            },
            "required": ["name", "position", "hitPoints"],
            "additionalProperties": false,
            "gameObject": true
        },
        "Coordinates": {
            "type": "object",
            "properties": {
                "x": { "type": "number" },
                "y": { "type": "number" }
            },
            "required": ["x", "y"],
            "additionalProperties": false
        }
    }
}

The definition of the Player type has the property gameObject, which obviously isn't part of the JSON Schema standard, and both name and hitPoints have a default property. The latter is part of JSON Schema, but quicktype currently ignores it. We'll change that.

Using quicktype as a library

We will use quicktype as a library and write our own main program that invokes it. You can follow along in this repo.

To start out, we need the quicktype-core NPM package. To invoke quicktype, we need this main function:

import * as fs from "fs";

import { quicktype, InputData, JSONSchemaInput, CSharpTargetLanguage } from "quicktype-core";

async function main(program: string, args: string[]): Promise<void> {
    // Exactly one command line argument allowed, the name of the JSON Schema file.
    if (args.length !== 1) {
        console.error(`Usage: ${program} SCHEMA`);
        process.exit(1);
    }

    // The "InputData" holds all the sources of type information that we give to quicktype.
    const inputData = new InputData();
    const source = { name: "Player", schema: fs.readFileSync(args[0], "utf8") };
    // "JSONSchemaInput" is the class that reads JSON Schema and converts it into quicktype's
    // internal type representation (see https://blog.quicktype.io/under-the-hood/ for a
    // semi-outdated but still useful introduction to the IR).
    // The "source" object is in the form that "JSONSchemaInput" needs.
    await inputData.addSource("schema", source, () => new JSONSchemaInput(undefined));

    // "CSharpTargetLanguage" is the class for basic C# types.  Its subclass
    // "NewtonsoftCSharpTargetLanguage" also produces attributes for Newtonsoft's Json.NET,
    // but we don't need those for our game, so we work with the base class directly.
    // Because it's not specialized we have to give it three arguments, none of which are
    // actually needed in our simple application: The "display name" of the language, an
    // array of names by which we could specify it, were we using quicktype's CLI, and the
    // file extension for the language.
    const lang = new CSharpTargetLanguage("C#", ["csharp"], "cs");

    // What we get back from running "quicktype" is the source code as an array of lines.
    const { lines } = await quicktype({ lang, inputData });

    for (const line of lines) {
        console.log(line);
    }
}

main(process.argv[1], process.argv.slice(2));

When we run this program with our JSON Schema input we get these basic classes:

public partial class Player
{
   public long HitPoints { get; set; }
   public string Name { get; set; }
   public Coordinates Position { get; set; }
}

public partial class Coordinates
{
   public double X { get; set; }
   public double Y { get; set; }
}

Our own target language

Now that we have the basics working, let's build our own subclass of CSharpTargetLanguage and make it do something custom! To be useful, we will have to subclass another class, as well: CSharpRenderer. The TargetLanguage keeps all information about a specific language, such as its name, and what kinds of options its output can be customized with. The Renderer is instantiated by the TargetLanguage with a specific set of options and only lives to produce output once.

Here is our first attempt at a TargetLanguage:

class GameCSharpTargetLanguage extends CSharpTargetLanguage {
    constructor() {
        // In the constructor we call the super constructor with fixed display name,
        // names, and extension, so we don't have to do it when instantiating the class.
        // Our class is not meant to be extensible in turn, so that's okay.
        super("C#", ["csharp"], "cs");
    }

    // "makeRenderer" instantiates our "GameCSharpRenderer".  "cSharpOptions" are the
    // values for the customization options for C#, and "getOptionValues" translates the
    // untyped string values to the typed values that the renderer likes.
    protected makeRenderer(renderContext: RenderContext, untypedOptionValues: { [name: string]: any }): CSharpRenderer {
        return new GameCSharpRenderer(this, renderContext, getOptionValues(cSharpOptions, untypedOptionValues));
    }
}

class GameCSharpRenderer extends CSharpRenderer {
    // We override the "superclassForType" method to make "GameObject" the superclass of all
    // class types.  We need to do the check for "ClassType" because quicktype also generates
    // classes for union types which we don't want to customize.
    protected superclassForType(t: Type): Sourcelike | undefined {
        if (t instanceof ClassType) {
            return "GameObject";
        }
        return undefined;
    }
}

To use the GameCSharpTargetLanguage we have to instantiate it in main:

const lang = new GameCSharpTargetLanguage();

Selective subclassing

To pass the information of whether a type is a game object from the JSON Schema to the renderer we need a feature of quicktype called "type attributes". A type attribute is a piece of information that can be attached to a type. For example, quicktype uses type attributes to store descriptions and potential names for types, and as we’ll see, they can also be used to extend code generation. Type attribute are opaque to the core systems of quicktype: quicktype passes them through, but otherwise leaves them alone, with the exception of invoking a few basic operations that all type attributes must support.

We will define a new kind of type attribute to indicate whether a type is a game object, and we’ll call it GameObjectTypeAttributeKind:

class GameObjectTypeAttributeKind extends TypeAttributeKind<boolean> {
   constructor() {
       // This name is only used for debugging purposes.
       super("gameObject");
   }

   // When two or more classes are combined, such as in a "oneOf" schema, the
   // resulting class is a game object if at least one of the constituent
   // classes is a game object.
   combine(attrs: boolean[]): boolean {
       return attrs.some(x => x);
   }

   // Type attributes are made inferred in cases where the given type
   // participates in a union with other non-class types, for example.  In
   // those cases, the union type does not get the attribute at all.
   makeInferred(_: boolean): undefined {
       return undefined;
   }

   // For debugging purposes only.  It shows up when quicktype is run with
   // with the "debugPrintGraph" option.
   stringify(isGameObject: boolean): string {
       return isGameObject.toString();
   }
}

const gameObjectTypeAttributeKind = new GameObjectTypeAttributeKind();

Our new attribute kind extends TypeAttributeKind<boolean>, which means that the value of one such attribute is just a boolean. All we need to know, after all, is whether—true—or not—false—a type is a game object. Notable things about the methods we override:

• makeInferred is currently used only for naming types. It has potential other uses, but we won't get into it here. You'll almost always want to return undefined here.

• quicktype sometimes needs to combine types with each other that are separate in the JSON Schema. For example, we can't (yet) process unions of different class types, so when you try to create one with oneOf or anyOf, the two class types get combined into one, containing the union of the original classes' properties. What happens to those two classes' type attributes is that they are combined with the method combine. In our case, if any of the constituent types represent a game object, we'll make the resulting type represent one, too.

Now that we have our type attribute kind, how do we get the actual attributes onto the types? We need an attribute producer, which is a function that the JSON Schema input code calls on each schema type, and which can return one or more type attributes, or undefined if it doesn't apply to that type. Here's the producer for our game object attribute:

// "schema" is the JSON object in the schema for the type it's being applied to.
// In the case of our "Player" type, that would be the object at "definitions.Player"
// in the schema.

// "canonicalRef" is the location in the schema of that type.  We only use it in an
// error message here.

// "types" is a set of JSON type specifiers, such as "object", "string", or
// "boolean".  The reason it's a set and not just a single one is that one type
// within the schema can specify values of more than one JSON type.  For example,
// { "type": ["string", "boolean"] } is a JSON Schema for "all strings and all
// booleans".
function gameObjectAttributeProducer(
    schema: JSONSchema,
    canonicalRef: Ref,
    types: Set<JSONSchemaType>
): JSONSchemaAttributes | undefined {
    // Booleans are valid JSON Schemas, too: "true" means "all values allowed" and
    // "false" means "no values allowed".  In fact, the "false" for
    // additionalProperties in our schema is a case of the latter.  For that reason,
    // our producer could be called on a boolean, which we have to check for first.
    if (typeof schema !== "object") return undefined;

    // Next we check whether the type we're supposed to produce attributes for even
    // allows objects as values.  If it doesn't, it's not our business, so we
    // return "undefined".
    if (!types.has("object")) return undefined;

    // Now we can finally check whether our type is supposed to be a game object.
    let isGameObject: boolean;
    if (schema.gameObject === undefined) {
        // If it doesn't have the "gameObject" property, it isn't.
        isGameObject = false;
    } else if (typeof schema.gameObject === "boolean") {
        // If it does have it, we make sure it's a boolean and use its value.
        isGameObject = schema.gameObject;
    } else {
        // If it's not a boolean, we throw an exception to let the user know
        // what's what.
        throw new Error(`gameObject is not a boolean in ${canonicalRef}`);
    }

    // Lastly, we generate the type attribute and return it, which requires a bit of
    // ceremony.  A producer is allowed to return more than one type attribute, so to
    // know which attribute corresponds to which attribute kind, it needs to be wrapped
    // in a "Map", which is what "makeAttributes" does.  The "forType" specifies that
    // these attributes go on the actual types specified in the schema.  We won't go
    // into the other possibilities here.
    return { forType: gameObjectTypeAttributeKind.makeAttributes(isGameObject) };
}

To tell the JSONSchemaInput about our attribute producer, we pass it in as the second argument when we instantiate it in main:

await inputData.addSource("schema", source, () =>
    new JSONSchemaInput(undefined, [gameObjectAttributeProducer])
);

That was quite a bit of work, and we're almost done. The last thing we need to do is make our renderer look at the type attribute and only generate the GameObject superclass where we need it. Here's the code required to do that:

protected superclassForType(t: Type): Sourcelike | undefined {
    if (!(t instanceof ClassType)) return undefined;

    // All the type's attributes
    const attributes = t.getAttributes();
    // The game object attribute, or "undefined"
    const isGameObject = gameObjectTypeAttributeKind.tryGetInAttributes(attributes);
    return isGameObject ? "GameObject" : undefined;
}

Apart from the boilerplate, which is a story for another time, this should be self-explanatory. Our code now produces the superclass in the right places!

Default values

The other feature we need are default values, which we'll implement with a second type attribute kind. We will be lazy here: We'll only properly support default values for number, string, and boolean types, and we won't do any error handling for cases that don't work. The way we're implementing it is by holding on to the default value JSON object and just stringifying it into the C# code. The syntax for numbers, strings, and booleans is the same in JSON and C#, which is why this works, mostly.

Here is the type attribute kind, which stores a type's default value as an any:

class DefaultValueTypeAttributeKind extends TypeAttributeKind<any> {
    constructor() {
        super("propertyDefaults");
    }

    combine(attrs: any[]): any {
        // If types with default values are combined, they better have the same
        // default value!  We make sure of that here, and throw an exception if
        // they don't.
        const a = attrs[0];
        for (let i = 1; i < attrs.length; i++) {
            if (a !== attrs[i]) {
                throw new Error("Inconsistent default values");
            }
        }
        return a;
    }

    makeInferred(_: any): undefined {
        return undefined;
    }

    stringify(v: any): string {
        return JSON.stringify(v.toObject());
    }
}

const defaultValueTypeAttributeKind = new DefaultValueTypeAttributeKind();

Again, we'll also need an attribute producer, which is pretty simple in this case:

function propertyDefaultsAttributeProducer(schema: JSONSchema): JSONSchemaAttributes | undefined {
    // booleans are valid JSON Schemas, too, but we won't produce our
    // attribute for them.
    if (typeof schema !== "object") return undefined;

    // Don't make an attribute if there's no "default" property.
    if (typeof schema.default === undefined) return undefined;

    return { forType: defaultValueTypeAttributeKind.makeAttributes(schema.default) };
}

We make sure we're dealing with an object, that it has a default property, and if it does, we just take its value and make an attribute out of it. Of course we also have to pass in the new producer function when we instantiate JSONSchemaInput.

How do we produce the C# code for this? The CSharpRenderer has a method propertyDefinition which returns the code for a single property. What we need to do is override it such that when that property has a default value, there's also an assignment = <default>; at the end:

protected propertyDefinition(p: ClassProperty, name: Name, c: ClassType, jsonName: string): Sourcelike {
    // Call "CSharpRenderer"'s "propertyDefinition" to get the code for the property
    // definition without the default value assignment.
    const originalDefinition = super.propertyDefinition(p, name, c, jsonName);
    // The property's type attributes
    const attributes = p.type.getAttributes();
    const v = defaultValueTypeAttributeKind.tryGetInAttributes(attributes);
    // If we don't have a default value, return the original definition
    if (v === undefined) return originalDefinition;
    // There is a default value, so stringify it and bolt it onto the original code
    // at the end.
    return [originalDefinition, " = ", JSON.stringify(v), ";"];
}

We're done! Check out the finished project on GitHub. If you'd like to apply this to your own use case and need any help whatsoever, please come talk to us on Slack.

Our biggest set of updates ever. Let's get right to it!

New Languages

• Objective-C with no dependencies
• Kotlin via Klaxon
• Rust
• Ruby with runtime typechecking
• Flow
• Vanilla JavaScript with runtime typechecking

New C# Features

• Option to fail if required properties are missing from JSON.
• Option to choose Double or Decimal for floating-point numbers.
• Option to choose Object or dynamic for properties without type information.

New Swift Features

• URLSession task extensions make it easier than ever to download API data as structs without any dependencies:

let task = URLSession.shared.pokedexTask(with: url) { pokedex, response, error in
  if let pokedex = pokedex {
    ...
  }
}
task.resume()

• Alamofire extensions add similar extensions for working with Alamofire.
• Option to specify a type name prefix.
• Option to choose internal or public access level for creating library code.

Drag-and-drop Multiple Files

Try dropping multiple JSON files into quicktype to generate a coherent set of types. quicktype will infer equivalent types across the samples to prevent duplicates.

Share quicktype Easily

The new Share Link button will generate a link to share your input and options:

This is a great way to help another developer generate code with quicktype, or to make a snapshot of quicktype to refer to later.

Download Code as zip

quicktype generates multiple files for languages like Objective-C and Java, so now you can click Download Code to get a zip containing many source files rather than creating separate files manually.

quicktype Playgrounds

quicktype playgrounds allow you to embed quicktype in any webpage by including a single script and placing some sample JSON in a <div>. This is great for pages that display JSON because it allows visitors to immediately copy code to represent the data in their apps.

TypeScript Input

For succinct, precise control over generated types, you can now use TypeScript as an input language. Here's an example of an AddressBook type specified in TypeScript, then generated in every language quicktype supports.

Postman Input

You can quicktype an entire Postman Collection by dropping it into quicktype:

Learn more about this feature on the Postman blog.

Visual Studio and Xcode Extensions

Try our free & open source Visual Studio and Xcode extensions. You can find the repos here and here.

Improvements to quicktype Core Library

Better map inference using Markov chains.

• Support for more JSON Schema features, documentation as comments, better error reporting, better naming, renaming.

Extend a language or implement your own using quicktype as a library

Did you know that quicktype is also a library? In fact, all quicktype apps (web, CLI, IDE extensions, and playgrounds) use the same open-source quicktype library from npm.

Use it from JavaScript by doing npm i quicktype then:

import { quicktype } from "quicktype";
const result = quicktype({ ... });

Here are two examples of using quicktype as a library:

• Generating customized C#
• Generating customized Java

Thank you!

Thank you for using quicktype. We love working on it and helping developers wrangle the world's messy JSON data. If you'd like to support us, please share quicktype by writing blog posts, making screencasts, demoing it at meetups, or just sharing it with friends & colleagues.

As always, please let us know if there are any new features you'd find useful! Say "👋" on Slack if you'd like to get in touch with us, or just click the chat bubble in the lower-right. Thanks!

Based on Kotlin playgrounds^[1], quicktype playgrounds allow you to embed quicktype in any webpage by including a single script and placing some sample JSON in a <div>. This is great for pages that display JSON because it allows visitors to immediately copy code to represent the data in their apps.

To add a quicktype playground to any webpage, first add this <script> element:

<script src="https://unpkg.com/quicktype-playground@1"></script>

Then add a <div class="quicktype" /> containing some sample JSON:

<div class="quicktype" data-type-name="Person">
{
  "name": "Bob",
  "age": 99,
  "friends": ["Sue", "Vlad"]
}
</div>

When the page loads, the <div> becomes an interactive widget with the ability to view the types for that JSON in every language quicktype supports:

You can specify a subset of languages to display with data-languages:

<div class="quicktype" data-type-name="Pokedex" data-languages="C# Java Swift">
{
  "pokemon": [
    {
      "id": 1,
      "num": "001",
      "name": "Bulbasaur",
      "img": "http://www.serebii.net/pokemongo/pokemon/001.png",
      "type": [ "Grass", "Poison" ],
      "weaknesses": [ "Fire", "Ice", "Flying", "Psychic" ],
      "next_evolution": [
        { "num": "002", "name": "Ivysaur" },
        { "num": "003", "name": "Venusaur" }
      ]
    },
    ...
  ]
}
</div>

This is an experimental feature that we hope you find useful! We still need to:

• Remove code left over from Kotlin playgrounds
• Remove unused dependencies–the script is currently large but should be able to shrink significantly
• Add more quicktype features

Please check out quicktype/quicktype-playground to file issues or send pull requests!

Alamofire is an elegant HTTP networking library that makes working with JSON APIs in Swift a breeze. quicktype makes Alamofire even more awesome by generating extensions and Codables for typesafe API calls.

Here's Alamofire's canonical example of handling a JSON API response:

Alamofire.request("https://httpbin.org/get").responseJSON { response in
    if let json = response.result.value {
        // json is of type Any, so we must cast and use dictionary indexers
        let data = json as! [String: Any]
        let headers = data["headers"] as! [String: String]
        print(headers["Accept-Language"])
    }
}

Unfortunately, as you can see, you're still left with json: Any, a dynamic value that you must cast and awkwardly introspect for the data you care about.

quicktype can generate statically-typed Alamofire response handlers along with Codable structs from JSON, allowing us to rewrite the above sample like this:

Alamofire.request("https://httpbin.org/get").responseHTTPBinGet { response in
    if let json = response.result.value {
        print(json.headers.acceptLanguage)
    }
}

How it's done

You can use the quicktype CLI or app.quicktype.io to generate Alamofire extensions and Codable structs directly from the API endpoint:

$ quicktype https://httpbin.org/get --alamofire -o HTTPBinGet.swift

quicktype generates the following Codable type for this API:

struct HTTPBinGet: Codable {
    let args: Args
    let headers: Headers
    let origin, url: String
}

struct Args: Codable {
}

struct Headers: Codable {
    let accept, acceptEncoding, acceptLanguage, connection: String
    let host, upgradeInsecureRequests, userAgent: String

    enum CodingKeys: String, CodingKey {
        case accept = "Accept"
        case acceptEncoding = "Accept-Encoding"
        case acceptLanguage = "Accept-Language"
        case connection = "Connection"
        case host = "Host"
        case upgradeInsecureRequests = "Upgrade-Insecure-Requests"
        case userAgent = "User-Agent"
    }
}

And Alamofire extensions to handle the API response:

extension DataRequest {
    // ...

    @discardableResult
    func responseHTTPBinGet(
        queue: DispatchQueue? = nil,
        completionHandler: @escaping (DataResponse<HTTPBinGet>) -> Void)
        -> Self {
            return responseDecodable(queue: queue, completionHandler: completionHandler)
    }
}

The code generated by quicktype allows you to do a statically-typed Alamofire request, getting the benefit of type-safety and code completion on your response data!

Alamofire.request("https://httpbin.org/get").responseHTTPBinGet { response in
    if let json = response.result.value {
*         // json is an instance of HTTPBinGet
        print(json.headers.acceptLanguage)
    }
}

Try this feature in your browser.

Little Big Details are the subtle details that quicktype takes care of when turning your data into beautiful, readable code. This Little Big Detail is about how quicktype uses the names of outer types to generate nice alternate names when property type names collide.

In every programmer's life there comes a day when they have to build a Swift app that stores data about celebrities and their pets. The back-end might provide JSON data like:

{
    "names": {
        "given": "Daenerys Targaryen",
        "nick": "Dany"
    },
    "job": "Khaleesi",
    "hobby": "government",
    "pet": {
        "names": {
            "given": "Rhaegal",
            "nick": "Ray"
        },
        "species": "dragon",
        "size": "huge"
    }
}

Run quicktype on this data and it infers these types:

struct Celebrity {
    let names: Names
    let job, hobby: String
    let pet: Pet
}

struct Names {
    let given, nick: String
}

struct Pet {
    let names: Names
    let species, size: String
}

Note that quicktype inferred that the .names and .pet.names properties have the same type, so it created only a single Names struct to represent both of them in the Celebrity and Pet structs. Easy!

The Celebrity/Pet app was a hit, so now the programmer moves on to a real estate app, where they're confronted with data like:

{
    "property": {
	    "name": "Blandings Castle",
        "info": {
		    "type": "Castle",
		    "county": "Shropshire"
        }
    },
    "owner": {
	    "name": "Clarence Threepwood",
        "info": {
		    "job": "Earl of Emsworth",
            "arch-rival": "Sir Gregory Parsloe-Parsloe"
        }
    }
}

How should quicktype name the structs here? The two outer ones, Property and Owner, are obvious, but each contains an info property with a distinct type. If they had the same type, such as with names in the celebrity-pets app, quicktype would just name it Info, but the info properties have different types and therefore need different type names.

quicktype could take the easy route and name them Info1 and Info2, or maybe Info and OtherInfo. Fortunately, quicktype is smarter than that and takes into account the outer types of the info properties, suggesting PropertyInfo for Property.info and OwnerInfo for Owner.info:

struct RealEstate {
    let property: Property
    let owner: Owner
}

struct Owner {
    let name: String
    let info: OwnerInfo
}

struct OwnerInfo {
    let job, archRival: String
}

struct Property {
    let name: String
    let info: PropertyInfo
}

struct PropertyInfo {
    let type, county: String
}

Little Big Details like this are how quicktype generates code as you would have written it. Think quicktype is going a good job? Please share!

This post is the first in a series we’re calling “Little Big Details”. It explains some of the subtle details that quicktype takes care of when turning your data into code, and the surprising amount of meticulous technical work behind these details. One of quicktype’s main goals is to generate the code that you would have written; the Little Big Details account for much of how quicktype achieves this.

The first Little Big Detail is about how quicktype turns JSON property names into nice property names in your preferred target language. Let's say you have some JSON like this:

{ "my_favorite_url": "https://quicktype.io/" }

What should the property name corresponding to "my_favorite_url" be? If you write C#, the answer is MyFavoriteUrl. Gophers prefer MyFavoriteURL, because they like their acronyms all caps, whereas in C++ you might just go with my_favorite_url. In Java you have getter and setter methods rather than properties, so my_favorite_url becomes getMyFavoriteURL and setMyFavoriteURL:

// C# class for { "my_favorite_url": "..." }
public class Demo
{
    public string MyFavoriteUrl { get; set; }
}

// Java class for { "my_favorite_url": "..." }
public class Demo {
    private String myFavoriteURL;
    public String getMyFavoriteURL() { return myFavoriteURL; }
    public void setMyFavoriteURL(String value) { this.myFavoriteURL = value; }
}

// Swift struct for { "my_favorite_url": "..." }
struct Demo {
    let myFavoriteURL: String
}

No matter what language you’re using, quicktype will figure out the best names for each property, and it will do so whether the JSON property is "my_favorite_url", "MyFavoriteURL", or "my favorite URL!!?!?!". How does quicktype do this?

First, quicktype splits up the JSON property name into its component words, in this example my, favorite, and url. Then it figures out which words are acronyms using two rules:

• If the word is all caps, and the whole property name contains at least one lowercase letter, then treat the word as an acronym

• If the word is in our big list of acronyms, then it's an acronym

The first rule will recognize acronyms in property names like "covered_by_ACA", and the second one hopefully takes care of all the rest.

To put the words back together to form the target property name, each target language specifies whether a word should be lowercase, capitalized (e.g. Url), or all caps for each of four conditions:

1. For the first word if it's not an acronym, like for good in good_vibes

2. For any other word if it's not an acronym, such as for three and musketeers in the_three_musketeers

3. For the first word if it's an acronym, like json in json_property

4. For any other word if it's an acronym, like url in homepage_url

Target languages may also specify a separator (e.g. C++ uses an underscore) to place between words.

These mechanisms allow quicktype to express all property styles common among its target languages, so you get properties named according to your language’s preferred conventions, no matter how gnarly your JSON is! If you find a case that quicktype doesn't handle correctly, please file an issue, or talk to us on Slack.

GraphQL is the hot new API technology that the cool kids are talking about. Here’s how to use quicktype to easily generate typesafe code for GraphQL queries.

If you’d rather jump straight into sample code, please see the GraphQL sample repo.

What is GraphQL and why is it cool?

With traditional APIs, you usually have to make multiple queries to collect the data needed by your app. For example, to get the followers for all of a user’s GitHub repos, you’d first query for a list of the user’s repos, then perform a query for each repo to get the followers. For a user with n repos, that’s n+1 queries, which means your app will be slow and will need a cumbersome UI (e.g. loading spinners, lazy lists).

With GraphQL, on the other hand, you specify exactly what information you want up front, so you get all the data your app needs in a single query.

Let's try it out by writing some queries against the GitHub API! You can run these queries in your browser using GitHub’s GraphiQL explorer. Here's a simple one for starters—it returns the current user's name and login info:

query {
  viewer {
    login
    name
  }
}

Here's the response I get for this query:

{
  "data": {
    "viewer": {
      "login": "schani",
      "name": "Mark Probst"
    }
  }
}

Let's try a more complex query—suppose we want the names of my three most-starred repositories, including the number of stars for each:

query {
  viewer {
    login
    repositories(first: 3, orderBy: { field: STARGAZERS, direction: DESC }) {
      nodes {
        name
        stargazers {
          totalCount
        }
      }
    }
  }
}

The result of this GraphQL query is:

{
  "data": {
    "viewer": {
      "login": "schani",
      "name": "Mark Probst",
      "repositories": {
        "nodes": [
          { "name": "clojurec", "stargazers": { "totalCount": 845 } },
          { "name": "quicktype", "stargazers": { "totalCount": 256 } },
          { "name": "metapixel", "stargazers": { "totalCount": 70 } }
        ]
      }
    }
  }
}

The first thing to notice is that the structure of the JSON we get back depends on the query. Unlike traditional APIs, which return a small, predefined set of types in response to queries, GraphQL APIs can return a huge permutation of types that are unique per query. For this reason, GraphQL API providers cannot provide strongly typed client libraries.

The second thing to notice is that the queries don’t specify types. For example, the last query doesn't specify that totalCount is a number, so how do we know what type to use? The answer lies in the GraphQL schema, which defines the types for all fields in all possible queries. GraphQL servers allow clients to download this schema through an “introspection query”.

Let’s see how quicktype can download a GraphQL schema using an introspection query, then generate types and helper code for our GraphQL queries.

To send an introspection query (or any GraphQL query) to GitHub, you need an access token. Follow these steps to get one and save it in an environment variable:

TOKEN=<your token goes here>

Make sure your token works by running this query on the command line:

curl -H “Authorization: bearer $TOKEN” \
     -X POST -d '{ "query": "query { viewer { login }}" }' \
     https://api.github.com/graphql

You should get back something like

{ "data": { "viewer": { "login": "schani" } } }

Now you can ask quicktype to download the GraphQL schema from the GitHub API server:

quicktype --graphql-server-header “Authorization: bearer $TOKEN” \
          --graphql-introspect https://api.github.com/graphql \
          --graphql-schema github.gqlschema

You should end up with a file named github.gqlschema that's a bit over 1MB. Here’s a simplified excerpt from that file that describes the totalCount field::

{
    "name": "totalCount",
    "description": "Identifies the total count of items in the connection.",
    "type": {
        "kind": "NON_NULL",
        "ofType": {
            "kind": "SCALAR",
            "name": "Int",
        }
    }
}

Now that you have the GraphQL schema, save one of the queries from above to the file query.graphql and tell quicktype to generate types for you:

quicktype --src-lang graphql --lang csharp \
          --graphql-schema github.gqlschema \
          query.graphql

I used the first query, which asked for my login and full name, and these are the C# types quicktype generated (if csharp isn’t your cup of tea, you can substitute elm, swift, java, c++, go, or typescript in the command line above):

public partial class Query
{
	[JsonProperty("viewer")]
	public User Viewer { get; set; }
}

public partial class User
{
	[JsonProperty("login")]
	public string Login { get; set; }

	[JsonProperty("name")]
	public string Name { get; set; }
}

quicktype generated C# classes that perfectly represent the type of the data returned by the query, adding JsonProperty annotations to ensure that the JSON is unmarshalled correctly. It also generated code to convert JSON to and from those nice types.

If you’d like to start using GraphQL right away, please check out our repository with sample code which shows you how to do a complete GraphQL query from start to finish using quicktype in C# and TypeScript.