Just read all your objections to Parse.
It seems to me that all of them arise from two core things
- You don't have access to database that actually holds the data
- The database is MongoDB which is quite young compared to MySQL/Postgres and can't do terribly complicated stuff
The above two things as you said made Parse very inflexible once you get beyond prototype phase.
I think i solved all of your objections in my product (http://graphqlapi.com) which puts the database at the center and the schema drives the api.
Internally it uses PostgREST to which i've been a core contributor for more then a year now ... how time flies :)
Thank you for the praise, however i really want to stress that Sub0 (and PostgREST) are not prototyping tools only :)
It's true that you don't build api's with them the way you would with a more traditional stack but you can build real products with this a lot faster.
This style of building APIs clicks faster with people that use (and trust) Postgres
Since it's in private beta which started a few weeks ago there is not specific system in production of Sub0 specifically, but someone (medical research institute with lots of research data) is already building a React frontend over their massive Postgres database using Sub0 and so far it's going well.
The tutorial i provide explains building a complete API for something like Trello
At the core of the system sits PostgREST and you can see a few users here http://postgrest.com/en/v0.4/intro.html#in-production although i suspect a lot more people are using it but don't advertise it. I've also done extensive performance test for speed, those numbers on the home page are real :)
The above two things as you said made Parse very inflexible once you get beyond prototype phase.
I think i solved all of your objections in my product (http://graphqlapi.com) which puts the database at the center and the schema drives the api. Internally it uses PostgREST to which i've been a core contributor for more then a year now ... how time flies :)