Using the Type System to Handle Identities

When building a sandboxed application running against cloud data (I prefer that to 'web developer') you have data objects. These typically have ids. In the old days these ids were integers, probably databases created identities. This was great because databases are good at making ids without collisions and you can then use these ids to query the database.

So in your typed language (C# in my case), you would happily have something like 'int id'. There are a couple issues I have with this. But first, I will fast forward us to today. As web developers grow more and more conscious of security, they realized that exposing these database ids to end users was potentially insecure because you could then guess about certain things and give away information. I create a new company and get an id of 500. I know you have 500 entries in your table. I also know the id of the last company and the next company. So we switched to guids, which are pretty hard to guess. So you would have something like 'Guid id' instead of int id.

I mainly do JavaScript with a blanket of TypeScript. The typing system is fairly loose under the covers. You know what I do? I just type ids to 'string'. This works for ints or guids. I am just saving them, maybe displaying them, but mainly just sending them back in json. It is fine for them to be strings. What I always said was, "Why does it need to be an int? It isn't like I am adding something to it." The same goes for Guid. I just want a unique thing that can be compared with another unique thing to determine sameness. It just happens that machines are good at making and comparing integers and guids (yes, a guid is mathematically an integer, but not in programming).

In my current project we have many kinds of ids. We have ids on people, ids of assessments, and all sorts of other ids. We are also switching over to using guids, another set of ids. We now have an interested class of problems that I will refer to as 'id confusion'. If I have an int or a guid, I know it is an id, but what kind of id? Two different ids are in no way compatible. You can take an id for a user and make it into an id for an assessment.

If only we had some way to have the compiler make sure that this class of problem does not occur... We could call it an 'Id Type System'. Or perhaps just a 'Type System'. <puts finger in ear pretending his producer is talking to him> I am being informed that modern programming languages do indeed have a type system...

Skip to Conclusion

You should build a type to wrap an id. This allows the type system to track how you use an id and won't allow ids to be confused with other ids. This also allows you to modify your id representation without changing types throughout your system. Your code also becomes much clearer because instead of passing around 'int' you have meaningful type information in your method signatures.

Simple, practical.