GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-10-03) - page 1 of 10
 
___________________________________________________________________
Cloud Firestore: A New Document Database for Apps
266 points by crb
https://firebase.googleblog.com/2017/10/introducing-cloud-firest...
___________________________________________________________________
 
troika - 4 hours ago
Great update, congratulations. It sounds similar to
https://deepstream.io records - small JSON documents that are
stored and synced in realtime across clients and can be arranged in
lists and reference each other.
 
niftich - 6 hours ago
Grats! Can you talk a bit about your consistency model?
 
  itcmcgrath - 6 hours ago
  Sure, it's strongly consistent on the server-side part (strict
  serializability), whereas for the mobile/web clients we make sure
  we move you through consistency snapshots with the real-time sync
  functionality.
 
    irfansharif - 5 hours ago
    Congratulations on the release!> multi-region replicated
    database [..] once data is committed, it's durable [...]>
    strongly consistent on the server-sideDo you mind elaborating a
    bit more here? Around perhaps what happens underneath the hood
    when failing over, etc. Do you have a single "co-ordinator" of
    sorts ensuring strict serializability, if so what do you do
    when failing this over? Or is it a quorum based approach like
    Paxos/Raft?
 
      itcmcgrath - 5 hours ago
      Quorum based (Paxos)
 
p2t2p - 2 hours ago
Another cool Google tech which will SUDDENLY go extinct when you
need it most and which will ignore all of you support requests if
it doesn't work properly and which will block you from all of you
stuff in Google's system if you break smallest shady statement line
in the TOS. Do you really want to base your business on top of
Google's stuff? Come on, even MS is more trustworthy than modern
Google.
 
