This, along with the database migration tools released earlier, allow developers a full migration path to move from Parse hosted data + API to their own infrastructure.
Over the weekend, I set up a website & app on a $5 DigitalOcean box running Parse and Mongo locally.
Kudos to Parse for providing an open source path forward. I know a lot of enterprise users who will only look at fully open source stacks, for a variety of reasons. It's good they are giving users a year to migrate. I expect Couchbase Mobile to see a lot of evaluations as this process plays out.
I will be watching to see how the community grows. It looks like the ExportAdapter.js module in parse-server is low hanging fruit to connect to stuff like Couchbase Sync Gateway, which would give access to a multi-vendor ecosystem including IBM and Apache.
[Full disclosure: I'm a FT Couchbase mobile developer]
Agree 100% -- Parse deserves huge kudos for that move.
Ex-Parse customers should definitely check out Couchbase Mobile, which has some functionality overlap with Parse and is already open source with several repos on github:
Sorry my mistake. They have just open sourced the server not the dashboard. But some one has said they are going to open source the dashboard and all soon.
Hacker culture of Facebook makes it really valuable company in terms of engineering. Dropbox and Google (Mailbox & Reader at least) should learn something from them. Incredible move and good luck in future endeavors!
Alas, open sourcing Reader wouldn't have done much: the code's all tied heavily into Google internal infrastructure. (Full disclosure: my team pulled the plug on Reader.)
Hey everyone looking for a migration path out - we have a “DevOps-as-a-Service” model where we can migrate Parse folks to AWS (not DO unfortunately) with full infrastructure automation, immutable infrastructure, autoscaling, chatOps deployments, monitoring and alerting, etc. for a flat rate. We have a platform that we’ve built that makes this possible - think of it as a Django/Rails/etc. for AWS: https://www.reactiveops.com/devops-as-a-service/
Although we have a framework, it lives in your github and runs in your AWS - there's no lock-in whatsoever. Ping me at matt [at] reactiveops dot com if you're interested!
I guess the time spent ( a year ? ) on the Go version didn't help feature wise. The product didn't evolve that much in the meantime.
I hope you provide a solution for cloud code and webhooks , webhooks at least , since cloud code is just javascript. Please be sure to host the documentation somewhere, like github pages.
Good luck for your next project. I'd love to read a "post-mortem" once the service is definitely closed.
It's sad that you are shutting down but I think it's awesome that you are releasing the platform source. Who knows, this could be the birth of a great FOSS project.
It really sucks Parse is closing down, it was one of the best alternatives to Firebase, indeed better for straightforward REST use cases, and I really enjoyed using it.
It's nice that you've released an open source migration path. I hope somebody else can fill the niche of a fully hosted API-as-a-service. Best wishes.
Migration is based on data size, but setting up the API server on a new VPS is quick... I'd say less than one hour from a fresh image on Digital Ocean. I'll try to publish a guide for that part.
It'll really depend on your app, and how many features you used at Parse. In most cases, it should be easier than rewriting your entire app with Firebase, but you should carefully look through the guide and make that decision yourself.
What about push notifications and Parse Config? Social apps that triggered push notifications now loose that functionality when moving to Parse Server, right?
Also what about security? One of the beautiful things about Parse was not having to worry about servers and the security of back-end because you knew Parse was on top of it.
Depends on your viewpoint: One of the beautiful things about having your own back-end is not having to worry whether or not some 3rd party team is not neglecting security of the back-end because you know you are on top of it.
You sound like somebody who feels comfortable handling security, but for boostrapped and/or a self-funded or even small funded startups, that's extra money that goes to plug a major whole that didn't exist with Parse because they made user authentication, permissions, and security simple.
I'm no security expert. So now instead of concentrating on growing the user base, gaining traction and making the best experience possible for our users, that means finding, interviewing, and hiring more people to handle back-end security which takes a lot of time out of improving the product.
How time consuming on a hours per day would it be to stay on top of handling security on your own? How many engineers would it take and at what cost per engineer?
Thank you for releasing tooling to deal with migrating as well as releasing the server itself.
Too often services don't think about the full exit / shut down strategy and as disappointing as it is to see Parse go, it's nice to see it will actually live on in a way that can't be shut down by a corporate decision.
I tried to use node on a $5 DigitalOcean dropplet a couple of times but whenever I tried to run npm to install something, it would run out of memory and be killed. Frustrated with this experience, I have stayed away from Node.
This, along with the database migration tools released earlier, allow developers a full migration path to move from Parse hosted data + API to their own infrastructure.
Over the weekend, I set up a website & app on a $5 DigitalOcean box running Parse and Mongo locally.