Live data from Hacker News

Introducing Firebase Hosting

firebase.com

61–70 of 79 posts

Re: Introducing Firebase Hosting

#62
I am building a financial services app and was using Angular and Firebase. I absolutely loved my development time with Firebase. It really complements Angular nicely and helped cement (in my head at least) what the role of the server in a modern app should be.

That being said, I decided that Firebase is not quite ready yet for my own app's requirements (for financial data I need data-at-rest encryption and on-premise hosting for my clients), but I wish them all the best and highly recommend them for anyone whose apps do not have the same constraints that mine does.

FWIW, my Firebase-like alternative is Node.js + SockJS + MongoDB. I'm looking into Feathers.js as well. It doesn't seem to be very widely used, but looks like it will provide some of the basics (service hooks, event hooks, etc.) on top of Node/SockJS that I will need.

Re: Introducing Firebase Hosting

#63
Congrats Firebase team! I've used Firebase hosting while it was in beta, and had a great experience. Very easy to setup and follow even for someone like me who has very little experience with servers/deployment.

They're also super friendly to their community and always responds to questions fast :-) would love to see more awesome stuff coming from them.

Re: Introducing Firebase Hosting

#64
post #60

Earlier quoted context omitted.

Take a look at the "Reading Data From Firebase" doc ( https://www.firebase.com/docs/reading-data.html ). If you've got some feedback on it or think it isn't clear enough, I'd be happy to chat with you and see how we can improve the docs.

Thanks for the response. I have, and its simple enough from the perspective of a developer that has been in the field for a little while, but since these services are getting more and more popular it seems like striving for absolute clarity might pay off in the long run. For example, 1. Its not totally clear that the url that you are supposed to use is the url that is generated when you create a new app and land insi…

I really appreciate the great feedback! I will take another look at the doc sections you mentioned and see how I can work in your comments without getting too verbose. I think that since the people who write the docs are the ones who make the API, we take some things for granted which we shouldn't. The only way to find that out is to get great feedback from people like you, so thank you!

Also, glad to hear you like the hosting! We're really proud of what we launched today and have a lot of plans for it into the future. If you have any more suggestions, feel free to email me. You can find my email in my profile.

Re: Introducing Firebase Hosting

#65
post #60

Earlier quoted context omitted.

Take a look at the "Reading Data From Firebase" doc ( https://www.firebase.com/docs/reading-data.html ). If you've got some feedback on it or think it isn't clear enough, I'd be happy to chat with you and see how we can improve the docs.

Thanks for the response. I have, and its simple enough from the perspective of a developer that has been in the field for a little while, but since these services are getting more and more popular it seems like striving for absolute clarity might pay off in the long run. For example, 1. Its not totally clear that the url that you are supposed to use is the url that is generated when you create a new app and land insi…

I agree with cnp. I think it would've been much easier to grasp if the URLs worked like most APIs. For instance, I expected this URL https://samplechat.firebaseio-demo.com/users to return the users as JSON instead of the html data dashboard. This slowed me down more than anything when I started. I think it would be helpful to have both the data dashboard and the raw data, but on separate URLs. But generally it's awesome!

Re: Introducing Firebase Hosting

#67
post #60

Earlier quoted context omitted.

Thanks for the response. I have, and its simple enough from the perspective of a developer that has been in the field for a little while, but since these services are getting more and more popular it seems like striving for absolute clarity might pay off in the long run. For example, 1. Its not totally clear that the url that you are supposed to use is the url that is generated when you create a new app and land insi…

I really appreciate the great feedback! I will take another look at the doc sections you mentioned and see how I can work in your comments without getting too verbose. I think that since the people who write the docs are the ones who make the API, we take some things for granted which we shouldn't. The only way to find that out is to get great feedback from people like you, so thank you! Also, glad to hear you like t…

Yeah, the hosting is fantastic, a devs dream. Already spammed my company with a link and a working example :)

Re: Introducing Firebase Hosting

#68
post #40

Upvoted solely for the description of how modern web-apps should be developed!!! So many people have legacy, server-side attitudes... JavaScript is treated like a special cousin that can raise alert boxes and things...

It's all cyclical, and I've seen enough cycles now. The trend always oscillates between heavy clients and heavy servers. They each have their strengths: Heavy Client: simplified backend management Heavy Server: clients all run the latest software (no versioning) There is (and will never be!) a silver bullet. Development is always tricky.

Not buying the latest version argument for a web app... But I am sure you're right that it is cyclical from a wide view. It seems to me that all human endeavour is. Additionally, all choices have a benefit and opportunity cost - everything in life is a trade-off...

Seems to me, in the case of a world where bandwidth is scarce and processing power is ubiquitous, that the fat-client, thin-pipe model is where it's at. :)

How many cycles have you seen? Are they really comparable? Doesn't each one need to be treated specially and considered independently?

Post reply on HN