Ask HN: Need advice for an API building product

6 points by ruslan_talpa ↗ HN
Hi, I am the founder of Sub0 - GraphQL and REST API for your database (http://graphqlapi.com) It's a piece of software that your run on your server and it will generate and expose a GraphQL and REST API by introspecting your database schema.

Like most developers I am more comfortable with technical issues then with sales and marketing but as a founder I need to figure out this part too. I would be very grateful if you could give me feedback on the following topics.

- What would be your expectations when it comes to licensing and pricing of such a tool?

- Which of the flowing 4 messages resonates more with you as a developer?

http://graphqlapi.com/dont-waste-time/ http://graphqlapi.com/graphql/ http://graphqlapi.com/postgrest/ http://graphqlapi.com/your-data/

The tool currently is in private beta but anyone is welcome to request an invite if you are interested in trying it out. Although this is more of a sales/marketing thread, i am happy to answer any technical questions you might have here.

Thank you

15 comments

[ 3.6 ms ] story [ 43.0 ms ] thread
I may not understand your product but isnt an ORM already an api for your database? with ruby for example, all i need to do is Object.where(id = 1) to get a specific record out.
Thank you for the feedback, these kind of questions do help to zoom in on the correct message.

When i say API, i am referring to "curl http://api.site.com/object/1" type of api, the kind you expose to the web where other developers can use to access the data in your backend/database, or even your frontend/mobile app talking to your backend through this API.

A lot of basic db operations is basically built into rails scaffolding though. for instance /object/1 automatically gives u id 1 back without any extra coding.
I get what you are saying but even to get that you had to (manually) define your model and it's fields and relations and that is only the most basic thing you can ask of an api, but how about the following tasks: requesting a subset of objects using a few filters, requesting only specific properties of objects, specifying what users can and can not access info about those objects, making sure garbage does not get into the database (input validation).

All these things have to be manually solved by you in your controllers, there is no scaffolding for that, while in Sub0 all those things are already solved, most of what you have to do is define your database schema and the rest just works.

As an example in terms of time invested (based on specific personal experience): To build an api the way you describe for a product like Basecamp it will take a good developer at least a few months. With sub0 we are talking 1-2 weeks.

Maybe I am extreely strict but I would want a developer to create that api himself in just 2-3 days. we're not talking anything sophisticated here like bulding a web crawler. This is basic CRUD 101 and not a huge pain point in the development process.
While it's not compiler technology (crawlers are trivial too), it's not basic CRUD either. It's an API able to support your entire frontend/SPA/mobile app, basic CRUD won't give you that. If you think it will take you 2-3 days to implement an api for Basecamp i would say you are overly optimistic :). If it would be that simple, products like Parse/Firebase would have not existed in the first place (much less acquired by facebook and google)
1 and 4 makes sense. Ok it provides an api ? is it like parse or BaaS - what does end user get - backend with apis,frontend ? Or how is it different to Kinvey who are in similar space.
(comment deleted)
I am interested in trying out - my email is in profile about @gmail
Thank you for your interest, please use the "Request Invite" form on the homepage as i have an automated process there.
Oh, i see you already did, nevermind :)
Thank you. 've got the invite - Im facing issue with cloning repo. Have pinged on slack.
In the most simple terms, you can think of it as an executable that you start, point to your database (PostgreSQL) and on the other end you get a GraphQL and REST api. The schema in your database drives the api. I am not very familiar with kinvey, but comparing with Parse (or what it used to be) and looking only at the REST interface you can say it has a lot of similarities but the fact that it's backed buy Postgre gives you much more flexibility as soon as you get beyond the simple CRUD stuff. Another differentiating point is the GraphQL interface which makes it possible for you to use OS frontend clients (Relay/ApolloClient/Lokka) and not have to learn a proprietary sdk