3 ms·

What's wrong with using UUIDs for microservice architectures?

by jamiethompson 10y ago

kuschku 10y ago
As mentioned in the article, they make it hard to identify the type of resource.
- AdieuToLogic 10y ago
  URN's[0] can support resource categorization so long as the Namespace Identifier (NID) does not collide with the reserved ones (and I'd throw in those which are well-known in the industry as well). So, for example, a URN which uses UUID's to satisfy uniqueness yet still allows for categorization could look like: urn:some-company:resource-type:abcdef012-3456-... For complete technical conformance, the "some-company" NID would need to be requested/registered from the IETF. In practice, my opinion is that the registration step is largely not required if the URN's are used strictly as an implementation detail within a system. However, those publicized and/or having a reasonable chance of being persisted by an external actor should have a sufficiently unique NID such that it can be registered and, more importantly, does not have a coincidental collision with other systems generating URN's. 0 - https://tools.ietf.org/html/rfc2648 https://tools.ietf.org/html/rfc2648
  - bpicolo 10y ago
    Imo, this is a great combination of strategies when you want to keep people away from iterating. It also gives you the basis for a decent ACL system. Yeah, you use a few more bytes per item, but modern DBs can handle that. Probably worth having a autoincrementing ID on tables using uuids as well, though. Not 100% sure on that, but I've definitely hit batch jobs that need to run / frameworks that require autoincrementing integer IDs, and getting stuck is a pain. (Adding an autoincrementing key after the fact is doable, but at least on postgres involves a rewrite the the entire table, so you kill the heck out of replication)
    - AdieuToLogic 10y ago
      Probably worth having a autoincrementing ID on tables using uuids as well, though. Quite true, IMHO. I usually define both an auto-incrementing integral primary key (PK) as well as a unique string column for the URN. The PK is used for deletes/updates/joins/referential integrity and is never exposed beyond the server processes.
  - jamiethompson 10y ago
    How would one best use such URNs in a REST API? An endpoint such as /products/:product-id: Would be something like? /products/some-company:products:abcdef012-3456... Seems a little clunky

What's wrong with using UUIDs for microservice architectures?

kuschku 10y ago

As mentioned in the article, they make it hard to identify the type of resource.

AdieuToLogic 10y ago
URN's[0] can support resource categorization so long as the Namespace Identifier (NID) does not collide with the reserved ones (and I'd throw in those which are well-known in the industry as well). So, for example, a URN which uses UUID's to satisfy uniqueness yet still allows for categorization could look like: urn:some-company:resource-type:abcdef012-3456-... For complete technical conformance, the "some-company" NID would need to be requested/registered from the IETF. In practice, my opinion is that the registration step is largely not required if the URN's are used strictly as an implementation detail within a system. However, those publicized and/or having a reasonable chance of being persisted by an external actor should have a sufficiently unique NID such that it can be registered and, more importantly, does not have a coincidental collision with other systems generating URN's. 0 - https://tools.ietf.org/html/rfc2648 https://tools.ietf.org/html/rfc2648
- bpicolo 10y ago
  Imo, this is a great combination of strategies when you want to keep people away from iterating. It also gives you the basis for a decent ACL system. Yeah, you use a few more bytes per item, but modern DBs can handle that. Probably worth having a autoincrementing ID on tables using uuids as well, though. Not 100% sure on that, but I've definitely hit batch jobs that need to run / frameworks that require autoincrementing integer IDs, and getting stuck is a pain. (Adding an autoincrementing key after the fact is doable, but at least on postgres involves a rewrite the the entire table, so you kill the heck out of replication)
  - AdieuToLogic 10y ago
    Probably worth having a autoincrementing ID on tables using uuids as well, though. Quite true, IMHO. I usually define both an auto-incrementing integral primary key (PK) as well as a unique string column for the URN. The PK is used for deletes/updates/joins/referential integrity and is never exposed beyond the server processes.
- jamiethompson 10y ago
  How would one best use such URNs in a REST API? An endpoint such as /products/:product-id: Would be something like? /products/some-company:products:abcdef012-3456... Seems a little clunky