@buzzdan I started my GraphQL journey with Alumbra. I inherited the beginnings of the service and was tasked with building it out. It’s a tricky library but very customizable due to it’s tight integration with Claro (made by the same guy). However, it’s not the easiest library to work with. The API design is fairly unintuitive and it’s not super easy to build a fully reloadable workflow with it. Keep in mind, when you subscribe to Alumbra, you also subscribe to Claro. Writing code is different, data modeling is similar but testing is vastly different. Most importantly though, workflow is different. I’m in the process now of converting the service to use the Lacinia library. I’ve found it to be much simpler and easier to work with compared to working around Alumbra. The difference between the two really clicked when a non-clojure developer on my team mentioned how much easier it is to work with Lacinia than Alumbra. The biggest advantage of Lacinia, I’ve found, is that it was not built around a non-core data structure. Everything surround Lacinia (testing, development, workflow, integrations, etc…) are intuitive and easy to get on to. The last thing I’ll leave you with is that the Lacinia team is always available. The lead developer on the project is on here a ton and the community is significantly larger. Given that Walmart Labs is supporting the project, you’ll always have support as long as Walmart is using it (which, I think, is going to be for a long time). With Alumbra, the support and development team consists of a single guy. An incredibly smart and driven guy (it shows in his excellent work) but he is still one guy. That’s just my two cents! I hope it helps!

@hlship Minor bug: Lacinia appears to be renaming the query and mutation types to QueryRoot and MutationRoot respectively, even if the schema IDL explicitly names them differently.