dotmanish - 5 hours ago
What happens to "Backups" with Firestore? (Firestore console
doesn't have a Backups tab)
 
  adufetel - 5 hours ago
  Thanks for the feedback.  We don't have backups for Cloud
  Firestore yet, but this will be available down the road.
 
    afro88 - 3 hours ago
    What are our options until this is available? Will built in
    backups be available once you're out of beta, or further down
    the road?
 
jinjin2 - 2 hours ago
The offline database experience still looks really primitive
compared to Realm, and all the documentation seems to purposefully
avoid any details with regards to conflict resolution. Are there
any plans to address this?
 
pritambarhate - 4 hours ago
Does any of you feel cheated by Google? Rather than improving the
existing product and providing backward compatibility, Google has
chosen to build a new product with its own proprietary API.I have a
client who has invested significant amount time and money in
Firebase Realtime Database. Now with this move, I am not sure if
Google will support Firebase Realtime Database for next 5 years. So
a full rewrite might be needed.Once more it seems that going Cloud
Native on one of Google's proprietary tools is very risky. I know
many of the readers will say that Firebase Real-time Database is
still supported. But the main question is: will it stay supported
for years to come?Google please please make an announcement and
make a commitment to keep Firebase Realtime Database alive for "X"
years to come. Otherwise, you are just making us developers lose
faith in you.
 
  PKop - 2 hours ago
  How would you propose shoe-horning a document database into
  Firebase realtime DB?Can't you just pretend this new feature you
  just learned about 2 hours ago didn't exist if you don't want to
  use it?Isn't releasing this very feature improving Firebase, like
  you're demanding?
 
  stefano - 3 hours ago
  This is a very reasonable comment, why is it downvoted so
  heavily?
 
  jamest - 3 hours ago
  [Firebase founder] To offer better querying, improve the data
  model, and increase scalability we had to build an entirely new
  database. The original technical choices we made as a startup
  weren't able to support the featureset Cloud Firestore has. Even
  if we tried to improve upon the existing Realtime Database
  product, we would have had to make breaking changes that would
  have required you to rewrite your code (and likely shipped a
  worse product).Regarding deprecation: you can be comfortable
  continuing to build on the Realtime Database. We don't intend to
  deprecate either database, since both are useful in different
  situations, depending on what you're building. We recommend using
  the Realtime Database for a number of usecases[1]We're not
  posting a "Realtime Database will be supported for X years"
  statement because many may interpret this as "the Realtime
  Database is deprecating in X years", which isn't the case.[1]
  https://firebase.googleblog.com/2017/10/cloud-firestore-for-...
 
    pritambarhate - 3 hours ago
    Thanks for the clarification. I certainly feel better with the
    confirmation. I hope it will give some certainty to thousands
    of developers out there who decided to make Firebase Realtime
    Database a critical component of their product architecture.
 
  fictionfuture - 2 hours ago
  its nearly impossible to make large non-breaking improvements to
  an existing production service ... so no, they did the right
  thing here.
 
drumttocs8 - 3 hours ago
Should I really be so excited for built-in query support in 2017?
For a mature product supported by a dominant tech company? Because
I am.
 
adamonkey - 5 hours ago
How is the pricing? Firebase Realtime Database is fairly expensive
($5/GB of storage per month), so it makes economic sense for
developers to migrate to their own backend once they hit a certain
scale. This is why third-party mobile backends are nowhere near the
popularity of non-mobile backends with Google Cloud / AWS.Do you
think $0.18 per 100000 writes solves this problem?
 
  habosa - 5 hours ago
  As you've noticed, the pricing model is totally different for
  Cloud Firestore.  Link for others reading:
  https://firebase.google.com/docs/firestore/pricingIf you're
  concerned about price per GB stored, Cloud Firestore will be much
  cheaper than Realtime Database (0.18/GiB/month).  We evaluated
  many use cases when deciding on prices and we believe developers
  will be happy with the new model.However since Cloud Firestore
  charges by operation, it's important to evaluate your use case
  when thinking about pricing.  For example if you're running a
  fleet of IoT devices checking in a few times per second with very
  small payloads, you'd be doing a lot of write operations with
  very little storage and Cloud Firestore could be more expensive
  in that case.
 
    jopsen - 3 hours ago
    So:firebase  <-- presence, real-time editing, chat, in-memory
    thingsfirestore <-- things that have a save/submit button,
    transactional databasequick question: So the real-time features
    in firestore are not ideal for real-time text editors and
    chats. But saving documents from firebase after to user has
    left is perhaps a good middle ground.Would firestore charge
    read for each reader that's listening in real-time when a
    document is updated?
 
      habosa - 3 hours ago
      I wouldn't say the difference is exactly that clear cut.
      Presence is a clear example of a situation where you want to
      use Realtime Database over Cloud Firestore.  And you're
      right, for something that you would otherwise do "in memory"
      or use memcached/redis/etc Cloud Firestore may not be the
      right fit.In my experience both databases are totally
      appropriate for a chat app.  Even though in Cloud Firestore
      you will pay a document write for each new chat message,
      that's only $1.80 for a million chat messages and you get all
      the rich querying from the Cloud Firestore API.Regarding your
      pricing question: https://firebase.google.com/docs/firestore/
      pricing#operation...> When you listen to the results of a
      query, you are charged for a read each time a document in the
      result set is added or updated. You are also charged for a
      read when a document is removed from the result set because
      the document has changed. (In constrast, when a document is
      deleted, you are not charged for a read.)
 
tannhaeuser - 6 hours ago
> Document Database for AppsFrom linked page:> designed to easily
store and sync app dataMaybe I'm misunderstanding, but that's not
what I understand a "document" to be.For me a document- is a file
that can be stored on a file system- can be send via mail- is using
a standard document representation so can be used by different
applications, such as markup (XML, HTML, SGML), or maybe PDF
 
  habosa - 6 hours ago
  I can see how that might be confusing.  We are using "Document"
  as it's used in database circles: https://en.wikipedia.org/wiki
  /Document-oriented_database
 
  sametmax - 6 hours ago
  Why the downvote ? The person is polite and genuinly doesn't know
  something.Just answer.Besides, a "document database", like many
  term in computing, can be very confusing. Come on, we all had to
  be explained what the difference is between a software server vs
  hardware. This is not different.
 
    tannhaeuser - 6 hours ago
    > Why the downvote?Smells like ring voting: 4 downvotes in <
    0.5 min? @dang?
 
      staunch - 5 hours ago
      Any post having to do with YC, Google, Microsoft, Facebook,
      Apple, etc are voting ringed to hell by their thousands of
      employees.As the site has grown, HN has become a bit of a
      mouthpiece for large organizations through these de facto
      voting rings.Best idea I have is for HN to add a profile
      field like: "Organizations: [google]" which would prevent
      voting on any Google-related submissions. It could also add a
      disclaimer in each comment of these submissions, so users
      wouldn't have to remember to do that.
 
        ben_jones - 4 hours ago
        It isn't even malicious - just a natural tendency people
        have. Like favoriting your friends picture on instagram
        even if it doesn't look too flattering.I love that
        suggestion, but how would you validate it? Registering
        company domains would be an exhaustive process.
 
          zzzcpan - 4 hours ago
          Or just punish big brand submissions slightly, to make it
          fairer for everyone else.
 
          staunch - 4 hours ago
          Agreed that it's not malicious. But it is insidious and
          should be prevented. There's only a half dozen large
          Silicon Valley orgs worth worrying about. Maybe a dozen
          domains.
 
        stephenr - 4 hours ago
        Changing or removing the downvote button would be a
        simpler, better fix.
 
        bryanlarsen - 4 hours ago
        All of the listed corporations also have a large number of
        fanboys and haters, so are going to attract a large number
        of votes even if employees abstain.
 
        tannhaeuser - 5 hours ago
        > HN has become a bit of a mouthpiece for large
        organizationsIn don't mind (in fact, appreciate) this
        aspect of HN as long as it's done openly and civilized.>
        Best idea I have is for HN to add a profile field like:
        "Organizations: [google]" which would prevent voting on any
        Google-related submissions. It could also add a disclaimer
        in each comment these submissions, so users wouldn't have
        to remember to do that.That's a brilliant idea.
 
      sametmax - 5 hours ago
      French person here.What's ring voting ?
 
        tannhaeuser - 5 hours ago
        > What's ring voting?Coordinated up- or downvoting from
        multiple accounts
 
riston - 1 hours ago
I do like the new solution more than the Realtime Database, but I
see only this solution to fit smaller scale. Applications with
heavy write could get really expensive. Also, the standard plan has
only "Maximum write rate to a document     1 per second". The write
is currently three times expensive operation as read hopefully,
this would be lowered in future.
 
nkw - 6 hours ago
This is great. I had a feeling something like this was coming given
most firebase people were pretty open about what the shortcomings
of the Realtime DB were and AngularFire received some much needed
attention to its database API last week.That said, I really hope
there are plans for some full text search ability beyond the
current suggestions[1]. I would very much like to ditch
Elasticsearch in favor of db engine provided search. Even a small
subset of the Elasticsearch/Solr feature set (similar to the full
text search capability now available for Postgres[2]) would be a
very welcome addition.[1]
https://firebase.google.com/docs/firestore/solutions/search [2]
https://www.postgresql.org/docs/9.5/static/textsearch.html
 
  itcmcgrath - 2 hours ago
  Thanks for the feedback, this request is definitely been a
  frequent one. :)
 
