Parse 2.0 | Hacker News Reader

Parse 2.0

medium.com

217 pointsgfosco48 comments

"Since these things happened on the same day, some have mistakenly assumed that they were related."

Huh? How could you not think two announcements about the same service on the same day by the same company were related?

Facebook totally could have spun this as "We're open sourcing Parse! (oh, and deprecating parse.com)" but a blog post called "Moving On" wouldn't have been the way to do it.

Regardless, releasing an open source version of the service you're shutting down is a hell of a lot more than most companies would do, so kudos to Facebook/Parse for that.

I guess I was trying to be funny and make a point at the same time... Of course people would think they were related.

The initial messaging could have been more positive, absolutely.

I do feel for your situation. It's apparent that this was the management's plan and you might not have been communicate to. Excited about Parse 2.0 nonetheless!

Out of curiosity, I thought there were a few blog posts about how Parse is written in Go.

But based on this blog post, it looks like you are re-implementing https://github.com/ParsePlatform/parse-server as a node app. Why not open source the original code?

It could be because Parse was engineered not to be easily deployed but heavily dependent on Facebook infrastructure or the code that is there isn't fit for release.

It didn't use Facebook's infrastructure: https://aws.amazon.com/solutions/case-studies/parse/

It was originally written in Ruby , then they rewrote the API in Go. I guess they can't opensource the Go code for legal reasons. Maybe the parse-server written in Node JS was an experiment they did before when they were still choosing a new technology for the rewrite.

The Parse infrastructure itself was written in Ruby then in Go. But the customer facing CloudCode feature was in a Node.js environment. Thus it makes sense that Parse Server which needs to run this cloud code would be in Node.

I think there are plenty of reason for this, and the question should be 'why open source the original code rather than having a clean start without all the dependencies and ugly things that accumulated over the years?'.

Once it's open, people will scrutinize everything, especially something as high profile as parse. They don't need publicity about commit message "Joe is so fucking stupid" that slipped away or something equivalent.

Fosco, you're doing a great job with this. Thanks for continuing to work so hard to help Parse developers.

Could this be even better than parse.com since you can program the server? That's what I never quite understood about Parse. It seemed like you had to do pretty much everything in the client/app which seemed like a severe limitation.

The cost of operations on a small dev shop of 1-2 people shouldn't be underestimated.

Pushing the need to be up 24/7/365 onto an external service with the manpower/funding to succeed at it reasonably well is generally worth it.

> Pushing the need to be up 24/7/365 onto an external service with the manpower/funding to succeed at it reasonably well is generally worth it.

Devops here. The only service I have ever found to have anywhere close to 5 9's of reliability? S3. That's about it though.

Fair enough but do you think a 1-2 man shop can get better reliability than a product like Parse if they are average app developers that don't have Ops experience?

EDIT Since I'm rate limited:

> I don't think any product exists that's going to remove the need for ops experience. I haven't used Parse, so I can't comment on its reliability.

If you are an app developer whose backend consists entirely of talking to an API, I'm uncertain exactly what "ops experience" on the server side you believe is needed?

I don't think any product exists that's going to remove the need for ops experience. I haven't used Parse, so I can't comment on its reliability.

> Fair enough but do you think a 1-2 man shop can get better reliability than a product like Parse if they are average app developers that don't have Ops experience?

I don't think that's ever going to be possible unless both people forgo sleep and are willing to drop whatever it is they're doing to attend incidents.

I'm really surprised by the number of responses of the form "but I could run that cheaply myself on my own server!" I see to online services.

> I'm really surprised by the number of responses of the form "but I could run that cheaply myself on my own server!" I see to online services.

https://en.wikipedia.org/wiki/Overconfidence_effect

Yeah. That was really where the host service has value.

Admittedly, if you know what you are doing, you can build a reliable, distributed backend but that isn't a skillset most App developers have.

It's not just about knowing what you're doing though, it's about having a team that can support the service 24/7.

Fwiw, I have a distributed service that runs 24/7/365 for years without downtime.

I've had ~4 on call events in 5 years and all of those I could wait at least 9 hours to resolve. Certain situations allow you to do that sort of thing.

