4 ms·

I guess the long form of the question I'm asking is, "Can Meteor/Firebase be secure without adding back in a lot of the server-side effort that they were built

by tg3 15y ago

I guess the long form of the question I'm asking is, "Can Meteor/Firebase be secure without adding back in a lot of the server-side effort that they were built to avoid." Avoiding the server-side seems to be a central part of Firebase's pitch, but as you say, you have to have a separate access layer through which your clients pass their requests. Who designs what the access layer looks like? Doesn't that require that you set up your users' accounts in a Firebase specific way so that they can have appropriate permissions in the access layer (which is server-side, by definition)? And that's only considering actual authorization to change data on the server. One of the comments below mentions business logic that shouldn't be tampered with, like discounts. How can any business logic at all be entrusted to the client to perform?

eaurouge 15y ago
I don't think it's right to lump Meteor and Firebase together as you've done here. They are similar and the sets of problems they aim to solve may overlap. But Firebase is a "scalable backend for your web app" and Meteor "is a set of technologies for building web apps". Firebase is more like a platform and Meteor is more like a framework, or SDK if you like. If you want to get a web app up and running quickly without having to build a backend, Firebase would be an option. With Meteor, one advantage is that you can write your client code as if you were building a desktop app, i.e. with minimal context switching. You can imagine the database is local and that any methods you call on the server are like calls to a local library with a well-defined API. Meteor would provide the glue between client and server that allows you to do this. Regarding your question: "Can Meteor/Firebase be secure without adding back in a lot of the server-side effort that they were built to avoid?" I think the Firebase founder commented somewhere on this post on how they might do this. But for Meteor, (1) I don't think the goal is merely to reduce server-side effort (2), I expect Meteor would provide much of this out of the box and you wouldn't have to do more on the server than you would with say Express or Rails.
- tg3 15y ago
  You're right, I probably shouldn't have lumped them together. My question is probably more applicable to Firebase since they explicitly state that a goal is to eliminate servers (or at least make them optional).

by tg3 15y ago

eaurouge 15y ago

I don't think it's right to lump Meteor and Firebase together as you've done here. They are similar and the sets of problems they aim to solve may overlap. But Firebase is a "scalable backend for your web app" and Meteor "is a set of technologies for building web apps". Firebase is more like a platform and Meteor is more like a framework, or SDK if you like. If you want to get a web app up and running quickly without having to build a backend, Firebase would be an option. With Meteor, one advantage is that you can write your client code as if you were building a desktop app, i.e. with minimal context switching. You can imagine the database is local and that any methods you call on the server are like calls to a local library with a well-defined API. Meteor would provide the glue between client and server that allows you to do this. Regarding your question: "Can Meteor/Firebase be secure without adding back in a lot of the server-side effort that they were built to avoid?" I think the Firebase founder commented somewhere on this post on how they might do this. But for Meteor, (1) I don't think the goal is merely to reduce server-side effort (2), I expect Meteor would provide much of this out of the box and you wouldn't have to do more on the server than you would with say Express or Rails.

tg3 15y ago
You're right, I probably shouldn't have lumped them together. My question is probably more applicable to Firebase since they explicitly state that a goal is to eliminate servers (or at least make them optional).