[deleted]
 
vira28 - 2 hours ago
Can this be used with the old firebase sdk? Upgrading looks like
pain
 
plexicle - 5 hours ago
Very excited to see a Go SDK for it, too! Can I use it for real-
time as well?
 
  habosa - 5 hours ago
  The Go SDK does not yet have realtime capabilities but that's on
  our roadmap!  Right now you can use realtime with Android, iOS,
  Web, and Node.
 
projectpublius - 5 hours ago
Will GeoFire remain solely on RTDB?
 
  habosa - 5 hours ago
  Cloud Firestore has native support for the "GeoPoint" data type
  and will eventually have support for native geo queries without
  any external library.For this reason we are not going to invest
  in making a GeoFire library for Cloud Firestore and spend that
  effort getting the native functionality ready.
 
jgmmo - 6 hours ago
How is this different than using datastore?
 
  [deleted]
 
  itcmcgrath - 6 hours ago
  Great question! I'm the PM for both Cloud Datastore and Cloud
  Firestore.The biggest difference is the integration with
  Firebase, so you have access to Mobile (iOS/Android) and Web SDKs
  along with a native offline mode. This comes along with the real-
  time synchronization feature that makes serverless app
  development a breeze.Cloud Datastore is great for large scale
  server-side development where you manage your own connection to
  your app, such as running your own website on App Engine or via
  Compute/Container Engine.
 
jcz - 2 hours ago
The firestore security rules dsl [1] looks like it could become
cumbersome as the number of edge cases increases. I've briefly used
firebase realtime database json rules [2] in a side project, and
while basic acl scenarios can be covered cleanly, rules quickly
tangle without a full programming language. It's hard to check
syntax, lint, test, and collaboratively edit.I believe this custom
auth layer is best handled by allowing code with restricted api
access and time constraints. The technical approach cloudflare used
to implement its edge workers by embedding v8/js [3] would be
perfect here.[1]
https://firebase.google.com/docs/firestore/security/get-star...
example:   service cloud.firestore {     match
/databases/{database}/documents {       match /{document=**} {
allow read, write: if false;       }     }   }  [2]
https://firebase.google.com/docs/database/security/[3]
https://blog.cloudflare.com/introducing-cloudflare-workers/
 
  habosa - 2 hours ago
  The new rules language (which was already used by Cloud Storage)
  is a full programming language.  It's not turing complete, but
  that's by design.  Still, you can declare functions and do other
  complex things that were never possible with the Firebase
  Realtime Database JSON rules.We're working on opening up the
  tools to work with the rules language so you can test and iterate
  more easily.
 
