Overall, it’s very alpha. Lots to work out still. Here’re are the bits I’m planning / building - above is the webdemo powered by parser+hxgen.
No progress on the macro workflow yet.
I’m going to offer an option to generate either typedefs or interfaces + classes. I believe they both technically work, it just depends on how you want to work with (and instantiate) your data (as class instances, or typed structs.)
This only deals with mapping simple schema / type definitions at the moment. Not yet any GraphQL queries, arguments, fragments, servers, etc. But it’s a nice, tidy interface description language, so we’re minimally looking into it for cross-stack data type definitions.
So far, I’m just working on basic schema / type mapping. Later I’ll look into typing queries. Once Haxe has all the correct types from a .graphql schema, I assume that you’d typically compile to JS and use the JS servers / etc.
That is, I don’t plan on building a server / query implementation in Haxe. Just the type definitions, so Haxe can be easily integrated with graphql-specified systems.
I don’t think so. That’d be like saying externs are useless because they don’t do anything.
Schema / type definitions are a small piece of the graphql ecosystem, but it is the foundation. You have to start somewhere! Or, looking at the graphql homepage… this project is currently in this realm:
FYI, I got tired of implementing a fragile parser clone, so I ported the official v0.13.2 graphql-js parser (parser.js, lexer.js, and ast.js). For the curious, I devised a few dozen regex’s in Ruby scripts, and it took about a day.
Naturally, this closes a bunch of issues and makes this library a ton more stable.
Also, expected query result types are now being generated – have a play with the updated web demo example:
I’ve been working on a way to simplify working with aws AppSync and haxe (one click to full project up and running goal). This graphql parser was the missing link between haxe and Apollo. Thanks!
