Thunking is a way of deferring evaluation, so for instance you can specify a GraphQL thing that has a field that's an array of those same things even though at that moment the "thing" isn't valid yet.

I need to convert this schema to Perl Classes which each can take a JSON response and populate their corresponding object with that.

I don't believe that you do need that. What would you gain by doing so? GraphQL is all about APIs that can evolve without major-versioning, which means that these classes would need to constantly change too. I made the Perl GraphQL using OO because it seemed like a good idea, and I'd do it that way again. But I believe that OO programming must earn its keep, not be the default.

Your specific issue here may be that those "Ratio" things are GraphQL "scalar" types, and the Perl code isn't really set up to know what to do with those just with SDL information. In particular, the Perl GraphQL modules are very much for making a server-side service, and you are making client-side code. That doesn't need to know the whole schema. It only needs to know the particular query/queries to fill its own information needs. See, as linked in the "SEE ALSO" section of the GraphQL docs, http://graphql.org/graphql-js/ and the graphql-perl port at http://blogs.perl.org/users/ed_j/2017/10/graphql-perl---graphql-js-tutorial-translation-to-graphql-perl-and-mojoliciousplugingraphql.html.