Hacker News new | ask | show | jobs
by vning93 3433 days ago
I loved Parse from the time I first started using it in college. It started out as a really handy way to spin up small apps quickly so I could start beta testing my app quickly with real users.

One of the main problems though was that it really felt like just a prototyping tool to me, and I never really used it for real apps in production.

Thus, for my latest project that I've been working on for several months now, I've decided to try in every way to address that problem. I started a company called Scaphold.io (https://scaphold.io) and it's a GraphQL backend as a service platform. It serves to address many of the same needs of Parse and more. It combines all the best data modeling tools from Parse and real-time capabilities from Firebase to provide a high-fidelity app development experience that you can actually build real production apps on, with as much transparency to your data as possible. That's the mission that we have at Scaphold, and I'm excited to be helping all the stranded app developers out there that were burned by Parse shutting down.

Excited to see what comes next for the app development world!

2 comments

I was wondering if you have a public policy in place which outlines what would happen in the event of a Parse-like shutdown or other end-of-company-life event occurring?

I ask in the hopes that it won't be taken as too negative a question but your company is VC-backed in the database space and we've lost a few too many of those this last year.

if you run a company or product, it's on you to make sure your data is recoverable and your product is fixable in the event of an outage.

expecting a vendor to tell you exactly how they're going to fold is something they can surely dream up and send to you so you feel better about the nature of the universe, but something you shouldn't really rely on.

in other words, assume the worst will happen, despite assurances of the contrary.

Great point. It is an inevitable concern with any hosted data platform. Though we do try our best to make your data as transparent as possible and are coming up with more and more ways so you can have tons of control over your data.
in other words, assume the worst will happen, despite assurances of the contrary.

And, just to emphasize, having a small company or product acquired by a big company is no guarantee. In fact it's oftne quite the opposite. E.g. Parse was acquired by Facebook, and then killed. Google has killed countless projects and companies. Oracle loves to kill products they acquire. The list is endless.

Fully agreed, I still find it helpful to judge the response and general attitude of the company in question though.

In this instance, it was exactly what I was hoping for.

the problem is in many circumstances the entire management or operations teams can be forcibly removed by investors etc. many of these companies are all volatile, high growth venture-backed companies with financial and corporate shenanigans being pulled left and right.

i wouldn't say the risk is attitude, or intentions. you know what they say about good intentions...

That's a very valid concern, and I appreciate you asking. One of the (many) benefits of using GraphQL is that it's an open standard.

And in the event of a Parse-like shutdown, migrating off of a hosted platform like Scaphold is much less painful since you could quickly spin up a GraphQL server on your own with the same GraphQL schema that you can easily export from Scaphold. Regarding the data you have stored in the system, we work hard to let you use as much of your own data as possible from various services across the web, so even if we shut down, your data still lives across those other service providers that you use. In addition, we'd be happy to give you a full export of your data in any format you wish. We use an underlying MySQL database behind the scenes, and migrating your data from one SQL database to another is much more structured than moving off of a Mongo database (Parse's data layer).

We're also pushing out more and more support for tying in your existing data hosted elsewhere on the web with advanced custom logic hooks that can tie into your other APIs and data layers as well.

Does this support multi-tenant apps? Most BaaS products I've seen assume that your account is hosting a single application and every user has visibility into almost everything. Versus an account that is supporting n clients, and each client has zero visibility into the data of other clients, unless via whatever secure mechanism they've granted permission for client X to see something within their company.