Parse is shutting down today | Hacker News Reader

Parse is shutting down today

status.parse.com

435 pointsjpdlla238 comments

During this year-long shutdown/migration process, the open-source and community maintained Parse Server is what most people switched to. Parse is yours now. https://github.com/ParsePlatform/parse-server

Something I've been wondering is would you recommend using the open source Parse server for new code or is it more targeted towards projects that were already using the Parse API?

I have created a few apps using Parse.com, one of them successful enough to take the additional time/cost hit to migrate and host myself using the Parse-Server project.

The open source project is great and I appreciate the effort that went into making sure we didn't all get (totally) screwed.

Would I use Parse-Server for a new project? Probably not. The state of the BaaS options out there has changed/improved significantly since Parse.com was a thing.

Which BaaS options are recommended now?

I haven't used it, but firebase is popular.

Yes it's google behind ... but you should rewrite the whole application. That's why I respect Facebook about their decision to opensource the Parse Server. The is the beginning of the Open Backend world. With Parse Open Source everybody will get Personal MBaaS :)

I second the Firebase recommendation. Facebook killed off their BaaS acquisition while Google doubled down on theirs. If you prefer open-source, Horizon (http://horizon.io/) is a great alternative to Firebase but does not have many of the key features like file storage and iOS/Android SDKs.

Firebase has a few issues.

Take a look at this video and tell me this query and the required data denormalization is acceptable.

https://t.co/xd1KUPc8xY

They must be using something akin to Cassandra to require something like that

Yep data modelling and querying capabilities is a real deal breaker in Firebase.

Something as simple as filtering by 2 or more values becomes ridiculously tedious.

http://stackoverflow.com/questions/26700924/query-based-on-m...

I completely agree that on its own, the querying functionality can be quite tedious for anything complex. I linked to this solution on the comment above as well: https://github.com/davideast/Querybase

> Querybase is in an experiment and not for production

Also since Firebase doesn't allow more than one filtering field with orderByChild(...) I'm guessing Querybase will do all the work on the client. This is less than ideal since the data has to be downloaded first.

Querybase is also making permutations of all the data you may wish to query. Needlessly taking up space on your server that will have to be retrieved. Wasted bandwidth etc.

I wouldn't call this an "issue" as much as a "limitation". Just as you can develop a data denormalization process for any use case, you can develop one for Firebase.

Here's a practical example of doing joins with Firebase (written by David East who is also the star of that video you linked): https://github.com/davideast/Querybase

Watch out for the hidden costs.

As I found out today if you want the analytics data in CSV, or query it to any level that's useful beyond "We have 5 users in Stockholm on KitKat", you'll need the next service tier up, which is $25 per month per project.

But if you want basic analytics, then it's free & easy.

Horizon is a scary recommendation right now given the recent shuttering of RethinkDB (the company). It might still be a great choice, but I would give the community some time to coalesce and see where things end up before recommending it for new projects.

I wrote this piece on Firebase recently and I would not recommend it except for very simple or specialised projects.

https://medium.com/@Pier/firebase-the-great-the-meh-and-the-...

Don't get me wrong, Firebase has a lot of good things going on, but the bad aspects make it unsuitable for a large variety of projects.

I really like Firebase, but for specialized cases as others mentioned. The realtime updates are solid, and the iOS SDK at least is deep enough to let you dig into edge cases when needed (like, how many clients are listening to this node?). But I use it like an in-memory store to sync live data. Can't imagine having to use it like a full database - I use Parse for storing more permanent data across tables.

Backendless is a solid option: https://backendless.com/

With Backendless you should rewrite your apps, which is not so good :) Anyways ... what will happen when Backendless decide to shut down?

Then you too will shutdown xD

Scaphold (https://scaphold.io/) is a super neat BAAS built on GraphQL!

but we still got screwed and I still hate facebook because of it.

I used to work at Kinvey, they've got a pretty good product geared towards integrating with whatever you've got to connect with. They have always been security conscious, even have HIPAA support now IIRC.

Happy to answer any questions, or get some current devs there into the conversation to help out.

I used it for a new project I started 6 months ago. We've since transferred to AWS and a Express/Node.js project. However the Parse Server open source project is very well maintained and supported. I would recommend it for any quick prototype project you need a backend, but don't need it to do anything fancy.

I think it depends on your level of expertise and the requirements of your project. Having Parse Server as something you can set up in a few minutes on a VPS and start building a client-server app is great. The integration via the various SDKs is incredible, and it takes a long time to build something like that out. All the available options have their tradeoffs, but I think having the source and an interested community is a great pro in the Parse column.

Erik, I recommend use Parse Open source to any kind of App project that needs a robust backend. It is awesome, simple to install and to maintain.

It's geared towards legacy. I have used parse in 3 different projects (none of that was my choice, these were existing projects I had to take over) and I would NEVER recommend it for new projects.

The way everyone seems to use it, in my experience, is giving the client credentials to manipulate the full database which is absolutely insane. Obviously this is not good practice but every single parse project I've gotten thrown into already did this and it was a significant amount of work to move it to be more secure and NOT do that. I think the way it's created makes it very, very easy to make bad security choices.

It's also basically a RESTful CRUD. That's mostly it minus some, mostly minor, bells and whistles. You can already do this with about 20 different open source stacks very easily and you're not stuck using this parse technology.

I can't articulate just how much trouble parse has given me. I even took an app and re-wrote its entire backend away from parse significantly faster than doing a handful of updates.

> I think the way it's created makes it very, very easy to make bad security choices.

I can sympathize with this. I work on a dynamic API security scanner, and the vast majority of the Parse APIs I've scanned have either used API keys with full read/write permissions on the DB, or have left the database in development mode, essentially allowing anyone with an API key to modify the schema of the database.

Parse was a very cool product, but most setups I've seen didn't take advantage of the (sometimes hard to find) security features Parse provides.

Later versions don't let you easily give the client full access. You instead have to do it through Cloud Code (another facet of Parse), so the key never leaves the server.

Not to disagree with your overall assessment. I'm generally wary of these swiss-knife frameworks - they're written for a particular use case in mind, and if your project doesn't fit that, you may go through contortions to get things working smoothly.

> Later versions don't let you easily give the client full access. You instead have to do it through Cloud Code (another facet of Parse), so the key never leaves the server.

That's fantastic! I never kept track of which version(s) I worked on but I had transitioned one project from Parse to Parse Server and it was still able to work this way but I'm glad they made progress to try and force better security.

I just noticed the app I used with parse did exactly what you said (gave the client full access to database writes). My app only held "public" data and no passwords, emails, or sensitive data, but I was wondering how you manage to secure the DB writes. Wouldn't you need another server to send the write requests that would validate them before sending them to parse? Or is there another way?

To secure code with parse I believe the most common way is to basically move everything behind cloud code.

So instead of making HTTP calls to directly modify the DB you make HTTP calls to cloud code functions you wrote which then verify who you are and only modify what you should be able to modify.

for mvp I would say yes, parse-server provides security (ACLs/permissions) and performant database query helpers out of the box, its a battle-tested abstraction layer to mongodb, I had to make some workarounds to work for my specific usecase but just like any other framework it has it pros and cons, marketing and getting new users is the bottleneck for me not the database

Hi Fosco ... Thanks to you @flovilmart and the other heroes who made this possible :)

