Hacker News new | ask | show | jobs
by mmastrac 3433 days ago
I was never a huge fan of parse, having seen startups fail hard when using it, and I've been pretty vocal about that in the past [1]. It was a great idea in principal, but failed pretty hard when faced with the reality of non-toy development.

I generally hate to see projects fail, but in this case I'm not terribly upset. I think that people were getting sucked into the ease of getting apps up and running quickly, then spending 2-3x the effort getting past that initial stage versus doing it in a more traditional stack.

Perhaps the open-source server might give the community some opportunity to fix the many, many glaring bugs and problems, but I have felt like the specific design of Parse itself was just too flawed to succeed.

[1] https://news.ycombinator.com/item?id=10056033

4 comments

I generally hate to see projects fail

Many would be happy to fail like this!

Facebook acquires Parse, an app-support company, for $85 million

http://articles.latimes.com/2013/apr/26/business/la-fi-tn-fa...

What's the shame in being a great prototyping tool? While it's not the right choice for everything in your stack, it's definitely one of the fastest ways to get a service or product off the ground.

My company came out of a similar place with Firebase. The initial version of our product was written 100% against Firebase. This was absolutely a good choice when it was made, but -- surprise! -- two years later, we had to start involving other databases. Was it harder than any other two-years-in scaleup? I didn't find it so. And we still use it where it makes sense.

That's the problem. It wasn't a great prototyping tool. Great prototyping tools are fine. Parse was not a great prototyping tool. In my not-terribly-nuanced-opinion, it was a really nice GUI wrapped around a not-so-great shim on top of MongoDB.

I don't have specific experience with Firebase, but I believe that from what I've heard from others using it, has a much better design that would survive much longer in the face of growth.

You say that you had to involve other databases two years in? The startups I've seen using parse are failing over to alternative technology much, much sooner.

I tried to reply to your comment you just deleted.
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 :)

That's really awesome! I'm glad to see you've also solved a lot of the req/s issues that Parse had too.

If prototyping tools are done right, I think they are valuable and awesome.

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

Do you have any nontoy examples of this? I.e. nontrivial apps in heavy use.
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 :)
Did you vocalize any of these issues anywhere? I have never used Parse but have been looking at the open-source version. What are the many, many glaring bugs and problems you're referring to?
We would all go crazy trying to report all the bugs we found in every piece of software out there these days. When there are too many or something is too difficult to use, you move on. To a large extent, finding bugs is the responsibility of the developers. When users submit bug reports, good ones at least, they should be thanked. My point is, as a developer, you can't blame the users for not reporting bugs.
That wasn't my question, but ok. I was just asking for the list of the "many, many glaring bugs" that OP was talking about. He edited his link, though, so it's already been answered.