Hi HN, I'm the lead engineer on Firebase Queue. I think it will make processing background tasks in Firebase much easier, and we're already using it for some projects internally. I'd love to hear what you think when you try it out!
My solution so far has been to write my own Node server that listens to a particular branch for requests, and use the rules to enforce that a user can only write to /request/<user-id>. When making a request, a user writes data to their user ID's request branch, and listen for changes made by the server to their request. This has worked out great, but the Java server is now a point-of-failure. It would be great to get some information on how this would be an improvement over my current setup.
The biggest advantage would be that you can have multiple server processes listening for requests on the same path and know that only one will be processing it at any point in time. That way your process is no longer a single point if failure.
Hi HN, I'm the lead developer on Firebase Hosting and the post’s author. We're trying to build something that's both simple to use and a serious production grade product. We think we're pretty close to the mark but we'd love to hear how we can improve it. Let us know in the comments (or email me at chris@firebase.com).
While this isn't specific to hosting, one glaring thing that I've noticed in the documentation / tutorials is there are no clear instructions on how to retrieve data. In the Getting Started link at the top of your site, theres a section that says 'Save Data', but nothing for 'Retrieve Data'. And the documentation isn't any clearer.
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 inside of Forge.
2. Its also not totally clear that in retrieving data you're supposed to follow the structure of you JSON schema. A simple note along the lines of "If you would like the retrieve the third index in your array, its as simple as creating a new Firebase instance and passing in 'mydata.firebaseio.com/3' as the url.
3. Like I mentioned in my first comment, it would be good if you had a 'Retrieve Data' bullet point on your getting started page. For users who simply want to import JSON into Forge to display in their app via retrieval, a two line note and example along the lines of
Retrieve Data
user = new Firebase('mydata.firebaseio.com/users/3')
user.once (userData) ->
console.log userData.val() # Should return Kim Gordon
would help.
There are little things (and I emphasize little here) scattered throughout which would lead less experienced devs into a bit of confusion when first getting started.
If I'm being overly cautious here please disregard, but it did hang me up when I first started playing around with the system.
Either way, totally love the hosting and super psyched to dive deeper into the platform!
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!
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.
Firebase gives you the ability to create dynamic pages with no backend requirement. This left a really small gap that the developer still had to host that HTML/JS page somewhere. So Firebase already supplied the backend now they also supply the hosting.
In short, both. :-) This was a commonly-voiced pain point for our existing customers and fits very well with our vision to make Firebase the best platform for building modern apps.
But when we do something, we like to do it "right" and so we also think Firebase Hosting comes with a very compelling feature set (Simple Deploy/Rollback, Automatically-provisioned SSL, and a global CDN). So we're optimistic it'll also attract new developers to the Firebase platform.
It would be nice if you could add some latency benchmark against common alternatives like S3. A lot of ppl use that for static webpages, but I wonder how lack of CDN affect the user experience.
I guess comparing to CloudFront would be helpful, too. If you've gone so far as hosting on S3, serving through CloudFront is about 5 minutes of additional effort.
Great suggestion! The difference between being on a CDN and not is really night and day. Every serious site deserves to be on a CDN. Your users will thank you for the faster page loads. :-)