stefano - 4 hours ago
I don't like this trend of creating new closed source database
systems that only exist on a single cloud provider.Your data is
your most valuable asset, and by using this you're locking it
inside Google servers. If they decide five years from now to
discontinue it, or to raise the pricing 10x, you're screwed.Are
most developers only working on short term projects? Why would you
put yourself in such a situation instead of using open source
technologies that can be deployed anywhere?
 
  react4 - 3 hours ago
  To your point and for precisely this reason, we offer realtime
  capabilities but on top of the Elasticsearch engine[1]. We also
  have a cloud native version in preview (that we are actively
  developing) which addresses deployment flexibility[2][3].[1]
  https://appbase.io [2] https://store.docker.com/images/appbaseio
  [3] https://appbaseio-confidential.github.io/streams
 
  jrowley - 2 hours ago
  How many of projects last 5 years? I'm notorious for short term
  thinking, but often times if pays off.
 
  cobookman - 4 hours ago
  > Your data is your most valuable asset, and by using this you're
  locking it inside Google servers. If they decide five years from
  now to discontinue it, or to raise the pricing 10x, you're
  screwed.You'd be able to move your data off of firestore. And
  there's legal business contracts around pricing. Google can't
  just raise pricing 10x overnight.
 
    stefano - 3 hours ago
    Sure, you can move it, but how much code will you need to
    rewrite? How much effort to convert the data to a new database
    format? And how much more development time to migrate your data
    without taking your service down during the migration?It's a
    very expensive move that I don't think people consider when
    choosing this kind of solution.
 
      kerryritter - 3 hours ago
      Maybe I'm naive but I think a lot of people consider this,
      but the benefits of development speed outweigh the risk for a
      number of cases.
 
      anderspitman - 2 hours ago
      Have you used Firebase before? In my (rather limited)
      experience, the development speed increases from not needing
      to manage your own Mongo store, not to mention implementing
      all of their real-time features on top of that, are quite
      valuable. At least for an MVP I wouldn't hesitate to do the
      first version with Firebase to test my assumption even if I
      knew I wasn't going to use it at scale. Plus you can always
      wrap Firebase in your own layer from the beginning.
 
polskibus - 5 hours ago
A couple of questions:What's the underlying synchronisation
mechanism?Is it based on CRDTs?How does this product differ from
Gun.js and realm.io?
 
  archagon - 4 hours ago
  If this is similar to what powers GDocs, it's probably OT-based.
 
  itcmcgrath - 1 hours ago
  It does not use CRDTs as they cannot be used to handle all the
  update requirements of this system.It uses Paxos as the consensus
  algorithm, along with internal systems like the TrueTime API to
  enable us synchronously replicate across multiple data centers.
 
  code-is-code - 4 hours ago
  It would also be great to see a comparison to the couchDB-sync
  which I currently use via pouchdb/rxdb.
 
tnolet - 2 hours ago
I'm sorry if I overlooked, but no aggregations? Like calculating
sums or averages?
 
HammadB - 5 hours ago
This is amazing! I just spent yesterday writing a separate app
engine service to use cloud datastore even though the rest of our
stuff is on Firebase (RTDB wasn't a fit for us). Great to see this
is out
 
deepsun - 5 hours ago
Sounds interesting, but is there any independent description of
what it cannot do, or what would be hard to do?I just noticed it's
much easier to understand a new datastore by reading its
limitations (usually carefully omitted from pr articles or
documentation).For example, I suspect that Firestore must be built
on top of Spanner infrastructure, as it's the only way to get
usable cross-datacenter many-row transactions. And Spanner's
limitation is it's high price. And if it's not Spanner, but more
like Cloud Datastore or the old Megastore, then there should be
limitations on transactions.Sounds amazing anyway, more datastorage
choices is always better for the world.
 
  habosa - 5 hours ago
  We try to be honest about what the product can't do natively and
  provide best practices, take a look at the "solutions" section of
  the documentation:
  https://firebase.google.com/docs/firestore/solutions/For example
  Cloud Firestore can't do native full text search, but we made
  sure it's easy to integrate with a search provider like
  Algolia.As for your guess about Spanner, you're right that Cloud
  Firestore uses the same technology as Cloud Spanner to ensure
  consistency at scale.Would love to know what you think about the
  product once you've tried it!
 
  itcmcgrath - 4 hours ago
  We've also tried to be transparent and document our current
  limits here: https://firebase.google.com/docs/firestore/quotas
 
bikamonki - 5 hours ago
What's the difference with Firebase RTDB?
 
  gfosco - 4 hours ago
  If you had read the post, you would know this, it even links to a
  more detailed post specifically about the differences towards the
  bottom.
 
  UnfalseDesign - 4 hours ago
  Here's a document they wrote comparing the two:
  https://firebase.google.com/docs/firestore/rtdb-vs-firestore
 
hmexx - 5 hours ago
I?m still looking for a product that provides firebase-levels of
ease of getting up and running (no API to design, rule-based
authentication, etc) , but runs on your own infrastructure, off of
a traditional RDBMS.Someone tell me they?ve found the holy grail?!
 
  marknadal - 3 hours ago
  We're a popular alternative, https://github.com/amark/gunSome
  cool differences:- MIT/ZLIB/Apache2 licensed.- Graph data
  structures (document, key value, tables, relations, and more!)-
  Decentralized like IPFS!- Alpha prototype for end-to-end
  encryption and user authentication / permissions security.And a
  bunch more :).
 
  joking - 5 hours ago
  You can use Apache usergrid or the open source version of parse
  for example.
 
    hmexx - 5 hours ago
    I believe usergrid runs off of Cassandra and Parse runs off
    another NoSQL DB. Maybe Mongo?
 
      jamesjyu - 5 hours ago
      Yep, Parse runs on Mongo.
 
  yasserf - 3 hours ago
  Deepstream.io is a cloud platform and opensource real-time server
  that provides rule based permissions, authentication and a real-
  time data store that can be plugged into different any database
  (we use Postgres under the hood for the cloud).It provides the
  same name document/collection concepts, but search abilities are
  still under development.Side note, Im one of the cofounders
  :DGenerally this move by Firebase makes a lot of sense! Building
  large real-time apps usually requires smaller documents or else
  things get super odd at scale.
 
  react4 - 4 hours ago
  We offer this at appbase.io, it runs on top of Elasticsearch (no
  vendor lock-in) and a cloud native version that you can run
  anywhere is now available in preview at
  https://store.docker.com/images/appbaseio.
 
  jkarneges - 5 hours ago
  If such a project were based on top of an RDBMS, would you still
  expect a document/KV-oriented API, or one more SQL-ish?
 
    hmexx - 4 hours ago
    Honestly I don't mind. A document API with a little
    manipulation on the front-end would be fine, as long as the
    back-end has some way of running through the relations.A SQL-
    ish API might even be better, although I can see some pitfalls.
    Maybe base it on GraphQL as a compromise?Either way, I'd love
    to have something like this.
 
  bryanlarsen - 4 hours ago
  horizon.io seemed to be a promising entry, but unlike RethinkDB
  the database, this project appears to have died with Rethink the
  company.
 
  arve0 - 1 hours ago
  FeathersJS provides a layer between your database (RDBMS, NoSQL,
  ..) and your client, which gives you similar functionality as
  firebase.https://feathersjs.comEdit: Minus rule based auth.
 
  pcnix - 4 hours ago
  You should check out Hasura (https://hasura.io/)!It is exactly
  what you're asking about.Disclaimer: I work at Hasura. Feel free
  to ask me anything you  want to know about.
 
    hmexx - 3 hours ago
    Woooo.. Interesting. I'm going to download it now and give it a
    whirl. Will get back to you with feedback (if you're
    interested).
 
jamest - 6 hours ago
[Firebase founder] This new database has been in the works for 2.5
years, since shortly after we joined Google. It was developed in
close collaboration with the Cloud Datastore[1] team, and uses
Google?s core database infrastructure.We built it because we know
it can be challenging to build complex apps with our original
database -- Firebase Realtime Database -- where we optimized for
ease-of-use & real-time sync over querying functionality. For more
info, see this comparison between the two[2].This is a open beta
launch, so the product has limitations[3] you should be aware of.
We?ll be working to remove/raise these before General
Availability.A note on naming: Firebase launched in 2012[4] with a
single product, the original database. As we added products
(Firebase Auth / Firebase Hosting / etc), we began calling the
original product ?Firebase Realtime Database?, or RTDB for short.
If you haven?t followed us lately, we?ve grown to become Google?s
app platform, and now have 16 products to help you build/grow
apps.We?re grateful for the support HN has given us over the years
and we hope you enjoy Cloud Firestore![1]
https://cloud.google.com/datastore/ [2]
https://firebase.google.com/docs/firestore/rtdb-vs-firestore [3]
https://firebase.google.com/docs/firestore/quotas [4]
https://news.ycombinator.com/item?id=3832877
 
  cfilipov - 5 hours ago
  Regarding offline mode. How is sync done? Is this OT based? How
  are conflicts resolved?
 
    mikelehen - 4 hours ago
    Good question, and to answer this well we should probably do a
    blog post or something. In the meantime you could dig into the
    code since the clients are all open source. :-)But basically,
    sync is split into two halves: writes and listens. Clients
    store pending writes locally until they're flushed to the
    backend (which could be a long time if the app is running
    offline). While online, listen results are streamed from the
    backend and persisted in a local client cache so that the
    results will also be visible while offline (and any pending
    writes are merged into this offline view). When a client comes
    back online, it flushes its pending writes to the backend which
    are executed in a last-write-wins manner (see my answer above
    to ibdknox for more details on this). To resume listens, the
    client can use a "resume token" which allows the backend to
    quickly get the client back up-to-date without needing to re-
    send already retrieved results (there are some nuances here
    depending on how old the resume token is, etc.).
 
      cfilipov - 4 hours ago
      Thank you!
 
  TY - 6 hours ago
  Just read through your link #2 and was very impressed. Firestore
  addresses every single concern I had with RDTB and more and I'm
  looking forward to using it in my side projects.Thank you!
 
    mayop100 - 6 hours ago
    That's great to hear! Our design for Cloud Firestore was based
    on years of developer feedback. Glad we hit the mark for you :
    )
 
  gfosco - 4 hours ago
  Awesome to see this.  I couldn't get behind the RTDB structure,
  but Cloud Firestore I will definitely use!
 
    inlined - 4 hours ago
    Woohoo! Is this an official parse endorsement? (Hi Fosco )
 
      gfosco - 4 hours ago
      Hey Thomas :) I speak only for myself, Firebase just got way
      better.
 
        inlined - 4 hours ago
        I'm glad. Hoping you like cloud functions too!
 
  sandGorgon - 5 hours ago
  Do you see this as an equivalent to Dynamodb ?Very timely ;)
 
    jaxondu - 3 hours ago
    DynamoDB does not come with offline sync.
 
  jonasb - 2 hours ago
  The enhanced query capabilities are very much appreciated. I hope
  full-text search is in the works, since adding a 3rd party FTS
  engine adds quite a bit of complexity.
 
  aphextron - 6 hours ago
  Very exciting. I found this to be the one "missing piece" keeping
  me from being able to build a whole app on Firebase when checking
  it out earlier this year. One question though, will this support
  BLOBs like GridFS?
 
    habosa - 6 hours ago
    You can store Blob data, but the maximum size of a single
    document is still 1MB.  If you need to store larger blobs check
    out Cloud Storage for Firebase.
 
      e12e - 2 hours ago
      Could you share some of the reasoning behind arriving at a
      1mb limit (why not 10mb or 512kb for example)?
 
        itcmcgrath - 2 hours ago
        Hard to explain externally, but it relates to RAM size
        allocation + throughput in the underlying distributed
        database system.
 
  insomniacity - 4 hours ago
  How goes the work to improve customer service and
  support?Thinking about
  https://news.ycombinator.com/item?id=14359801, what improvements
  have you made in the last 139 days that would make us want to
  build on this?
 
    jamest - 36 minutes ago
    (Some quick context for those not aware of the initial
    incident: In May we fixed two bugs in our pricing pipeline that
    caused some users to see price increases.Bug 1: we under-
    reported bandwidth (in particular SSL overhead)Bug 2: we were
    not enforcing quotas for all accounts.For most users, the fixes
    had little-to-no impact. For a few users who were using the
    Realtime Database with large volumes of small reads and writes,
    the impact was large. You could mitigate this impact by
    updating your client code, but unfortunately a user who had
    shipped code to their IoT devices couldn?t. This user was also
    simultaneously forced to upgrade to the Blaze pay-as-you-go
    plan due to quota enforcement on our $25/mo Flame plan. These
    combined resulted into a large billing increase for this user.
    We weren?t quick enough to provide this user with credits due
    to poor internal communication).To address these we have (1)
    worked to make billing more transparent on Realtime Database
    and (2) are working on improving support.1a. We rewrote our
    documentation to add more detail on billing mechanics and how
    to optimize bandwidth
    (https://firebase.google.com/docs/database/usage/billing).1b.
    We rewrote the documentation for our profiler tool which was
    confusing to many developers
    (https://firebase.google.com/docs/database/usage/profile).1c.
    We now have better alerting for if/when we find errors in our
    codebase that can impact their bill (up or down).1d. We will
    soon be releasing (spoiler alert) a new monitoring API to let
    developers directly analyze their database billing and
    performance data.2a. We raised the quota on free technical
    questions from 5 => 10. Questions on accounts/billing/bug
    reports are still unlimited2b. We worked to increase Support
    CSAT. It is up by 15% since the billing issue in May.Finally,
    the new database we?re launching today, Cloud Firestore, has
    daily budgets. You can use these to set exactly how much you?re
    willing to spend per day (more here:
    https://firebase.google.com/docs/firestore/usage#limits) We?ve
    also got extensive pricing docs:
    https://firebase.google.com/docs/firestore/pricingI hope this
    answers your question!
 
    steego - 2 hours ago
    For their own sake, I hope the team gives this question
    attention and respect.What sets Amazon apart from many other
    companies is their reputation for relentless customer service.
    Customers pay close attention to the quality of answer or lack
    of answers to questions like this one.Every cloud company that
    asks us to invest our time in their proprietary API is asking
    us to trust them.  If you violate one vocal customer's trust,
    we're going to notice.  If you don't make things right, we're
    going to notice.  Even before I read the article, I first read
    the comments to gauge the reception because I care more about
    the perception of trust before I even consider using something
    like this.Customers don't always stop trusting companies for
    fair or valid reasons, but that doesn't matter.  Trust is much
    more of a visceral thing than a cerebral thing.So here's my
    question to other HN readers.  What would Google need to do to
    improve its reputation for customer service?  What would they
    need to do to make that commitment resonate with you on a
    visceral level?
 
    vim_wannabe - 2 hours ago
    How does customer service work with technical services?There is
    very little time for developers of a system to use on support,
    so how do you go about building the baby padding around them? I
    would imagine at least 97.5% of support requests are a problem
    on customers end, so just how much support staff would you need
    for a global service like this?
 
    victorhooi - 2 hours ago
    So my reading here is that the main issue is Firebase was
    undercharging customers, due to a bug.They didn't go back
    retroactively and ask for back payments, but just started
    charging them accurately going forward.Of course, that bill
    caused shock for some people, as they suddenly realised, "Oh
    s*it, I'm being charged accurately now, my bills are huge!!!"In
    this customer's case, apparently they were also doing something
    bad with TLS tickets and not setting keep-alives - basically
    causing them to spam Firebase with
    connections:https://news.ycombinator.com/item?id=14357270Of
    course, there's the other issue of a communication breakdown
    which they said they're working on.
 
  judah - 5 hours ago
  What's your story on ACID, particularly on
  transactions?Transactions: If I want to insert 2 documents, but
  zero if either fails, what does that look like with Firestore?And
  if I store a document and run a query milliseconds later, will
  the query include document I just stored? Or are queries
  eventually consistent?
 
    habosa - 5 hours ago
    Cloud Firestore has support for transactions:
    https://firebase.google.com/docs/firestore/manage-
    data/updat...So yes, if any of the operations in the
    transaction fails (and cannot be retried) the whole transaction
    will fail.  It's atomic as you'd expect.  If you've ever used
    transactions in Firebase Realtime Database you'll be happy to
    know that the transactions in Cloud Firestore are much easier
    to use since they don't require selecting a common data
    parent.Queries are always strongly consistent.  If you do a
    write-read sequence you'll see the value of the latest write.
 
      ibdknox - 5 hours ago
      How do you deal with consistency in the offline case? E.g. If
      I make a bunch of edits while disconnected, and others have
      made edits while connected, how are the conflicts resolved?
 
        mikelehen - 4 hours ago
        This works similar to the Realtime Database in that it's
        last-write wins (where in the offline case, "last" is the
        last person to come back online and send their write to the
        backend). This model is very easy for developers to
        understand and directly solves many use cases, especially
        since we allow very granular writes which reduces the risk
        of conflicts. But for more complex use cases, you can get
        clever and implement things like OT conflict resolution as
        a layer on top of last-write wins, e.g. similar to how we
        implemented collaborative editing with www.firepad.io on
        the realtime database.PS: Hi Chris! :-)
 
          ibdknox - 4 hours ago
          Hey Michael! Congrats on the launch :)Providing a one-
          size-fits-all solution here is probably impossible, but
          it seems like it would be nice to provide some mechanism
          to be notified that you're making edits based on stale
          information. If such a mechanism existed, it would be
          easy to add a bunch of canned merge strategies. In doing
          so you can probably teach people a little bit about the
          pitfalls they're likely to run into (these sorts of bugs
          are insanely difficult to track down), while not really
          making them do much work.The approach we've taken in Eve
          is that we can't solve all these problems for you, but we
          can at least let you know that things can go sideways and
          prompt you to make a deliberate decision about what
          should happen. It's amazing how helpful that ends up
          being.
 
          [deleted]
 
          lozenge - 3 hours ago
          It looks to me like Firestore's API doesn't include a
          "default" way to upload user edits to documents. Conflict
          detection is possible using the transactions -
          https://cloud.google.com/firestore/docs/manage-
          data/update-d... - you can do something like HTTP's PUT
          If-Unmodified-Since (or PUT If-Match).
 
          mikelehen - 2 hours ago
          Good point. read-modify-write transactions are a good way
          to detect conflicts and get a chance to handle them, but
          they're unfortunately limited to while the client is
          online. If the client is offline, the transaction will
          fail so they're not useful for general conflict
          resolution. This was an intentional decision because
          there's not a straightforward way to preserve the intent
          of the transaction across app restarts.  But there may be
          options for adding some sort of conflict resolution
          strategy in the future that leverages the same underlying
          primitives that transactions use today.
 
          mikelehen - 2 hours ago
          Thanks for the feedback. I think you're right and we're
          interested in exploring what we can do to help people
          more in the future. One of the really nice things about
          Cloud Firestore is that documents are versioned with
          timestamps in such a way that we could definitely detect
          and expose conflicts and let you decide how to deal with
          them... It's mostly a matter of identifying the common
          use cases and then figuring out the right API to make
          them possible without going too far into the deep end of
          conflict resolution.
 
          euyyn - 2 hours ago
          > OT conflict resolution as a layer on top of last-write
          winsCan you link to somewhere where this layering is
          explained?The www.firepad.io site has documentation on
          how to use the editor, but I'm interested in how "OT on
          top of last-write wins" is achieved.
 
    [deleted]
 
    [deleted]
 
  wahnfrieden - 5 hours ago
  Do you have a rough timeline on beta => General Availability?
 
    itcmcgrath - 5 hours ago
    Nothing we can share at this time. Really looking forward to
    the feedback we get now we're in beta as this will feed into
    our GA plans.
 
  novaleaf - 4 hours ago
  glad you mentioned Cloud Datastore.  It seems that Firestore
  supersedes Datastore and Firebase.   Is that correct?   Any
  comparisons of Firestore vs Datastore?
 
    habosa - 3 hours ago
    It does not "supersede" Datastore or Firebase Realtime
    Database, neither of those products are going anywhere.This is
    a totally new product that builds on what we learned from those
    two products, sharing some of the best features of each and
    bringing in some totally new things as well.All three are (in
    my opinion) great choices for building a new app today so make
    sure you evaluate all options.
 
      [deleted]
 
  mjw1007 - 4 hours ago
  Can you provide anything to reassure potential users that this
  will still exist in five or ten years time?
 
    mbleigh - 3 hours ago
    The Firebase Realtime Database has been around for ~5 years
    (and is still fully supported after this launch).Cloud
    Datastore has been around in some form (started as App Engine
    Datastore) since 2008.Cloud Firestore was a massive multi-year
    joint effort between Firebase and Google Cloud. Google is
    investing heavily in both, and this is a big deal for our
    teams.
 
      mjw1007 - 1 hours ago
      Perhaps you could consider persuading the powers that be to
      make a loud public commitment.After all, if they are truly
      confident, there should be little cost in doing so.
 
        mbleigh - 1 hours ago
        We announced the product, that's a loud public commitment.
        Once it reaches general availability, it will be covered by
        the Cloud deprecation policy requiring a minimum of one
        year notice for deprecation.I'm not sure what other
        guarantees would even make sense to offer. If anything, I'd
        look at this announcement as ongoing proof in the magnitude
        of investment Google is making in Firebase and Cloud.
 
