Parse is shutting down today(status.parse.com) |
Parse is shutting down today(status.parse.com) |
I guess my parser is offline too...
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.
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.
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.
Mediocre link on the topic: https://en.wikipedia.org/wiki/Data_access_object
I'm in favor of DAOs and use them myself but they don't have anything to do with what I was talking about.
Like I said it does help but it's not a panacea.
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:
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.
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)
Attracting new users unfamiliar with the technology seems at best secondary ( and possibly, unwelcome) to the Parse Server community now.
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.
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.
You guys are aweosme!
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 .
See inside /bin/parse-server:
require("../lib/cli/parse-server");
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.
https://github.com/ParsePlatform/parse-server/blob/master/pa...
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
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.
- 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.
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.
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!
Because the title of this post is "Parse.com is shutting down today".
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.
"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.
Just 1 paragraph about what you do is all it takes.
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.
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 ?
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!
"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.
- 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.
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 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
- 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/
I just wanted to have a next-to-complete list.
Couchbase fits the bill as well, and has serious real-world deployments. https://developer.couchbase.com/mobile (Yes, I work for them.)
Parse is dead, long live Parse.
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.
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).
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.
There doesn't appear be any way to simply export data 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.
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).
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
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
I'd be very keen on hearing your experience getting started building something on Graphcool!
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?
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
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 :)
If prototyping tools are done right, I think they are valuable and awesome.
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.
The prior export feature that allowed data to be exported in JSON format was great, but that was left broken without any explantation.
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.
In this instance, it was exactly what I was hoping for.
i wouldn't say the risk is attitude, or intentions. you know what they say about good intentions...
I'm still unclear. It's some sort of hosted database+services?
perhaps this http://rawrmaan.com/why-parse-failed/ might be a better explanation ?
From my reading it seems like a generic rest service. I suppose like COTS for rest services.
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.
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.
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.
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.
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.
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.
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.
Assuming the cost of open sourcing something is zero, even if it's just a zip dump, is usually not correct.
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.)
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
So, yeah, I'll take those corrections.
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.
Happy to answer any questions, or get some current devs there into the conversation to help out.
Take a look at this video and tell me this query and the required data denormalization is acceptable.
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.
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.
Something as simple as filtering by 2 or more values becomes ridiculously tedious.
http://stackoverflow.com/questions/26700924/query-based-on-m...
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.
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