Getting unique IDs from Firebase

[Rick Giusti]

Hi,

My question concerns getting unique IDs from Firebase.

I'm creating an app that I want to have zero friction to use,
i.e., no signup/login, just start using it. It has a component
that is to be shared, either with another user, or shared
between devices. Examples include 1) a list you create using
this webapp on your phone and want to see that same list on
your desktop computer, 2) two person games, or 3) a shared document.

I have done an app or two of this sort with Firebase, and have
the app create a URL for the second device or second person to
use that links the two. A new user has no ID (user number and/or
shared component ID) in localStorage. For the new user, I get
an ID from Firebase and store it in that person's device's
localStorage. A URL, with that ID added as part of an appended
query, is provided, that if followed on another device, will
cause that ID to be stored on that second device.

I have tried two schemes to get a unique ID.

1) Designate a node in the database that holds the next ID. Use the
transaction() API call to increment that ID, using that ID,
knowing that it is unique. The downside to this is that I have
the async problem, I cannot continue the app until this
returns. Yes, one can deal with this with increasing indenting
or promises (e.g. jQuery deferreds), but it is that  more
cognitive strain on the programmer. 

2) Use the push() API call to immediately return a unique ID (
nextUserNumber = userRef().push().name(); ), and assume the
push will eventually succeed. The downside is the form of the
ID returned (e.g. -Iz0T__VhJ_8QYH__CI1). If I supply this as
part of a URL, for the cut&paste-challenged person with a
smartphone, correctly transcribing this is can be a pain.

Am I missing something about Firebase that would relate to this?

Additionally, the ID that might be passed verbally or transcribed
without cut&paste should have some particular characteristics.
(This part is not Firebase related.) It should be short, but
not so short you can guess the next in sequence, and resistant
to common transcription errors. I'm thinking of something
similar to the identifiers JSFIDDLE creates, though using only
upper or lower case is easier to verbalize. Any thoughts, or
suggestion for terms on which to search.

Thanks.
   

[Jonathan Friedman]

Your second approach is much better in my opinion. If you want a
shorter ID, just hash them.

For example, you could do an MD5 and use the first 6 characters. Or
you could design your own heuristic to manipulate the Firebase
strings.

You should be aware, that you might get collisions this way.

Good luck with your project.

Cheers,
-Jonathan

Jonathan Friedman, PhD
CircuitHub, Inc.
https://circuithub.com

> --
> You received this message because you are subscribed to the Google Groups
> "Firebase Google Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to firebase-tal...@googlegroups.com.
> To post to this group, send email to fireba...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Andrew Lee]

Rick -

There's nothing magic about push ID's. They're essentially just the concatenation of a timestamp with a random portion to avoid collisions. If what you want is a "pretty" unique IDs that you don't need to use a transaction to generate -- just make up your own. Pick the character set you want and generate a random string with those characters. 

You'll want to make sure the string is long enough to avoid collisions. The push ID's we create are designed so that even heavy users won't run into a collision before our sun goes supernova, so you can probably get away with shorter ones.

-Andrew

--

Andrew Lee

Founder, Firebase

http://twitter.com/startupandrew

[Rick Giusti]

Jonathan, Andrew,

Thanks for your replies.

A) It looks like I'm not missing anything with regards to Firebase, which is
reassuring, thanks.

B) I have an aversion against hoping for no collisions (something I may just
have to get over). If one uses a "collisions possible" method, one has to
guess at the optimal tradeoff between "long enough so that collisions are
unlikely" and "short enough for a user to transcribe accurately". I will mull
on this.

Again, thanks.

Rick

[Jonathan Friedman]

More brain dump... ;-)

You should also consider that there is a difference between
"provably-correct" collision-free and effectively collision-free.

For example, a simple (somewhat common) heuristic is to encode the
date/time of the request in base 36 (a-z, 0-9) -- or base 62 (A-Z,
a-z, 0-9) if your app can tolerate being case sensitive.

Theoretically, you could receive two initial requests at precisely (to
the resolution of the OS clock) the same time, but that's extremely
unlikely -- or handle it by adding 1 to one of the requests since they
would both be available at the same time and you could know about that
collision if you instrumented the app correctly.

You end up with some pretty short IDs this way with little fuss: 10
years (pick something reasonable), 12 months, 31 days, 24 hours, 60
minutes, 60 seconds (collect requests in 1 second buckets to resolve
conflicts).

= 321,408,000 values to uniquely define the timestamp

= only SIX characters in base36 encoding

Cheers,
-Jonathan

[Tobi Reif]

It makes sense to generate an ID on the client in order to provide it
immediately / avoid waiting for network latency/roundtrip.

