graphql-perl - a GraphQL implementation in Perl
I have recently started porting the reference implementation of GraphQL for JavaScript to Perl, sponsored by Perl Careers. My key considerations:
- Use as "modern" Perl as possible: one of the Mo* family, plus type-checking
- Follow the JS implementation where it makes sense, but be open to more Perlish ways where that's easier/better
You can see the GitHub repo at https://github.com/graphql-perl/graphql-perl, and the MetaCPAN page for the distro at https://metacpan.org/release/GraphQL.
Initial findings:
- it will be useful to have a possibility in module-starter to generate a GitHub-aware filebase, including meta info pointing at your GH repo, and .travis.yml and .gitignore and MANIFEST.SKIP
- a workable "modern" type system looks achievable with Moo, Type::Tiny, Function::Parameters, and Return::Type. It would probably be useful to enhance module-starter with boilerplate for these too.
- Pegex looks promising as a means of lexing and parsing GraphQL. If this is successful enough, it may even be possible to use the grammar beyond Perl, in line with Ingy's "Acmeist" philosophy.
- Tests will just be straightforward Test::More for the present time. A future possibility also advancing the above would be to use TestML for tests.
- For the GraphQL internal type system, it may or may not be possible to use Type::Tiny for that too!
Hi Mohawk
Before committing to PEG, I suggest you read about some of the serious issues it faces, the worse IMHO being that it can't tell you the parse is ambiguous:
o PEG: Ambiguity, precision and confusion
o Grammar reuse
Damn. The 1st link had a double single-quote at the start. Retrying...
o PEG: Ambiguity, precision and confusion
Function::Parameters 5.14 requirement is a little steep, perhaps something like Type::Params (part of Type::Tiny dist) could be used instead, also avoiding having to use 'fun' and 'method' keywords instead of 'sub'.
If you can wait a couple of days, the next stable release of Type::Params should have measurable speed improvements over the current stable release too.
I don't know enough about GraphQL to say whether it's suitable for implementing GraphQL's internal type system, but happy to help you figure it out.