Hacker News new | past | comments | ask | show | jobs | submit login

[dead]



But that's a thousand lines of code I don't have to write. And integrations I don't have to do. And libraries for lots of platforms.

I think you're undersstimating the added value – the point is that people don't have to bother setting up and maintaining all of those moving parts with a service like firebase.

Case in point, I was building a small real-time web serice this weekend; it's exactly the sort of thing that Firebase would be great for. But given that I couldn't run it locally, and that there's no migration path if they were to acquired and shut down, I had to implement a half-assed solution on my own. If Firebase had been open-source, I'd almost certainly have ended up forking over cash for them to host it anyway.


The project in which I implemented this toolset is working great and it only took me one weekend to implement too. I am not saying Firebase is inferior at all.

Just, for my situation, I am not sure why I need to pay for that functionality when I can literally set it up in one day vs reading the documentation on how to set it up on Firebase in the same time.

I also control all outcomes and avoid ones like this where Google could potentially take over control of a large portion of your app.

My server side code is about 100 lines. This controls a chat server, chat rooms, youtube video commands. And its currently working just fine with 4,000 visitors a day on a vps that cost $5 a month.

Why not learn how to do it yourself? Especially if you already have vps. I am using varnish with multiple sites and it took a couple hours to set up. I am really confused on this.


I think you're vastly underestimating what Firebase offers, which you presumably didn't do in 100 lines of code:

1) Full user management services, including registration and password recovery 2) Extremely fine-tuned access control per resource 3) Complete, tested front-end libraries for AngularJS, Backbone, and other popular frontend libraries. 4) Much more reliability than socket.io in providing cross-platform, cross-mobile real-time messaging (believe me I've used and tested socket.io). socket.io may or may not work on a given platform, and it's no longer a very active project, either. 5) Full admin panel for database, including real-time data updates.

Look, for a chat app, you're absolutely correct that Firebase may be overkill. But very few of us that rely on Firebase for applications are limiting ourselves to chat apps.

That said, I'm not happy about this acquisition. And this is probably the last time I'll be burned like this by a PaaS company. I saved a lot of time by going with Firebase (much more than 100 lines of code) but I'm questioning whether it was worth it.

PS: I didn't downvote, although I was tempted after reading your "Why not learn" remark. I think you're right in the end that open source is the best solution, but you're very wrong to assume that people are using Firebase because they can't quite figure out how to make a 100-line Node app.


Socket IO is definitely an active project, the last commit was 9 days ago today.


Yes, it's picking back up now, but for a while it languished (half of 2013 with no commits, for example).

Also, check out the number of issues, some of which are pretty significant (although there are tons of ridiculous ones there, too). But if they're catching up -- and they appear to be -- that's great. It's a great project.


Don't forget about persistence. Creating a horizontally scalable database isn't likely to be a trivial matter. Somehow I don't think Twitter Bootstrap is going to be much help there.

Firebase has solved many harder problems than you and I are ever likely to have to deal with and they deserve full credit for that.


We don't know how "solved" these questions are because it's closed source.


Bootstrap and Angular? Why? I'm pretty sure the core idea of FireBase is being usable with any JavaScript client-side.


I don't see MongoDB. Is that on purpose ?


+ Redis


When building our realtime platform we quickly realised socket.io fell over spectacularly with serious traffic, and that all other hefty realtime services did not use it.

There has been lots of movement with the bigger release but nothing that has interested us in going back to it.


so what did you use ?


Well the memory leaks and approach to fallback connections led to it being more sensible to roll our own.

We've only needed to handle concurrent connections in the 1-10k range though.

There are really better c++ and erlang implementations we've investigated but won't pull those off the shelf till needed.

Obviously there's loads of great realtime-as-a-service offerings like Firebase and Pusher that make sense for a lot of use cases, just not ours.

We were always uncomfortable with relying on a third party for a core aspect of infrastructure, and this acquisition introduces uncertainty that we don't have to worry about.


I've not tried it yet, but Poxa [1] looks quite promising: it's an Elixir app that is supposedly compatible with Pusher libraries.

[1] Poxa: https://github.com/edgurgel/poxa




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: