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?
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.
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.
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.
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.
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?
> 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.
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.
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.
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 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.
"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 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!
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.
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?
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?
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.
50 comments
[ 78.8 ms ] story [ 2255 ms ] threadhttps://rethinkdb.com/blog/realtime-web/
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.
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 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.
https://en.wikipedia.org/wiki/Overconfidence_effect
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.
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.
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.
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?
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.
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.
The initial messaging could have been more positive, absolutely.
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?
Was it too hard or time consuming to re implement?
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.
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.