I used Parse for a dozen projects, but none in production, and all were free. To be honest, I loved how Parse allowed me to focus on the App/product without having to worry about APIs and backend.
However whenever I'm serious about an App I end-up investing in some PHP or Node .. This is probably true for a lot of people and this is why it is probably shutting down.
ymmv but we had a lot of problems with extreme slowness and downtime when using parse, it made development a bear and we were only using it for some testing. We wouldn't use it in production after our experience.
I disagree that Parse worked out badly. Now that parse-server is open source, the ecosystem is stronger than ever.
I hesitatingly and begrudgingly used parse while it was still hosted by Facebook. At the time my biggest and only problem with it was the vendor lock-in. Now that it's open source, that problem no longer exists, and all the great tooling is still around.
I'm happily using it on new projects. I suggest taking a look and trying it yourself.
I wouldn't write off Parse's value because one client was rough around the edges. I suspect the SDKs will become much more stable and usable now that the community can help contribute to them.
If you can find a part-time engineer that can build and maintain a backend with all of Parse's features, you should absolutely do that.
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.
Not their core business? Their version wasn't profitable enough?
Hadn't really read about Parse before. It seems it was primarily aimed at mobile developers. Did it have significant use-cases beyond that? In comparison, AWS Lambda, Google Functions, and Azure Functions seem more generically applicable.
I'm writing a pretty complicated application using parse. It's been great so far. I've been a very vocal non-fan of their iOS SDK though, so much so that I'm actually dropping it in favor of a custom written job using their REST API instead. But besides that one thing, it's been fantastic.
The new Cloud code stuff they just added is awesome.
I spent 10 years doing heavy backend shit until about 5 years ago when I switched back to native front-end development. I still am having to write a service here or there to cover some holes that Parse doesn't cover for this application, but those are pretty small holes.
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.
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.
I really wanted to like Parse, but I saw a startup get burned badly by it recently. It works great as a fast way to get your app up and running, but it absolutely falls flat on its face as soon as you do anything more complicated than a basic read/write interface.
The real problems show up when you've all of a sudden got these old apps out in the field with no way to upgrade them to a newer version of the DB. If you aren't being diligent and making all your Parse DB calls through their cloud functions, you are guaranteed to end up in a situation where your older mobile clients are holding back schema and feature evolution. You can try to hack around it using triggers, but these are too buggy to be reliable.
Other examples of where Parse is painful:
- beforeSave/afterSave triggers are completely unusable! They are unbelievably limited and each one you add slows your app down by as much time as it takes to run. If you want to do something like add users to Mailchimp, you have now tied the length of time it takes to save a user to the length of time it takes to talk to mailchimp!
- There is absolutely no way to test your parse code other than uploading it to a parse app and hitting it. You can hack together some node code that sort-of tests it, but it's nowhere near representative of what happens on the server.
- You can't manage Parse.Config programatically. There's a web interface and that's that. None of your config can live in your git repo because there's no way to read or write it from the command-line.
- The schema tools are pretty bad on the website. IIRC they introduced REST APIs to make changes to schema recently, but unless you plan on writing tooling around those, you'll be manually syncing schema between prod/staging at some point in your life and you'll probably also miss a critical column that got added.
- Parse has a bunch of weird datatypes that act strangely in their cloud code. Want to make a pointer and store it in a parse field? Construct its internal representation and set it! I wish I was kidding. If you construct a pointer incorrectly, it can actually create a phantom object in another table. Also wish I was kidding about this.
- createdAt and updatedAt are special and Parse won't let you touch them or set them. Heaven forbid you want to actually set these to a meaningful time other than the actual last time the record was written. Nope. So you end up making your own updatedAt columns and just using those.
For your own sanity: stay away from Parse. The range of use cases where it is actually useful is so narrow that you'll leave that very quickly unless you are building a toy app.
We gave Parse a spin, a few times actually. Mostly just for hobby projects. It was proposed for a production build but the general consensus on our team was "externalize anything you want except the core product...because we can't afford the implications of vendor lock-in there".
I don't know about treeline. At a previous company, we committed early on to using Parse and it was a disaster for us. Most of our problems as a company were not technical of course, but pretty much all our serious technical problems can be traced to us locking ourselves into using Parse, when it would have been 1000x easier to just put a server of our own making on Heroku and run a postgres database.
Our userbase was TINY (so you think scaling should not even remotely be an issue), but we had constant downtime with Parse; not to mention we observed between 1% and 3% of all requests to Parse failing for obscure reasons (and it was never clear if it was just our node, or if it was global). I seem to recall the Parse team fixing these, and then repeatedly rolling back their fixes since they would inevitably cause something even more catastrophic to happen. I am sure all of them were working really hard, and I don't want to say anything to make them feel bad, but honestly, the class of problems that plagued Parse (at least at the time I was familiar with it) did not inspire confidence. It is possible that it is much better now; I have not used it in months.
Parse is a lot of fun for quick prototypes and demos, and I recommend it for that if you find yourself wanting to iterate quickly and repeatedly on such things, particularly if most of your "innovation" is happening on a client (like an iOS or Android app, etc.).
I have been using Parse for a couple of years now. Some of my clients are currently on it and is being used in production. The most compelling part of the offering is a well thought out SDK which helps in time to market by reducing the development time. Parse has a lot of potential but unfortunately they will need improve in some areas pretty soon. The first issue is documentation, it is bad. What makes it worse is not being able to build a large enough developer community around the product. If Parse would only listen to the developers using their platform, take constructive feedback and improve their offering it will go long way. The response from Parse when things are bought to attention is much to be desired. Part of the problem is Parse needs to solve is to partner with companies/developers to help out their customers with the common issues that people face when using their platform and concentrate on the real issues of the platform. This should also help them with their support as well, which is bad even for paying customers. I really think Parse can learn from companies before them like Microsoft, Salesforce, Apple on how to go about building a strong developer community around a platform. I also think Parse can help a wider range of customers, like make a serious play in the enterprise market if these issues are looked into.
The initial magic of Parse was in the tight coupling of native mobile SDKs with standard cloud services. We released our first barebones beta SDKs long before we had a publicly documented (not to mention properly versioned and stable) server API. So for a while we iterated quickly underneath the hood and dragged people over to new versions of our cloud APIs with new SDK releases. It only became feasible to do this after we productized our server side APIs. And then it took some time to prioritize the project and execute on it.
I was a big stackoverflow user and then completely stopped using it when I switched to full time embedded C. Any APIs I was using or problems I hit were too niche.
Oh my goodness! This is something that I think you need a sizable open source community to build and maintain. This platform is not close to something you can rely on to build your new startup / business. I don't want to denigrate the efforts of the founders / devs but this is just an insanely huge amount of effort. Entire companies are built to just to provide a small subset of what Dark is trying to accomplish. The employees must be super stressed out! I would focus on maybe just the IDE and deployment. I don't see why you need an entire new language. I could see this being an advanced IDE to churn out server-less APIs plus some closed-source packages to provide magic. But this is just... woah!
I agree. A language or framework isn't a reason for failure, however, it's a pattern that I observed at Razorfish for a few years. Maybe the devs we had just weren't very good :)
However whenever I'm serious about an App I end-up investing in some PHP or Node .. This is probably true for a lot of people and this is why it is probably shutting down.
reply