I looked at what you're doing. I don't want to learn to write GraphQL markup in a new DSL. Honestly, what you've created is a solution looking for a problem.
Do you prefer a UI? Like Hasura, AppSync, 8base, and firebase? The DSL is very very close to GraphQL’s SDL though, so learning it shouldn’t take more than 5 minutes.
The problem we’re solving is the tediousness of building a GraphQL API.
We decided to work on this 14 months ago because me and my co-founder have built many backend systems and 99% of the time it’s just CRUD, auth and some validation and transformation logic, yet it would still take a lot of time to get something done.
The problem is very clear to us, but we’re trying to refine the solution to have something that is 10x better than what is already in the market.
We went with the DSL route because we wanted to support as many languages as possible for “turing complete” logic and not get tied up to one language. Also, text is great, and running locally is even better because it gives you the freedom to integrate it into any system very easily, unlike UI-based cloud solutions which are neither text nor run locally.
The GraphQL API isn't tedious. I write one language, TypeScript. The rest is all automatically generated for me. Fully typesafe, easy to unit test, fast to add features, not much boilerplate. Check out: type-graphql + https://graphql-code-generator.com/
Yeah GraphQL APIs are not tedious to work with, I LOVE GraphQL Codegen for TypeScript and it works very well with my DSL. What's tedious is building a GraphQL API, not consuming it.
https://github.com/pragmalang/pragma
I've been working on this for the past 14 months. Would love some feedback.