Don't be a condescending prick, especially when you're the one who's wrong.
Stop, just stop. This isn't right/wrong, because we don't even seem to be having the same conversation. Everything you talk about assumes and depends on having a server and server-side logic. Your arguments all amount to "I can totally do client-side-only, I just have to do X on my server". Like:
Which is then sent to the _server_ and put into a server-side key-value store with the username.
Right, so your solution for Firebase is that they should have more server-side stuff? Good, we agree. Wait:
We were specifically on the topic of adding price validation to a freemium Firebase application; you still have yet to explain what's stopping me from leaving the bulk of my code as-is and using AJAX off my _server_ only for the price validation.
What's stopping you is that in this scenario you don't have a server! So if you want to add this, you have to now add a server. Now you've got your MVP running on Firebase, and a new server-side setup, just to add a feature? Seems like a disaster.
(To be fair, Firebase are talking like they'll make some private quasi-sessions that could act as servers, but setting up conversation between them and the clients sounds like a recipe for callback spaghetti, at the very least.)
The point the OP, some other posters here and I am trying to make is that client-side sounds great -- it's way simpler, for sure -- until you start to think about security. Because, frankly, security depends on things not being in the client's control, and that means servers.
If you disagree with that, please email me, because this conversation is now adding no value to HN.
Sorry, I have no idea what you are shadow-boxing at, any more. There are questions over security with Firebase. They say it will be fine when they're done. You say it will be fine in 80% of cases if they implement your idea.
I suspect that whatever the final solution is, it is going to be just as complicated as what we have now. Security isn't easy. Disabling it sure makes for great demos, though.
Er...... I don't think you understand what Firebase is... Obviously they're still running servers; the entire service is basically hosted MongoDB with a clever Scala API and a JS library that further abstracts Socket.IO.
Jeez, HN needs a better system for nested replies. Anyway.
You seem to think it can be patched up by turning it into something else. Great, we agree that it doesn't work as is, then.
Well, yeah, of course. The whole discussion started off as a debate about whether and how they could go about implementing security after the beta launch.
It's pretty well understood by all parties (and admitted by the founders themselves) that security isn't something Firebase is currently equipped to handle...
---
Sorry, I have no idea what you are shadow-boxing at, any more.
I've gone above and beyond in terms of explicit clarity to un-derail this conversation. Which part of my solution are you confused about? (I don't think I was too technical, but I can explain in more detail if necessary.)
I suspect that whatever the final solution is, it is going to be just as complicated as what we have now.
Do you mean that my system would be too complicated for developers? (The operation seems pretty straightforward to me.) Or are you just implying that you think they'll go in a different direction which involves a lot more developer labour?
You have been saying it should be mostly possible. I am sceptical.
In that case, do you see a specific hole in my design, or are you just unclear in general about how it would be used?
Yes. The discussion was over whether proper security is something it could ever be equipped to handle in an all or mostly-client world. The founders have been saying it is (and pointing to Office as an example). You have been saying it should be mostly possible. I am sceptical.
Read their front page. "No servers, no server side code". Of course there are actually servers involved, but they're inaccessible by the developer.
That's the whole point of this post: how much access will devs have to the servers, and how? Until those questions are answered, explicitly explicitly, doubts hang over the whole idea.
You seem to think it can be patched up by turning it into something else. Great, we agree that it doesn't work as is, then.
So you're saying that all server-side data that all apps using Firebase want to store should be stored centrally on Firebase owned servers. i.e since trusted user/pw hashes must be stored on a server to be matched against and the only server we have is the one that Firebase provides, all apps using Firebase will store these hashes on central servers owned by Firebase.. That sounds like a really bad idea.
Stop, just stop. This isn't right/wrong, because we don't even seem to be having the same conversation. Everything you talk about assumes and depends on having a server and server-side logic. Your arguments all amount to "I can totally do client-side-only, I just have to do X on my server". Like:
Which is then sent to the _server_ and put into a server-side key-value store with the username.
Right, so your solution for Firebase is that they should have more server-side stuff? Good, we agree. Wait:
We were specifically on the topic of adding price validation to a freemium Firebase application; you still have yet to explain what's stopping me from leaving the bulk of my code as-is and using AJAX off my _server_ only for the price validation.
What's stopping you is that in this scenario you don't have a server! So if you want to add this, you have to now add a server. Now you've got your MVP running on Firebase, and a new server-side setup, just to add a feature? Seems like a disaster.
(To be fair, Firebase are talking like they'll make some private quasi-sessions that could act as servers, but setting up conversation between them and the clients sounds like a recipe for callback spaghetti, at the very least.)
The point the OP, some other posters here and I am trying to make is that client-side sounds great -- it's way simpler, for sure -- until you start to think about security. Because, frankly, security depends on things not being in the client's control, and that means servers.
If you disagree with that, please email me, because this conversation is now adding no value to HN.