You guys are aweosme!

I second the sentiment that Parse has done a good job of shutting the platform down and giving users warning/notice. I hope the Open Source version takes off (looks like it has, with 12K stars!).

As a shameless plug though, there are other Open Source alternatives though - we wrote a migration guide for ours: https://github.com/amark/gun/wiki/Migrating-from-Parse .

Awesome Fosco! The open source community has already 12k+ stars on Github and is growing fast. Thank you for all the work and collaboration! You rock guys!!!!

And nowhere in there I was able to find what's Parse and what does the open-source Parse Server do.

Huh. Yeah, I dove around a bit, browsed the wiki, etc, and so far all I've seen is the equivalent of "an open source version of the Parse backend". No description anywhere that I can see about what it does or why you should care (unless you're already on Parse, of course).

IIRC the Parse homepage used to have this, but ever since the shutdown notice (so, for the past year) the homepage has largely been useless.

So many posts on HN are like this, assuming that every obscure webservice is common knowledge. "Jabberwocky has reached version 1.1! Performance increased by 30%, users must migrate from 1.0 by the 12th. Use Jabberwocky in your business now! New users get a free trial!" OK that's nice but what tf is it and why should I care?

Yesterday I built a 100M user social network using Jabberwocky. It took me just 25 minutes, bro, and now I've retired to my own private Caribbean island.

So it's you on my Caribbean lawn! Now get off it.

I'd assume the main goal of the open-source Parse Server is to provide some support for previous users of Parse? Who would already know what Parse does.

Attracting new users unfamiliar with the technology seems at best secondary ( and possibly, unwelcome) to the Parse Server community now.

Parse was an API as a service. The idea being that you don't need your own servers and parse would provide API, database, push messaging and so on.

That said, I never used it, I saw it appear, had a look, decided what it offered was too rudimentary to be scalable, and moved on.

That said, as an open source offering, it's quite interesting.

This post answers the basic question, what is parse:

http://blog.parse.com/announcements/what-is-parse-server/

> Parse was an API as a service. The idea being that you don't need your own servers and parse would provide API, database, push messaging and so on.

I'm still unclear. It's some sort of hosted database+services?

I'm also confused. "API as a service" sounds to me like "service as a service"... ok, it's a service, but what does it do?

From my understanding, it provided services that you would have to create from scratch in your own infrastructure that would be a significant undertaking. For instance, push notification in iOS is a bit of a nuisance if your app really doesn't rely on a complex server back end, but you would like to still add push notifications. Parse did this portion for you, so you could focus on the product. I could be wrong though, I looked at it a year ago, and my memory isn't what it used to be.

This seems like the best documentation http://parseplatform.github.io/docs/rest/guide/

From my reading it seems like a generic rest service. I suppose like COTS for rest services.

The first iOS app I built used parse for the entire backend. We basically used it as a database in the cloud accessible by multiple clients (it can accommodate fancier uses as well). We didn't really run any custom code on the server side, Parse basically provided access to a shared db across our client instances. It allowed us to build a simple location sharing app in a few hours.

It was basically a CRUD API as a service; simple object storage and retrieval via HTTP, with goodies like validation and nested routes (joins) and such built in.

And if I download the open source code, and run it on my own server, is it a service as a service as whatever-the-opposite-of-a-service is? I'm confused...

You're thinking too small. Support it multi-tenant on a fleet of servers and sell it to customers, now you've got a service-as-a-service-as-a-platform.

> I'm also confused. "API as a service" sounds to me like "service as a service"... ok, it's a service, but what does it do?

perhaps this http://rawrmaan.com/why-parse-failed/ might be a better explanation ?

I would call Parse a "Backend as a Service"[0], akin to Firebase[1]. "API as a Service" is more like Apiary (bought by Oracle) or Apigee (bought by Google).

[0] https://en.wikipedia.org/wiki/Backend_as_a_service