That's the genius behind parse (from the perspective of their creators): they don't have to run your code, so they don't even have to think about all the issues that come with that (security, CPU usage, etcetera). Firebase used the same trick.

That's just not true. Most reasonably mature apps were running code on our servers via Cloud Code. And it's hardly genius or a trick to have thick client SDKs.

They do have think about some of those issues more, especially security if the client contains all the of application logic, hence the row level access control. And when you charge per API call CPU usage matters, a database update is significantly more expensive than a cached get.

It's genius to get started quickly, but quickly becomes an architectural nightmare. If you need to change a query and the logic is in the mobile app then its going to be days before Apple approves a new build, and even longer before the user updates to the latest version. If your logic is on the server side then you roll out the new code and you're done.

Parse offered Cloud Code though, which runs your own Javascript functions and could do so as background jobs.

We had a product called Cloud Code that was similar to Node (albeit way more limited) so you could run stuff on the server.

I think the idea is that if you're willing to program the server, you just use MongoDB or SQL or whatever. Parse is all about having the option not to deal with those things.

Repository: https://github.com/ParsePlatform/parse-server

Why not open source the dashboard code as well?

I have been looking at migrating options and would like to have something as close as possible to original Parse.com

The dashboard was such huge help in testing, debugging etc. Suggest opening that up too so other players can run that as well.

That is in the works. https://github.com/ParsePlatform/parse-server/issues/3

Awesome! I would love to see one of the providers take that up and offer that in the migration process.

One of the best things Parse offered was ability to purely focus on application code and not worry about anything else. Tech pundits may balk at this approach but for a startup looking for product/market fit, this works. Until we have that nothing else matters.

I'm curious as to why you decided to left out push notification. That was one of my favourite Parse features, and I think it's why a lot of people use it.

Was it too hard or time consuming to re implement?

Check the pull requests, as Push delivery is in-review and landing very soon. At least one developer has already pulled the diff and got it working.

There is an alternative universe where I push https://github.com/dgrtwo/ParsePy/issues/13#issuecomment-160... a little bit more, and actually complete the python server implementation of the Parse API.

I wonder what would be happening at this universe if it also saw this "closing née open-sourcing of Parse": would a competing implementation get sudden traction? Would I be selling bitnami images (that is what I was thinking about how to make money with it) for mobile developers who didn't want to mess with backend services? Would it land me a job on Facebook? Would I take it?

So... what is Parse? Neither the blog post nor the repo give any idea what you'd actually use the parse-server package for.

I guess the assumption is that anyone looking for parse-server has already used Parse in the past.

What you should've done instead is make another closed source Parse under a different name, get acquired for $X million, then do it again ad infinitum.

You can start by relabelling the open sourced Parse right now!

That's the great thing about open source: a project can outlive its stewardship.

It's great that the Parse server got open sourced, no doubt. But a lot of people rely/relied on Parse for sending push notifications... you know, that pesky little item listed as "unsupported" in the parse-server README.

What's the current best option for sending push notifications? Is there an equivalent to Mailgun, SendGrid, Mandrill, SES? UrbanAirship? Does Twilio do it? Or do you just go direct to Apple/Google?

We migrated to Pushwoosh – all good so far

Maybe hook things up to RethinkDB?

https://rethinkdb.com/blog/realtime-web/

I've had a lot of positive experience with Amazon SNS. It's reasonably priced ($1/million push notifications) and makes sending notifications as easy as hitting an HTTP endpoint. We deliver a couple million notifications a month and have had no problems.

Second that with our experience sending 1m push notifications a day to android/ios

Thirded. It was actually a little annoying getting the message structure right (putting an escaped JSON string inside of JSON isn't the most intuitive thing), but once I got that working it's been smooth sailing.

Why not make a relatively simple node app that hooks up with apples servers? It is (if I recall correctly) a very simple protocol and it is free, even if you send lots of notifications.

Take a look at the pull requests. Push is landing imminently.

We relied on Parse to send push notifications and since the announcement were looking for alternatives. We decided to go with pubnub (which FWIF we were already using for other stuff). I think it's worth for anyone who was using parse to check it out.

Reply on news.ycombinator.com