That is not true. The default access is only to authenticated users.

No it does not. By default it locks down your empty database to only authenticated users.

You know what I mean: open to all authenticated users, authentication being cleared at the app level. Only having to create an account for full access to all data is indeed "open." Would that Facebook used this strategy, the implications would be clear.

HTTP/2 happened. HTTP/2 allows you to send HTTP requests over a single TCP connection per domain. Headers are compressed. The request overhead is minimal compared to HTTP/1.x.

Caching one big file has the draw back of busting the cache each time the file is updated for any small change.

Caching multiple small files allows you to have a finer grain cache. Only bust the things that updated. And, since it's all the same TCP connection it's now performant to load this way.

Can't you do that already by reusing the 1.1 connection? Or is the 2.0 change that requests are now parallel?

Yep, more wording was bad. In HTTP/2 it's all parallel.

Sorry, wrote this before coffee. I was referring to H/2 eliminating head-of-line blocking. HTTP/2 gives you one TCP connection for multiple requests rather than the 7 connection limit browsers impose on HTTP 1.x

I highly recommend using Workbox: https://workboxjs.org/.

One of the more gnarly parts of ServiceWorker is having to clean up old caches during a version change. The workbox-build module generates revision hashes for your pre-cached assets and handles any cache clean ups for you.

Hello,

Firebase YouTuber, Slacker, AngularFire contributor, and Stackoverflower here. Feel free to ping me personally in the Slack channel (davideast) of via email (david@firebase.com) to talk more about all of these problems you've hit. We work hard to make sure people get their questions answered so I'd love to have a discussion with you.

I think Firebase is a pretty cool guy. Eh helps you develop high-quality apps, grow your user base, earn more money and doesn’t afraid of anything.

[Firebase Employee]

If you use the SDKs, we handle the connection and all of the data is sent over a reused full duplex socket rather than individual requests. https://www.firebase.com/docs/android/, https://www.firebase.com/docs/ios/, https://www.firebase.com/docs/web/

I'm trying to attach a ChildEventListener to the "item" Firebase and I'm getting a "permission denied" error. My guess is that I am doing something wrong, but on the off chance that the adding event listeners is not (yet) enabled, it would be nice to know. Any clues to what I might be doing wrong?

I've never used the Firebase API itself before. It's very clean!

Edit: I reached the same (now obvious) conclusion as mentioned in the reply below. Now my quick hack is working perfectly. Thank you so much for this!

[Firebase Dev Advocate] Glad you're enjoying Firebase! Attaching a listener to the "items" Firebase is disabled. This is because it would send every item from HN to your computer. You'll need to attach a listener to the individual item instead. The "permission denied" error is coming from the security rules on the HN Firebase (https://www.firebase.com/docs/security/quickstart.html). If you're trying to find out what the latest updates are, they're kept in the /updates node (https://github.com/HackerNews/API#changed-items-and-profiles).