But in case where the scenario calls for absolutely unique IDs, Firebase
could offer an alternative where IDs can be requested and are provided
by the server, 100% unique per app / Firebase. (It could simply start
with a "1".)

The developer could (per app) decide between fast and unlikely to
collide vs a bit slower and unique (100% unique per app).

(I'm referring to IDs used for each message ( snapshot.name() ) and the
case where push() is used to get a unique ID for some specific use.)

Tobi

--
http://tobireif.com

[Andrew Lee]

You actually can generate guaranteed-unique auto-incrementing numbers already. You just need to use a transaction() on a counter. Increment it each time you want a new ID.

-Andrew

an email to firebase-talk+unsubscribe@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Tobi Reif]

Thanks for the tipp! I found a nice example by Vikrum linked from
http://stackoverflow.com/questions/16127389/real-time-click-link-counter
. (The actual code for the transactional counter is amazingly short,
nice API :) )

The above is useful for generating unique IDs for various uses.
Regarding the IDs set on push etc (per object / DB record):

Perhaps it would make sense to offer a setting per Firebase, where
(before the Firebase gets used) the developer can choose between two
options:
A) The IDs are available immediately and are highly unlikely to collide.
B) The IDs are available after a short lag (server roundtrip latency)
but are guaranteed to never collide. (They first ID could be "1".)

Option A is how it currently works AFAIK, and option B could be offered
as alternative in the future.

Tobi

--
http://tobireif.com

On 7/12/13 8:06 PM, Andrew Lee wrote:
> You actually can generate guaranteed-unique auto-incrementing numbers
> already. You just need to use a transaction() on a counter. Increment it
> each time you want a new ID.
>
> -Andrew
>
>
> On Thu, Jul 11, 2013 at 1:46 AM, Tobi Reif <to...@tobireif.com
> <mailto:to...@tobireif.com>> wrote:
>
> It makes sense to generate an ID on the client in order to provide
> it immediately / avoid waiting for network latency/roundtrip.
>
> But in case where the scenario calls for absolutely unique IDs,
> Firebase could offer an alternative where IDs can be requested and
> are provided by the server, 100% unique per app / Firebase. (It
> could simply start with a "1".)
>
> The developer could (per app) decide between fast and unlikely to
> collide vs a bit slower and unique (100% unique per app).
>
> (I'm referring to IDs used for each message ( snapshot.name

> <http://snapshot.name>() ) and the case where push() is used to get

> an email to firebase-talk+unsubscribe@__googlegroups.com
> <mailto:firebase-talk%2Bunsu...@googlegroups.com>.

> To post to this group, send email to
> fireba...@googlegroups.com

> <mailto:fireba...@googlegroups.com>__.
> For more options, visit
> https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>.

>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Firebase Google Group" group.
> To unsubscribe from this group and stop receiving emails from it,

> send an email to firebase-talk+unsubscribe@__googlegroups.com
> <mailto:firebase-talk%2Bunsu...@googlegroups.com>.

> To post to this group, send email to fireba...@googlegroups.com

> <mailto:fireba...@googlegroups.com>__.
> For more options, visit https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>.

>
>
>
>
>
> --
> Andrew Lee
> Founder, Firebase
> http://twitter.com/startupandrew
>

> --
> You received this message because you are subscribed to the Google
> Groups "Firebase Google Group" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to firebase-tal...@googlegroups.com.

[Michael "Kato" Wulf]

In answering another thread, I came up with an example which demonstrates unique, incremental ids by using a transaction counter. It might be useful for this case too. I've posted a fiddle demonstrating the behavior, and the security rules that enforce it.

--

Michael "Kato" Wulf

Firebase Team

        <mailto:firebase-talk@googlegroups.com>__.

        For more options, visit
        https://groups.google.com/__groups/opt_out
        <https://groups.google.com/groups/opt_out>.

    --
    You received this message because you are subscribed to the Google
    Groups "Firebase Google Group" group.
    To unsubscribe from this group and stop receiving emails from it,

    send an email to firebase-talk+unsubscribe@__googlegroups.com
    <mailto:firebase-talk%2Bunsu...@googlegroups.com>.

    To post to this group, send email to fireba...@googlegroups.com

    <mailto:firebase-talk@googlegroups.com>__.

    For more options, visit https://groups.google.com/__groups/opt_out
    <https://groups.google.com/groups/opt_out>.

--
Andrew Lee
Founder, Firebase
http://twitter.com/startupandrew

--
You received this message because you are subscribed to the Google
Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send

an email to firebase-talk+unsubscribe@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.