[inlined]

I’m admittedly biased (early Parse employee, but not there by shutdown). Which part was a “fiasco”? As far as turndowns go I thought it was pretty damned fair: one year notice, a live data migration pipeline to self-hosted mongo, and an open source server implementation with a free license. Facebook even paid employees to continue working on the OSS components for a while till the community became so abusive that they moved elsewhere. The only thing I think could have been smoother is if Parse appIds were indicated by subdomain rather than header, which would have allowed switching over without client code changes and minimal cost to Facebook.

And does Dark even have the same sort of risk? It says your code runs on Google Cloud, which sounds like you get to walk away with your own backend if they shut down. Parse considered AWS an implementation detail, not a feature.

[vbsteven]

The fiasco was not on Parse's end but it was ours for locking ourselves into their platform.

The sunset window was indeed fair and as you described they provided a clear migration path to self-hosted mongo and eventually the open source server.

The main problem was the vendor lock-in where our code base was completely tied to their platform and the migration which cost a lot of developer/ops time was forced upon us. Instead of improving our product we had to spend our time and money on the migration to the open source server that was still in its infancy.

After running the open source Parse server for a while which was not without its issues we decided to rewrite the product in Java/Spring/Postgres and now we are free from the lock-in. If AWS decides to quit we can move it over to Azure or GCP without too much problems.

My original comment was not a stab at Parse but a word of warning for choosing BaaS services. Parse allowed us to ship an MVP that turned into a V1 in very little time. But that productivity came with a hidden cost. A cost that nearly killed the company.

Currently there is very little known about the Dark platform and language. From what I see it looks a lot like a next-generation Parse or Firebase and I am very cautious about adopting something like that again.

[ruperp]

However, there's always a new generation of developers who will inevitably make the same mistake that you (and I) did.

[inlined]

Thanks for the clarification. I’ve seen a shift to BaaSes that have a core of open source and self-hostable architecture that are wrapped in vendor-specific hosting that can improve performance, reliability, simplification/integration, and extra ancillary toys. See Kubernetes vs GKE.