[1] https://firebase.google.com/docs/

No, Parse was a Backend as a Service (https://en.wikipedia.org/wiki/Backend_as_a_service), like Firebase, Kinvey, Telerik Backend Services or Backendless.

nowhere in there I was able to find what's Parse

This is a major failing of a lot of open-source projects and a lot of real companies as well. Fortunately Wikipedia often provides some background. It's my go-to place whenever I'm confronted with some un-navigable home page filled with hipster jargon about how a company wants to "empower" me with "cloud" "solutions".

Here's a brief history of Parse: https://en.wikipedia.org/wiki/Parse_(company)

Parse.com was a BaaS(backend as a Service) acquired by Facebook in 2013. Using the platform was possible to build and host most of all your app backend(database, legacy code, integrations, Push notifications, send emails, social login, ...) and to integrate with your app front-end using the SDKs or even using a REST API. Parse Server is the open source version of Parse.com launched after the Parse shutdown announcement.

That cannot work at all!

See inside /bin/parse-server:

    require("../lib/cli/parse-server");

The same with the package.json, it points to /lib/index.js.

However there is no /lib folder, apparently its name is /src. So there is basically no possible way that is even able to run. How is this possible? Either someone linked /src to /lib (doesn't make sense) or they changed the name of the folder and didn't change anything else.

Files in src/ are run through Babel and output to lib/ as a prepublish step. The version that you download from NPM contains a lib/ directory.

https://github.com/ParsePlatform/parse-server/blob/master/pa...

That makes sense, I would have put them in /dist though

I have seen a fair number of "abrupt" and poorly executed shutdowns on HN over the last few years, and although I don't use Parse, I feel as though the team did a good job sunsetting this over the last year. Thank you for the product, the open sourced version, and for not ditching your community! Best of luck to everyone who worked on the team

They did some extraordinary work

Very interesting interview with Parse founder in its heyday: https://soundcloud.com/heavybit/caveat-founder-ep-1-featurin...

On finding an interesting market @ 13:30: Evidently the Parse folks discovered they were dealing with an agency building an application for the Food Network. The agency needed SLAs/enterprise contracts and Parse found a $$ customer base

Thanks mcescalante, we appreciate the kind words!

Thank you, mcescalante. We did our best to make the transition as smooth as possible.

Yeah, that's pretty impressive. YC should consider making it a requirement of funding that the components go open-source if they shutdown without acquisition, etc. Aside from collective benefit, a future, YC startup might get a head start from their docs or components. They seem to fund multiple startups in the same market segments at times.

That would likely be overly onerous...what if they use licensed 3rd party components?

And in such a case, an Open Source mandate would directly conflict with the financial interests of the investors (the time required for the effort takes away from the liquidation amount of the remaining assets.

It would only if the software source or patents compromised the value they gained from the business. This would be the case for some startups. It wouldn't be for others where brand, talent, & existing users were what they were after.

It also wouldn't take any significant time given developers could just push the final source and docs into a Github repo with a license. Or just dump it as a zip on the web. That's nothing. Also a good chance that at least one ex-developer would like to do it just so their work wasn't totally wasted.

How many production systems have you come across that could be dumped onto the public without any cleaning? Credentials, build systems, personal information, patent use, are a couple of examples that I've seen in prod code that couldn't or shouldn't be included.

Assuming the cost of open sourcing something is zero, even if it's just a zip dump, is usually not correct.

Fair enough. I forgot about the malpractice of putting credentials and personal information in the code itself. Companies doing that would have a hard time open sourcing the code. Others whose build system doesnt cleanly separate 3rd party or internal stuff might also have trouble. Patents I already handled by saying they simply don't release third party stuff that's proprietary. Patent-encumbered code or tech is one such thing.

So, yeah, I'll take those corrections.

They'd have to be left out. The rest could be open-sourced. If 3rd party stuff is hidden behind API, it could even be replaced with open-source stuff. That's not even necessary as my recommendation is to not overly burden the startups with this requirement. They just dump what's theirs somewhere under FOSS license. Others can do the necessary work of dealing with missing, 3rd-party components if they want to reuse the FOSS code.

But Parse was acquired by Facebook. So this clause wouldn't apply.

They did a great job with Parse server, but unfortunately for people who just wants their data they basically have been abandoned.

Exporting data in JSON format is no longer supported. The featured has been left broken without any explanation, and they disabled the ability to contact them in regards to data export.

You could very easily have created a free mLab account, migrated the data, and exported it from there...

A little Parse trivia a gathered from talking to (very capable) Parse engineers that now work at FB:

- Still the world's largest MongoDB user

- Had 1M apps, largest one with 40M users

- Server was Rails at first (24 threads max. concurrency), later rewritten in Go

- >40 MongoDB Replica Sets with 3 nodes each. Storage Engine: RockDB (MongoRocks). No sharding (DB-to-replica-set-mapping). Only instance storage SSDs, no EBS.

- Write Concern 1 (!) - some people complained about lost data and stale reads (slave reads were allowed for performance reasons)

- Partial updates were problematic as small updates to large docs get "write amplification" when being written to oplog

- Experienced frequent (daily) master reelections on AWS EC2. Rollback files were discarded -> data loss

- Special flashback tool that recorded workloads that could be rerun for load and functional testing

- JS ran in forked V8 engine to enforce 15s execution limit

- No sharding automation: manual, error-prone process for largest customers

- Indexing not exposed: automatic rule-based generation from slow query logs. Did not work well for larger apps.

- Slow queries killed by cron job that polled Mongos currentOp and maintained a limit per API-key + query combination

- It was planned to migrate Parse to FB's infrastructure but the project was abandoned

- Clash of clans used Parse for push notifications and made up roughly half of all pushes

I find this extremely interesting, as we are building a BaaS, too, but have a very different approach (Baqend). Coming from a database background, our idea is that developers should know about details such as schemas and indexes (the Parse engineers strongly agreed in hindsight). Also we think that BaaS is not limited to mobile but very useful for the web.

Also I think that providers should be open about their infrastructure and trade-offs, which Parse only was after it had already failed.

> which Parse only was after it had already failed

You just listed some pretty impressive metrics, Parse was acquired for $85M and yet, you still think that Parse failed?

I'm curious what you would call a success.

A product that is acquired and subsequently shut down because the acquirer has no interest in it is indeed a failed product as far as I'm concerned, even if said acquisition was a financial success for the investors and employees.

It was acquired because it was successful.

The failure is 100% on Facebook's side. They could have decided to keep the business up, they decided no to.

Thankfully, Google is doubling down on a similar business, so we have alternatives.

Of course, it's a little unfair to declare it failed. The exit definitely was impressive. However, the product still died. It's hard to tell without the real business metrics whether this was due to lack of sustainable revenue and growth or just missing alignment with FB's overall strategy.

From a standpoint of traction it was no failure. A lot of developers liked it for a good reason. However, the pricing model and the lack of performance guarantees lead Parse to being used for prototype stuff in the free-tier mainly. I think, if they had a little more trust in the capabilities of developers to know what they are doing, the service might still be alive.

Even with higher levels of "consistency" Mongo is still unsafe [1].

[1]: https://aphyr.com/posts/322-jepsen-mongodb-stale-reads

That is definitely true for some of the older versions of Mongo. Still, a quorum write concern will yield far fewer consistency violations. An interesting trade-off to take: losing a little data is better than losing a little latency.

While the Parse team did an excellent job open-sourcing the platform and providing ample notice, it was still a costly learning experience.

Seamlessly transitioning a large user base on iPhone and Android to our self-hosted Parse with minimal service interruption or missed push notifications required significant engineering and coordination. The transition involved more hours than the initial build.

While we did our best (email campaigns, push notifications, etc.) we still have a sizable number of users who use the app daily, yet haven't updated it and are still pointing to (the old) Parse. We didn't plan on Parse going away back then, so those are not graceful failures.

Users who did update the app were signed out (couldn't maintain the session in the switch), resulting in a lot of "I didn't get my forgot password email" questions to support and an unknown number who won't bother troubleshooting it.

With the information at hand over a year ago, I still would have went with Parse. It really did help us get off the ground quickly. Maybe we would have missed our window of opportunity without it.

I loved Parse from the time I first started using it in college. It started out as a really handy way to spin up small apps quickly so I could start beta testing my app quickly with real users.

One of the main problems though was that it really felt like just a prototyping tool to me, and I never really used it for real apps in production.

Thus, for my latest project that I've been working on for several months now, I've decided to try in every way to address that problem. I started a company called Scaphold.io (https://scaphold.io) and it's a GraphQL backend as a service platform. It serves to address many of the same needs of Parse and more. It combines all the best data modeling tools from Parse and real-time capabilities from Firebase to provide a high-fidelity app development experience that you can actually build real production apps on, with as much transparency to your data as possible. That's the mission that we have at Scaphold, and I'm excited to be helping all the stranded app developers out there that were burned by Parse shutting down.

Excited to see what comes next for the app development world!

I was wondering if you have a public policy in place which outlines what would happen in the event of a Parse-like shutdown or other end-of-company-life event occurring?

I ask in the hopes that it won't be taken as too negative a question but your company is VC-backed in the database space and we've lost a few too many of those this last year.

if you run a company or product, it's on you to make sure your data is recoverable and your product is fixable in the event of an outage.

expecting a vendor to tell you exactly how they're going to fold is something they can surely dream up and send to you so you feel better about the nature of the universe, but something you shouldn't really rely on.

in other words, assume the worst will happen, despite assurances of the contrary.

Great point. It is an inevitable concern with any hosted data platform. Though we do try our best to make your data as transparent as possible and are coming up with more and more ways so you can have tons of control over your data.

Fully agreed, I still find it helpful to judge the response and general attitude of the company in question though.

In this instance, it was exactly what I was hoping for.

the problem is in many circumstances the entire management or operations teams can be forcibly removed by investors etc. many of these companies are all volatile, high growth venture-backed companies with financial and corporate shenanigans being pulled left and right.

i wouldn't say the risk is attitude, or intentions. you know what they say about good intentions...

in other words, assume the worst will happen, despite assurances of the contrary.

And, just to emphasize, having a small company or product acquired by a big company is no guarantee. In fact it's oftne quite the opposite. E.g. Parse was acquired by Facebook, and then killed. Google has killed countless projects and companies. Oracle loves to kill products they acquire. The list is endless.

That's a very valid concern, and I appreciate you asking. One of the (many) benefits of using GraphQL is that it's an open standard.

And in the event of a Parse-like shutdown, migrating off of a hosted platform like Scaphold is much less painful since you could quickly spin up a GraphQL server on your own with the same GraphQL schema that you can easily export from Scaphold. Regarding the data you have stored in the system, we work hard to let you use as much of your own data as possible from various services across the web, so even if we shut down, your data still lives across those other service providers that you use. In addition, we'd be happy to give you a full export of your data in any format you wish. We use an underlying MySQL database behind the scenes, and migrating your data from one SQL database to another is much more structured than moving off of a Mongo database (Parse's data layer).

We're also pushing out more and more support for tying in your existing data hosted elsewhere on the web with advanced custom logic hooks that can tie into your other APIs and data layers as well.

Does this support multi-tenant apps? Most BaaS products I've seen assume that your account is hosting a single application and every user has visibility into almost everything. Versus an account that is supporting n clients, and each client has zero visibility into the data of other clients, unless via whatever secure mechanism they've granted permission for client X to see something within their company.

Parse was an amazing discovery when I was just starting out my dev career and I've used it in all of my major projects, but it had some serious shortcomings. I wrote about why I think Parse failed from a developer's perspective.

https://news.ycombinator.com/item?id=13522602

Why do you think Parse was a failure in the first place? Surely, Parse founders got a nice little cash out of the acquisition and Facebook got developers onboard and Facebook Login integrated onto many apps.

Well, he said "from a developer's perspective" ...

> Why do you think Parse was a failure in the first place?

Because the title of this post is "Parse.com is shutting down today".

Shutting down is not the same as failure

But it is a reasonable enough definition of it that we should be able to apply the principle of charity to calling it a failure, no? It is not something anyone would mistake for "success" on its own terms, even if the people involved did OK for themselves.

It really depends on the goal. It's a success if the goal was to build something to be IPO'd or acquired for benefit of investors and founders. It was a big success in that regard. It's a failure if the goal was mainly to benefit developers. That wasn't the main goal. Incentives like this are why I don't use VC-funded stuff unless I have a fall-back option. Risks also apply to proprietary software in general but many suppliers are more interested than startups are in sucking money out of you for long-term. Market leaders stick around longer.

People also die. By your definition, are all people destined to fail because we all die? Is no one worth remembering, or being called "successful"?

You posted that directly in response to a message that reminded you about the principle of charity.

Parse is just "doubling down on its amazing bet." No failures here!

When a marriage ends in divorce, it is fair to call the marriage a failure even if you get a profitable settlement from the divorce and even if you both go on to better marriages. Same reason.

Nice analogy, but we generally don't select development tools on the basis that we want to grow old with them.

I am increasingly inclined to do exactly that.

I'm on the same page. My "old = inferior" bias is swiftly wearing off as I gain more experience.

Why not? I wouldn't choose to develop against SaaS that I knew was going to shut down in 5 years. Parse also said they'd keep running after the buyout.

Speak for yourself, but the longer the tool has been around, the more I trust it. One of the chief selling points of learning something like Vim or Emacs is precisely that it isn't going to disappear next week and become abandonware (TextMate) or just lose interest from people because something else came along (Sublime Text → Atom/VS Code).

Same with a lot of developer tools. (This is sometimes bad. It is still taking a long time for people to migrate to Python 3.x, and the transition from CVS/SVN to Git and other DVCS was pretty slow.)

Depends. I don't know what the acquisition price was but given that they're shutting it down, I'm thinking it was in tens of millions range, which makes it an aquihire. Assuming they raised low to mid tens of funding, The investors probably have a 1x or more a preference on the sale. This means the leftover value is in the low to mid ones of millions. I love that you're getting 0.1% So we're talking like ones of thousands of dollars for an engineer after two years of work at probably less than market rate salary.

Given that your equity package at a large company would be is late and 50 times that per year yeah the engineers didn't come out ahead so it's a fail.

This is wildly wrong.

Baseless conjecture shot down immediately by someone intimately involved with the project is truly something beautiful to behold.

Are you at liberty to discuss the actual reasons and shed a bit more light on why things went down the way they did?

Side note, your product was unbelievably popular at my university. Parse made getting a functional DB up and running for courses and side projects completely painless and a no-brainer for tight deadlines and PoCs.

I have to agree with @csmajorfive - This is quite wrong from both a factual numeric point of view as well as guesstimates on what percentage that investors/founders/employees got.

I have no idea what you're talking about. Facebook is very generous with equity for employees and I"m sure the founders got a good deal.

I don't give a shit about the founders I'm talking about the employees.

I've spent the last 15 minutes on parse.com, github.com trying to find out what the parse backend actually is. Can someone explain?

I've definitely noticed of a lot of these companies that shutdown/close their doors, that it takes a long time to understand what they actually did/do. A businesses front page should explain what they do to the lay person. Even if your product is aimed at developers, most of the time it's not them buying, but their managers who will not want to guess what it is the company does.

Just 1 paragraph about what you do is all it takes.

This is so basic. It's amazing how many projects fail to do this. A common one I've noticed is to have a news feed or blog roll right at the top of the front page. It makes lots of sense to everyone involved in the project but none to potential new users.

Parse was a backend as a service that allowed for a cloud hosted database to be connected with web and mobile apps with simple JavaScript. It was a lovely tool for hackathons. They could also run arbitrary JS in response to events at scale. It competed with Firebase until they were acquired by Facebook.

It all makes me feel very stupid. I did programming since childhood and web since the beginning, I was clouds (virtualization) user even before millennium, I do backends for a living, saw a lot of JS code, know something about mobile apps, but I must join this thread.

"Parse Server is an open source version of the Parse backend that can be deployed to any infrastructure that can run Node.js" - each of these words one-by-one do have some meanings, but altogether they have none, neither your explanation for me. I fully believe it's totally my fault and it's hopeless, so please no reply.

"a cloud hosted database" + "run arbitrary JS in response to events at scale" covers most of it. It's a hosted database and server.

A cloud hosted database is accurate, but doesn't really describe it well. Amazon, Heroku and others also provide cloud hosted PostgreSQL, which is a very different use case.

Parse was a:

* cloud hosted nosql database,

* with client libraries for mobile platforms,

* direct write access from mobile apps, without hosting your own API backend in the middle, and

* some methods of securing this direct write access from untrusted clients.

Yes, but covering all the important parts exceeds the "couple sentences / one short paragraph" goal. First and foremost it's a DB + server + client libs (I entirely agree on that one, it's a major value-prop). Details beyond that are many.

Other important parts may include "runs on node.js", "server code in JS", "client + server define ACL per row", "push notifications", "amazingly, supports windows mobile", etc, depending on the viewer. That's what the rest of the documentation is for, e.g. in a features list.

Thank you. After reading their website, the GitHub page and all the comments down to this point, your comment is first thing which explains what Parse is/was.

Same here, arguably this is one of the most important elements on the front page, open source or not.

Look at this open source project for example: http://activeadmin.info/

The front page doesn't leave you wondering why the fuck do you want to use ActiveAdmin for.

This is a real bummer. I am not a programmer by profession (I am a PM), but I took time to learn Parse from scratch to quickly write my own app. I managed to launch my app on App store and everything was well till Parse announced their shutdown. Unfortunately, with a 1 yr old at home and a demanding work / commute, I didn't really have the time to learn about their migration guidance or educate myself on a new platform. So my App will stop working from today, which is a bummer.

For people who are more knowledgeable than me, I was really using Parse as a data store and using their APIs to store and retrieve data. I really liked their visual tools where I can create tables (classes) almost like in an excel document. This meant that I didn't have to learn a DB language. Is there a comparable tool that has similar features ? I have looked at Mongolab and Firebase and both seemed a lot more complicated than Parse. Or do I need to learn MongoDb now ?

If you have some time and are looking for something easy check out Proxima:

https://www.jamroom.net/proxima

It's really designed for someone that is not a developer first. I built a MBaaS quite a few years ago, and Proxima was something I built on the side since I wanted an easy backend to power my own app. I also wanted someplace to do documentation, support, newsletters, etc. - so the idea with Proxima is that you can focus 100% on JUST your app and Proxima will handle your backend/website, etc.

Note too that it's not a SaaS - you would download and install it on your own server (although we do offer the hosting as well if interested). It's open source and free, so check it out if you're looking for something easy. Feel free to contact me as well if you have any questions.

Hope this helps!

Found this on the Parse CEO's LinkedIn profile[1]:

"Facebook acquired the company for ~$100m in April 2013, intending to build a business akin to Amazon Web Services, and we operated for two years as a semi-independent subsidiary.

Facebook ultimately chose to exit the hosting business but Parse continues to thrive as an open source project with official support at Amazon Web Services, Microsoft Azure, Google Cloud Platform, etc."

Was this widely reported? I never knew that the internal plan with FB's Parse acquisition was to build an AWS competitor. Kind of interesting!

I guess it was viewed as a hedge in case the FB on-platform advertising revenue didn't grow as fast as they were predicting.

[1]: https://www.linkedin.com/in/ilyasukhar

A few points on our parse.com and migration to parse-server experience:

- I didn't like it initially. Not only the name (parse what?) but also because people started using it as a relational storage, which it clearly were not. Later, I became one of them (got convinced by colleagues).

- We recommended parse.com to a few clients, and they really enjoyed it.

- Had some issues with SDKs but we've been able to workaround them with the help of parse's team (pre and post FB acquisition).

- When the shutdown news came, that was a crossroad. Open source parse-server had got too many issues and we decided to postpone and not follow the recommended timeline. By august, we decided to stick to the open source version, but still no decision on using a third-party provider for the parse-server, mongodb, both, etc, etc. Also, the providers we had seen then turned the yellow light on due to the shutdown experience. By october, it was decided to follow the dark path of going on our own. For clients, we helped them on specific needs.

- The migration consisted of very minor changes in the "cloud code" part, and almost no changes at all to client apps. Difficult part will be to scale our infrastructure when needed.

BTW, we finalized the migration of our own app on saturday.

I know sales pitches are frowned on here but in the interest of helping out (with probably no return based on most users' Parse instance sizes), I have to share this. We were in the same boat when Parse shut down so here's just another option for anyone looking to migrate their app away still.

We took the parse server and built a hugely scalable platform on AWS and made it free to signup. We're still adding features but if anyone wants to start using it, it's in Production and available via http://octobas.com

You can also migrate your app to any externally hosted MongoDB service (like mlab.com) and simply connect your MongoDB instance to an Octobas.com Parse Application. (still for free under the base plan.. this method actually works out even cheaper when you scale up).

I just want to say thank you to the HN community. We learned a lot in engaging with folks here over the years.

Hi Ilya, You've really done a nice job with this transition, so rare to see people caring for their users until the end and keeping their word.

I am curious if you've ever looked at PostgREST, i think i've seen Tikhon among ppl who starred it on github. Any comment on it? Thanks

So the alternative options are:

- pouchDB - https://github.com/pouchdb/pouchdb

- RxDB - https://github.com/pubkey/rxdb

- gunDB - https://github.com/amark/gun

- horzion - https://github.com/rethinkdb/horizon

- firebase - https://firebase.google.com/

Kind of strange that you just threw in RxDB (your own creation?) and GunDB (which is easily torn apart as snakeoil whenever it appears on HN) along with the rest of them.

Yes RxDB is my creation. Didnt know that GunDB is not liked here, do you have a link for me?

I just wanted to have a next-to-complete list.

Why do you descibe gunDB as SnakeOil? it is a perfectly good product

Not understanding the idea here. PouchDB isn't a BaaS. RxDB is a wrapper for PouchDB, correct? PouchDB is a great project, so not criticizing, just not sure what criteria you're using.

Couchbase fits the bill as well, and has serious real-world deployments. https://developer.couchbase.com/mobile (Yes, I work for them.)

Thanks to all contributors that made the transition to open-source possible, parse-server is far from dead, getting daily improvements in performance, extensibility (Postgres, push notifications queues...) and ease of use.

Parse is dead, long live Parse.

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

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...

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.

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 :)

This makes me wonder. If my startup reaches a certain amount of success, heck if only 5 customers, and for some reason I need to shut it down, what's a graceful way to deal with it.

I can give each customer all of their data back in a nicely formatted zip file etc. But is that enough? customers are more likely to want an equivalent service (remember the Google RSS reader fiasco?). Even if a customer finds an alternative service on their own, there should be a way to import the said zip file from their previous services. This brings in the idea of "service interoperability" (and related import/export) among startups that have no relation to each other. Apparently, standardizations like JSON etc, should make it easier.

Looks like a huge blind spot that the startup industry doesn't pay attention to. (Graceful shutdown and graceful import/export built in as a rule rather than the exception).

The export data feature has been broken for months — it’s stuck in the “waiting to begin…” phase. Is there plans to allow people to export their data?

I’d like to get my data out, but both options for exporting data via the dashboard are broken. They also disabled the ability to contact them in regards to the export data functionality.

uhhh...sorry to say but I don't think you're getting that data out anymore.

>When your app is disabled, you will not be able to access the data browser or export any data, and your applications will no longer be able to access the Parse API.

The apps were not disabled. The export feature hasn't been working because of a bug on their end. It seams like the claim that Parse "firmly believes in data portability" is complete BS.

The data export feature was replaced by the database migration tool we launched on January 28 last year. We highly recommend using the database migration tool as this will ensure that all of your data is copied over and synced to your new database prior to switching traffic over. Tons of apps have migrated in the past year using the db migration tool.

It's terrible that you aren't allowing data to be exported anymore. You shouldn't need to setup a server and go through the migration process just to get your data out.

The prior export feature that allowed data to be exported in JSON format was great, but that was left broken without any explantation.

Email migration@parse.com for generic last-moment migration assistance.

Thanks, but unfortunately they just replied with a canned email about their migration guide.

There doesn't appear be any way to simply export data anymore.

I would like to make an appeal. Let's use this post as a great recognition for the Parse team hard work and share also our lessons learned using Parse/Parse Server as a Backend. Thank you, Thank you guys. @csmajorfive, @gfosco, @laker, @HectorRamos,@jamesjyu, @flovilmart ... and everyone else

Thanks for the shoutout, but I'm not part of the parse team :)

Yes, you are! Parse Server Team :)

Thanks for the shout out!

Ah yes, the day that so many unsupported apps stop working.

As for iOS apps, I imagine Apple's new attempt to remove unsupported apps from the app store will result in many of these apps getting the boot soon.

I've already seen the notification when opening an app that it might perform slowly since it is not supported (or something along those lines).

I've seen a notification like that, but it had to do with an App not being compiled for 64 bit architecture.

Quick... everyone run to www.graph.cool !! It's parse but for GraphQL!

The way you phrased it almost seem sarcastic in the context of this thread, although i think you are actually recommending them :)

They offer a interesting product but i think at this moment it has the exact same problem that Parse had (my other comment in this thread), you don't have access to the raw data, hope they will do that in the future (provide direct access to the source database), it will certainly be a more interesting/flexible service

Hi ruslan_talpa, I'm one of the founders of Graphcool. Thanks a lot for your feedback. You're totally right: Not having direct access to YOUR data is one of the main concerns about BaaS which we'll address at its core over the coming months.

I'd be very keen on hearing your experience getting started building something on Graphcool!

Thanks a lot for the shoutout, bh13731. The sunset of Parse and the rise of GraphQL was indeed one of the reasons for us to start working on Graphcool. We have a lot of customers who migrated from Parse to our platform which was a good usability benchmark for us.

In general GraphQL provides many advantages over a traditional REST like API provided by most BaaS. It frees you from the need for proprietary SDKs and reduces vendor lock-in.

Here is a quick way how you can get started: https://www.graph.cool/docs/quickstart

What are the founders next up to ? Interesting to hear about it.

Ilya's a VC now. http://venturebeat.com/2016/08/09/parse-cofounder-and-y-comb... James and I are still working at Facebook, on other projects.

Cool. How big was team when parse was bought by Facebook ?

24 people

Can someone clarify: does this mean all older versions of apps that were dependent on Parse are now orphaned?

That is, even if you've released a new version of your app that uses the open source Parse Server, any of your users that haven't updated to the new version now essentially have a broken app?

Yes

Well, that's quite unfortunate for the millions(?) of users whose apps will break today for reasons they won't understand.

Updated my Parse app several months ago away from Parse, but up to 600 DAU's were still using the old versions - I'm not sure whether they'll fail gracefully or not. You can't convince some people to update their apps, they think it is a conspiracy!

I remember when Facebook announced the acquisition of Parse. I was talking to some devs who really like Parse. They were pretty down about the news. The comment that really struck me was, "Now that Facebook bought them, I don't trust Parse anymore." A lot of devs seemed to sour on Parse, but Facebook seemed to push back by seeming to say that Parse was going to be around for a long time. Well, that was interesting.

A key takeaway from this; and one of the main reasons parse failed-- don't name a company or service after an extremely generic programming term.

Parse failed for a lot of reasons but I hated it because the documentation was terrible at the beginning and used to get me stuck in a forever loop of links. So I searched for additonal info:

"Parse javascript"

"Parse website library"

"Parse programming"

Admittedly contrived examples. But the point i am making is pretty clear.

That sure wasn't one of the main reasons Parse failed! It is annoying though. Perhaps we should have taken over some similar term, like "golang".

I have been using Sashido for a while for two different apps.

I am surprised about their service. The migration was super easy and straightforward and it is as easy to use as Parse.

I would love to see them offering a cheaper option for very low traffic apps but 5 dollars for migrated apps is a fair rate that I can afford. Another option would be some discount if you already have apps hosted with them.

While I know there are people who say they loved their Parse experience, I suffered greatly. There are bugs, there are issues, there are simply things that either don't work or are very hard to make work.

On top of it, architecture of the app I was trying to make work, was... challenging.

Anyhow, not a big fan, but it is open source and now you can fix those issues if you care about them.

It's super sad. It was so great when it was hosted by them. I am bit worried about what is going to happen to the documentation.

I am currently using SashiDo which I quite like. Excellent support. Before that, I tried NodeChef, but I have found Sashido a little more intuitive. Your millage may vary.

At my last job one of my biggest projects was a migration off of parse to a postgres backend. Fun times.

I liked the graceful shutdown that Parse had. Always thought that FB would just unplug the wire

Hope facebook will opensource the original Parse platform. Less likely, but just hoping.

Does anyone know if the same admin UI (tables, settings) is available with Parse Server?

It is, it's called parse-dashboard and it's open source as well.

By looking at their websites i have no idea what their product is about.

This looks like it does similar things that Parse was doing: https://exis.io/

As a non-developer who found Parse extremely easy to use, is there a similar product in the market that I can switch my iPhone app over to?

So we know there is a Go version somewhere I wonder why they didn't opensource this instead of rewriting everything to nodejs...

Assuming this is true, probably due to the fact that most apps using Parse are already in Javascript.

The backend for running half a million apps doesn't look anything like the backend for running a single app. Open-sourcing the actual Parse stack was not an option, and no one would've put in the effort to actually run the dozens of components involved. I started from scratch because that was the only way.

The hosted parse.com service is meant to support hundreds of thousands of apps. It was not really meant to be self-hosted by individual developers serving a couple of applications.

Thank you for your service Parse. I'll me

can someone tldr us on what happened to parse?

Facebook bought it.

facebook shut it down

Founded 2011, sold to Facebook for $85M in 2013, folded by Facebook in 2016 (though the software was released as open source).

Technically I believe the software was re-implemented as open source; the initial release didn't measure up compared to what Parse offered but the project has grown since then.

Facebook decided it wasn't worth it to continue maintaining Parse so they shut it down and open sourced all the code. Simple as that.

I am curious to know why facebook bought it in the first place

Pbly talent grab and also it gave them a view of up and coming apps they could target for acquisition: http://www.businessinsider.com/why-facebook-acquired-parse-f...

Facebook bought it. Parse was highly coupled to AWS at the time. They spent some 3 years trying to get it to run on Facebook's cloud, and apparently failed to do so. Facebook decided to cut their losses, and shut it down.

We did have many technical challenges (as would be expected, really) but that wasn't why it ultimately went away.

Parse is not that challenging that you can't reimplement it in any platform you choose, especially in 3 yrs.

Anyone want to explain to me like I am five, because I got no fricking idea what it does and why would I want it?

> why would I want it

Well, the title says its shutting down so you probably don't want it. If you don't know what Parse is, this news doesn't affect you.

The open source Parse Server offers more benefits than hosted parse.com. Many of the benefits are outlined in this blog post: http://blog.parse.com/announcements/what-is-parse-server/ Whatever you are building with Parse Server, Nodechef can help you get there faster. https://www.nodechef.com/parse-server

Are you a nodechef cofounder by any chance? I host with nodechef and am happy with them so far.

Yes, I am one of the co-founders. Thanks for hosting with us.

There are a lot of comparisons between the Parse Open Source and Parse.com as a service ...

Hey maybe tone it down with the sock puppet accounts.

The Parse folks seem to have handled this reasonably well but this is the perfect illustration of why building your own application around a third party service like this is not a pure win. There is a tradeoff and it can in fact bite you.

It's a shame so many people think of the Data Access Object design pattern as something only Java developers should be using. Using DAOs to provide database-agnostic access to your data takes a few moments more at first, but then when you need to move data from $DB_X to $DB_Y, there's a lot less wailing and gnashing of teeth.

Mediocre link on the topic: https://en.wikipedia.org/wiki/Data_access_object

I'm not sure what your point is. Do you mean that if only people used DAOs then Parse shutting down wouldn't be a problem? It only encapsulates the problem. You still need to go through a process to switch from Parse to MariaDB or whatever else you switch to. You just don't have to rewrite your whole application.

I'm in favor of DAOs and use them myself but they don't have anything to do with what I was talking about.

You made the point that the tradeoff can bite you. I mentioned DAOs as a way to make that bite less painful. Not a hard connection to make.

That's what I assumed, but it wasn't totally clear that was your intention.

Like I said it does help but it's not a panacea.

Why do I feel like this post is getting brigaded by Sashido?

Because it is. Makes me begin to regret my decision of migrating my parse server to them, but I will say that they did make it easy to migrate over and answered my questions promptly.

I was about to say the same thing. At this point I can't tell who is genuinely recommending me a service and who is shameless plugging.

What an incredible journey!

I read this as "Paris is shutting down today"

I guess my parser is offline too...

Check out the Parse Migration Guide to migrate away without any downtime - http://www.parsemigrationguide.com/

Reply on news.ycombinator.com