Numbers as Unique ID’s
Brent Simmons talking about sync for Vesper:
Here’s the thing: unique IDs for notes and users are 64-bit integers in my system.
This actually surprised me a bit. My old co-worker, Brian Reischl on both the NewsGator RSS Sync platform as well as Glassboard, tweeted this reply:
@brentsimmons 2^53 limit is new on me. This is why Glassboard mandated strings – fewer client side bugs to get blamed on server team. 🙂
— Brian Reischl (@brianreischl) April 14, 2014
The reason we mandated strings is because we learned a tough lesson with the NewsGator platform that broke most of our client apps including mine, NewsGator Inbox. I know FeedDemon was also affected but perhaps NetNewsWire was not, so maybe that’s why Brent didn’t feel the effect of this issue like the rest of us did.
The Day Sync Died
One day in the NewsGator office we all started to notice that our web app was no longer working correctly. I looked at NewsGator Inbox and noticed the same thing. We quickly discovered that our internal unique id assigned to each blog post in the system had become too large for the integer type we were using and had in our documentation. We had to mad scramble to patch the database, the web app and the client apps. I don’t remember exactly what the fix was, perhaps Brian does, but the lesson we both learned was to mandate strings for unique ID’s.
Brent had this thought, but dismissed it based on database bloat and inelegance. That’s a silly argument to me. As well as Brent’s other thought of leaving it to a future platform team to figure out when it becomes a problem. You see the problem now, fix it in a way so that its never a problem in the future.
Imagine if the issue does come up in the future and part of the solution is a client side code change. If the problem isn’t noticed way before it happens, your app could be broken for days while waiting for Apple review. Even if you contact Apple and push the bug fix version through, your users are still out of luck for some amount of time.
As someone who has dealt with this situation in a real world scenario, my suggestion would be to use strings as unique ID’s even if its inelegant and causes some minor database bloat. Its a good trade off to not have to worry about the problem in the future.
I should note that we had two other reasons for using strings for unique ID’s.
The first was to obfuscate any REST API calls so that guessing a number wouldn’t somehow get you access to data you weren’t suppose to see. Our security infrastructure rendered this issue moot.
The second was the idea that a client shouldn’t care what’s in a unique ID. The client should just treat the ID as an opaque string. Should the server ever need to encode additional data into an ID, which the NewsGator Platform eventually needed for performance, it shouldn’t effect how clients interact with that ID. I realize Vesper generates some ID’s on the client (which I find to be an intriguing design decision) so this concern doesn’t apply, but I wanted to further explain our approach.