fictionfuture - 4 hours ago
Looks great, however, I still have hopes that something similar to
a GraphQL interface for a SQL based database is coming.NoSQL is
cool, but ultimately GraphQL/Apollo serves many of the same issues
but has the capability of a much richer, standardized and
potentially lower cost backend.
 
  ruslan_talpa - 4 hours ago
  It's coming https://subzero.cloud/ :)
 
    fictionfuture - 2 hours ago
    looks cool, interested to see the backend you're using and if
    it requires lockin.did Kreatank do that logo?
 
sagadotworld - 3 hours ago
We're one of the startups shown in the announcement (Crypto
Portfolio Tracker [1] - bottom right logo). Firestore enabled us to
build the first version of our app in under a week. We've been
using the product for over two months now, and it's given us a
competitive edge in being able to develop features rapidly and not
having to spend time on operations.One of the things we liked about
Firestore is that it takes the best practices of Realtime Database
and makes them more explicit. Before, your RD database structure
would look like  `collection/{id}` and
`collection_sub_collection/{id}/{sub_id}` in order to avoid loading
sub-collections in top-level queries. With Firestore, this
collections pattern is now part of the API itself, and sub-
collections aren't fetched when the parent is fetched.Another
feature we liked is that transactions are no longer limited to a
subtree of your database. Before, you would have to structure all
of your transactional data under a single path. This would
sometimes lead to having to pile-in unrelated data into a single
object, such as adding payment data under a users object instead of
a separate collection, so that you could atomically modify both
user and payment data. With Firestore, transactions are global, so
this isn't a concern anymore - we are free to structure our data in
any way that makes sense for our app.Overall, we had a great
experience with Firestore during the alpha, and we'll definitely be
keeping it as part of our technology stack. Congrats on the
launch!(disclaimer: this post isn't sponsored by Firebase)[1]
https://cryptoportfoliotracker.com
 
  Scarbutt - 24 minutes ago
  Is your use of Firebase limited to Firestore? If not, Does Crypto
  Portfolio runs entirely in Firebase?
 
willchen - 6 hours ago
Looks very exciting! I've used firebase for some small weekend
projects and it's been very productive for me.I'm curious, what's
the react native support like for Firestore / firebase in general?
 
  adufetel - 6 hours ago
  There's a pretty complete React Native library you can use to
  build with Firebase services, including Cloud Firestore:
  https://github.com/invertase/react-native-firebaseThe Cloud
  Firestore integration is fresh out of the box, but I'd certainly
  recommend trying it out!
 
  [deleted]