Hey all! Bit of a Ruby on Jets newbie here but really enjoying everything I’m seeing and have gotten my first app up and running. Thank you to @tongueroo (@tung?) and everyone else who has contributed to the project, it’s surprisingly simple AND really powerful for someone coming from a rails background.
I was just curious if there are any plans to build official support for AppSync in an effort to build out GraphQL api’s? I’ve done some digging into the documentation and realize that most everything boils down to core “resource” model so I believe I should be able to build this out as RoJ stands right now. It seems a little more complex than just a simple “Associated Resource” as it requires an AWS::AppSync::GraphAPI resource before I can start to create associated resources.
My thinking is maybe that I create a “Shared” resource that creates the AWS::AppSync::GraphAPI resource - and then create “Associated Resources” for AWS::AppSync::DataSource resources that will call my lambda functions. I probably have a little playing around to do but figured I’d drop in here first and see if anyone has any experience here and/or if there are any plans to build it into the framework in a native manner much like APIGateway at any point.
No plans to add “native” GraphQL support, at least, in the sense being described here.
Some thoughts:
Found that for stateful resources, like a GraphQL data stores, it’s best to keep them out of Jets. Define things that is ok to fully replace with Jets.
The same reasoning would apply for a MySQL database. For example, wouldn’t want a “jets delete” to delete the DB. It’s better to decoupled them.
Other thoughts:
A GraphQL friendlier ruby interface to construct queries and map modeling structures would be a great library. It makes sense as a separate library, like an “ActiveRecord” for GraphQL.
Absolutely, very helpful…thanks a bunch for responding (and again for all of your work)
I agree completely to your point about stateful resources! I actually kind of anticipated having all of the data stores defined outside of Jets for that exact reason. To be fair, I may have done a poor job of explaining what I was thinking. I believe AppSync actually offers a lot more than just being a GraphQL “resolver” but that’s kind of all I was trying to get set up to get started. Rather than having to define all of the internals of a GraphQL api using a library like graphql-ruby, I thought it could come in quite handy to define the majority of that in AppSync (through Jets configurations) and just have the field resolvers map to lambda functions that are managed in Jets - much like API Gateway calls are now. That said, it may not make sense to offer both REST and GraphQL options for Jets if that’s not the intended direction for the library. Maybe it makes more sense in one of the other libraries you’ve developed.
I did end up making a bit of headway building some of this out. I was able to define the necessary AppSync resources (GraphQL Schema, GraphQL Api and an AppSync API Key) in Shared Extensions. Unfortunately, where it fell apart was trying to figure out where to create the resolver functions. It didn’t make sense to define those in “Controllers” because those are specifically used to generate API Gateway resources. I looked into defining them in simple functions under the functions directory but that didn’t feel right either.
I’ve since been pulled in a different direction temporarily but am hoping to get back to this soon. I’ll be sure to report back if I find an elegant way to handle all of this
Interesting. Have played with GraphQL before. It was pretty light though. So maybe lacking enough knowledge on GraphQL currently. This is helpful information to let simmer on the brain. Thanks for the notes.
Just thought I’d reply here and let you know that after digging into some more of your tools, I get the feeling that implementing AppSync may be something that is better suited for something like Lono (in case anyone else finds themselves with the same question as me)
May spend some time digging in and will certainly report back if so.
Thanks for all of your efforts on all of these tools!
This is helpful information to let simmer on the brain. Thanks for the notes.