Item — HN Reader

(Founder of Firebase here) - The answer here is an emphatic, unequivocal yes. What BaaS providers like us do is create generic apis to allow developers to do the common operations that already can do with their own server code. Everything that can be done with your own server code can be done with our server code. So if it's possible for you to write your own secure server, then it's possible for a BaaS to do the same.

The trick here is designing an API that is simple and easy to use that still works for a large set of use cases, and this is a very difficult task. Security is complicated, so making a generic, simple API tends to lead to APIs that apply to a reduced set of problems. Any particular BaaS system will likely not solve every security scenario available, but that doesn't mean ones can't be built that solve the vast majority of the scenarios that matter.

Firebase is working hard on building this API, and we're doing it with a lot of careful diligence and input from our users. We're nowhere near done with it, but we're confident that when we are, we'll have a simple, powerful security model that works well and is secure for most apps without needing any server code, and for those apps with more complicated needs, we make it easy to hook up your own servers too.|

Also, I'm very excited you got your app working in 5 minutes : )

4 comments

> The trick here is designing an API that is simple and easy to use that still works for a large set of use cases, and this is a very difficult task. Security is complicated, so making a generic, simple API tends to lead to APIs that apply to a reduced set of problems.

I completely agree, and I think you understand the issue.

I'm just not convinced that any meaningful definition of app-specific "security" can be achieved concurrently with the kind of simplicity that underpins your value prop.

If I have to go and cook up logic validation, ACLs, and who knows what just to make sure my app isn't trivially broken by anyone with a JS console, aren't I basically doing the server-side programming that your pitch says you're trying to eliminate? Except in a less familiar fashion?

I'm not saying this is unfixable; I hope you have novel insights, and I want to be wrong. But I've always been sceptical of the free lunch.

We're working hard to make this possible! Hopefully you'll be impressed with what we're cooking up when it's ready.

Out of curiosity, how complete is your security system right now? As in, if the code were frozen and documented as-is, would it be generally acceptable to use in production as far as you've tested (ignoring the occasional non-critical hiccup here and there)?

I noticed that your FAQ offers beta testers the option of trying out what you have. Does this mean that it's at least functional for simple/common use cases?

Agreed. If you can provide an generic implementation able to work across many applications, you save everyone from having to reinvent the wheel - at the cost of delegating a portion of your app to the service host.

The model I used in pageforest.com is to enable users to secure their documents as public, private, or shared access with other named users. Some apps don't fit in these neat categories, so a more complex system would be needed to support them.

I completely agree. It is entirely possible to secure with the appropriate API's.

Operations can be rejected by the server. If done correctly the client side can have an optimistic UI that is also secure. (Optimistic UI's don't need to wait for an ack from the server. They display local changes immediately and roll back if server denies.)

But that just adds to the complexity that the "BaaS" is aiming to remove?

What does BaaS stand for?

Backend as a Service, I'd guess.