I like this. A while ago, I was asking my co-founder the question "Why isn't there Git for data like there is for code?" while working on a database migrations engine that aims to provide automatic database migrations (data & schema migrations). After all, code is data.
I've been working on a language for building GraphQL servers quickly.
It use PostgreSQL for storage, it supports serverless functions using OpenWhisk, it allows you to write authorization rules, and it sets up user authentication workflows.
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.
Why not just work with people you enjoy working with on your own research independently?
If it provides someone with value, sure you can raise funds and generate revenue and dedicate your life for research. Of course it's easier said than done, but it's possible. Why not?
I believe that research-oriented tech startups can change the world and create/dominate new/emerging industries.
You'll have more skin in the game tying your research to a business, which will probably make you think bigger and change the world.
If done right (financing your research), you can have people more experienced than you are work with you, and learn from them.
Let's say that you can use these services while building your backend using a BaaS from the BaaS solution itself natively, would this solve your problem?
When we started writing the code for Heavenly-x (https://heavenlyx.com), the first thing we needed to write before anything else is the definition of a data structure that represents the requirements as close as possible (a concrete syntax tree).
We’re building a tool with a custom DSL for building CRUD GraphQL APIs, with auth and data validation and transformation. So our architecture consists of three phases:
- Parser
- Setup
- Runtime
There’s no way the parser would succeed if the input is not valid. We’re writing our software in Scala and we are using parboiled2 for parsing the DSL into a concrete syntax tree, so if it succeeds then it’s valid and if it fails, it fails early and we don’t have to worry about validation in later phases. We wrote some custom validation logic that traverses the concrete syntax tree after the parser to validate for some requirements that we couldn’t encode in the concrete syntax tree, but it’s really a small portion of our codebase and it’s easy to maintain.
At the Setup and the Runtime phase we assume that the concrete syntax tree is valid.
At the Runtime phase we have a running GraphQL server so we have a parsing phase too but it’s handled by Sangria so we don’t have to worry about it.
We are also building a UI for those who don’t like using our language. It’s a React app where the state data structure looks exactly like our concrete syntax tree.
