Comments URL: https://news.ycombinator.com/item?id=25243227

Points: 4

# Comments: 0

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.

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.

The project is open-source, any feedback is highly appreciated: https://github.com/anasbarg/pragma

https://github.com/pragmalang/pragma

I've been working on this for the past 14 months. Would love some feedback.

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.

I don't plan to work as an aerospace engineer, I just want to understand how rockets work.

Thanks

Comments URL: https://news.ycombinator.com/item?id=24676671

Points: 3

# Comments: 0

I want to know about your pain points with existing BaaS solutions such as Firebase, AWS AppSync/Amplify, etc. so I solve them with the somain-specific language I'm building.

Thank you.

Comments URL: https://news.ycombinator.com/item?id=24602331

Points: 10

# Comments: 2

I’m building this because I think that building APIs is unnecessarily tedious and I wanted to he able to iterate on ideas faster.

It’s called Pragma (https://pragmalang.com). I would really appreciate any feedback.

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.

We’re launching soon. You can subscribe for early access here: https://heavenlyx.com/get-started

Comments URL: https://news.ycombinator.com/item?id=20386984

Points: 1

# Comments: 0