[gkoberger]

Yeah, it sucks Parse shut down. But that's not an argument to avoid SaaS. My startup is built on over 20+ different third-party tools. It will really, really suck if any of them shut down... but I'd rather deal with that possibility in the future when we have more money and time, than struggle to build everything out ourselves now.

Like I said, it sucks Parse is shutting down. But in ~2 hours, you can get the open source Parse clone they released going and be back to new. Seems better to deal with that now than to have slowed down initial development by building everything in-house.

[bad_user]

> But that's not an argument to avoid SaaS.

Actually it is, at least the kind of SaaS / PaaS that locks you into proprietary APIs / tools. Speaking of which, Parse never made sense to me. I mean, you can quickly assemble the needed functionality from open-source libraries, deployed on AWS or Heroku, without the never ending issues, limitations or the lock-in of something like Parse.

You do need the know-how and that might take time if you don't have it, but on the other hand that technical know-how becomes your secret sauce.

Somebody wise once told me that the best product managers and project cofounders are highly-technical people, preferably former engineers. The reason is because imagination is limited by what you know is possible, which is the reason most non-technical folks aren't capable of proposing good solutions to their problems.

[Jare]

> in ~2 hours, you can get the open source Parse clone they released going and be back to new

I keep hearing this, and I have a hard time believing it. Are there any examples of a significant app/developer doing this? Sure a working Parse Server is easy to get up and running, but the reason someone wouold choose Parse was to avoid operations, and that's not a service you build in your company in 2 hrs. (as an aside, it looks to me like the Parse Server is a very limited subset of the real Parse)

[lacker]

If you have a small app and don't need to be careful about scaling issues, then 2 hours is pretty accurate I think. It's trickier when you have a large app, because with Parse Server you do need to handle your own databases and production environment. So I think some of the larger apps are either going to need to hire some devops folks, or make an arrangement with higher-service providers like ObjectRocket.

It has been less than a week, though, so we will see.

[arihant]

Parse Server uses Mongo, there are plenty of operations-free Mongo hosting options, like Compose. Also, Parse server code itself could be given to company such as Heroku or AWS beanstalk to host it for you.

[campers]

There's quite a few pieces missing from the open source Parse server. https://parse.com/docs/server/guide#migrating Analytics, Push (a big one), Config, Jobs. I've been building a mobile app platform on Parse for a while, so I'll have to re-build all the missing pieces for all my existing customers and to keep the new customers coming in. Its something I'd been planning/researching for a while for the next version anyway, the number of times I've said fcuk Parse! Now I have to hurry up and build the next Parse anyway at http://appstack.systems

[semerda]

If someone wrapped it as a microservice with containers and a deployment script for AWS then yes. Otherwise the configuration alone would take few hours. This then begs the question; was/is AWS or Google a better backend to rely on long term.