feat: add uuid or else

2022-07-12 15:33:38 +07:00 · 2022-07-12 15:33:38 +07:00 · 8772dc9447
parent cb822c0486
commit 8772dc9447
4 changed files with 38 additions and 1 deletions
--- a/docs/2022-07-12-uuid-or-else.html
+++ b/docs/2022-07-12-uuid-or-else.html
@ -0,0 +1 @@
+<!doctype html><meta charset=utf-8><meta name=viewport content="width=device-width,initial-scale=1"><link rel=preconnect href=https://fonts.googleapis.com><link rel=preconnect href=https://fonts.gstatic.com crossorigin><link href="https://fonts.googleapis.com/css2?family=Recursive:wght,CASL,MONO@300..800,0..1,0..1&display=swap" rel=stylesheet><link rel=stylesheet href=styles.css><h1>UUID or else</h1><p>There are many use cases where we need to use a unique ID.<br>In my experience, I only encouter 2 cases:<ul><li>ID to trace request from client to server, from service to service (microservice architecture or nanoservice I don't know).<li>Primary key for database.</ul><p>In my Go universe, there are some libs to help us with this:<ul><li><a href=https://github.com/google/uuid>google/uuid</a><li><a href=https://github.com/rs/xid>rs/xid</a><li><a href=https://github.com/segmentio/ksuid>segmentio/ksuid</a><li><a href=https://github.com/oklog/ulid>oklog/ulid</a></ul><h2>First use case is trace ID, or context aware ID</h2><p>The ID is used only for trace and log.<br>If same ID is generated twice (because maybe the possibilty is too small but not 0), honestly I don't care.<br>When I use that ID to search log , if it pops more than things I care for, it is still no harm to me.<p>My choice for this use case is <strong>rs/xid</strong>.<br>Because it is small (not span too much on log line) and copy friendly.<h2>Second use case is primary key, also hard choice</h2><p>Why I don't use auto increment key for primary key?<br>The answer is simple, I don't want to write database specific SQL.<br>SQLite has some different syntax from MySQL, and PostgreSQL and so on.<br>Every logic I can move to application layer from database layer, I will.<p>In the past and present, I use <strong>google/uuid</strong>, specificially I use UUID v4.<br>In the future I will look to use <strong>segmentio/ksuid</strong> and <strong>oklog/ulid</strong> (trial and error of course).<br>Both are sortable, but <strong>google/uuid</strong> is not.<br>The reason I'm afraid because the database is sensitive subject, and I need more testing and battle test proof to trust those libs.
--- a/docs/index.html
+++ b/docs/index.html
@ -1 +1 @@
-<!doctype html><meta charset=utf-8><meta name=viewport content="width=device-width,initial-scale=1"><link rel=preconnect href=https://fonts.googleapis.com><link rel=preconnect href=https://fonts.gstatic.com crossorigin><link href="https://fonts.googleapis.com/css2?family=Recursive:wght,CASL,MONO@300..800,0..1,0..1&display=swap" rel=stylesheet><link rel=stylesheet href=styles.css><h1>Index</h1><p>This is where I dump my thoughts.<ul><li><a href=2022-06-08-backup>Backup my way</a><li><a href=2022-06-08-dockerfile-go>Dockerfile for Go</a><li><a href=2022-07-10-bootstrap-go>Bootstrap Go</a></ul>
+<!doctype html><meta charset=utf-8><meta name=viewport content="width=device-width,initial-scale=1"><link rel=preconnect href=https://fonts.googleapis.com><link rel=preconnect href=https://fonts.gstatic.com crossorigin><link href="https://fonts.googleapis.com/css2?family=Recursive:wght,CASL,MONO@300..800,0..1,0..1&display=swap" rel=stylesheet><link rel=stylesheet href=styles.css><h1>Index</h1><p>This is where I dump my thoughts.<ul><li><a href=2022-06-08-backup>Backup my way</a><li><a href=2022-06-08-dockerfile-go>Dockerfile for Go</a><li><a href=2022-07-10-bootstrap-go>Bootstrap Go</a><li><a href=2022-07-12-uuid-or-else>UUID or else</a></ul>
--- a/posts/2022-07-12-uuid-or-else.md
+++ b/posts/2022-07-12-uuid-or-else.md
@ -0,0 +1,35 @@
+# UUID or else
+
+There are many use cases where we need to use a unique ID.
+In my experience, I only encouter 2 cases:
+
+- ID to trace request from client to server, from service to service (microservice architecture or nanoservice I don't know).
+- Primary key for database.
+
+In my Go universe, there are some libs to help us with this:
+
+- [google/uuid](https://github.com/google/uuid)
+- [rs/xid](https://github.com/rs/xid)
+- [segmentio/ksuid](https://github.com/segmentio/ksuid)
+- [oklog/ulid](https://github.com/oklog/ulid)
+
+## First use case is trace ID, or context aware ID
+
+The ID is used only for trace and log.
+If same ID is generated twice (because maybe the possibilty is too small but not 0), honestly I don't care.
+When I use that ID to search log , if it pops more than things I care for, it is still no harm to me.
+
+My choice for this use case is **rs/xid**.
+Because it is small (not span too much on log line) and copy friendly.
+
+## Second use case is primary key, also hard choice
+
+Why I don't use auto increment key for primary key?
+The answer is simple, I don't want to write database specific SQL.
+SQLite has some different syntax from MySQL, and PostgreSQL and so on.
+Every logic I can move to application layer from database layer, I will.
+
+In the past and present, I use **google/uuid**, specificially I use UUID v4.
+In the future I will look to use **segmentio/ksuid** and **oklog/ulid** (trial and error of course).
+Both are sortable, but **google/uuid** is not.
+The reason I'm afraid because the database is sensitive subject, and I need more testing and battle test proof to trust those libs.
--- a/posts/index.md
+++ b/posts/index.md
@ -5,3 +5,4 @@ This is where I dump my thoughts.
 - [Backup my way](2022-06-08-backup)
 - [Dockerfile for Go](2022-06-08-dockerfile-go)
 - [Bootstrap Go](2022-07-10-bootstrap-go)
+- [UUID or else](2022-07-12-uuid-or-else)
				`@ -0,0 +1 @@`
				<!doctype html><meta charset=utf-8><meta name=viewport content="width=device-width,initial-scale=1"><link rel=preconnect href=https://fonts.googleapis.com><link rel=preconnect href=https://fonts.gstatic.com crossorigin><link href="https://fonts.googleapis.com/css2?family=Recursive:wght,CASL,MONO@300..800,0..1,0..1&display=swap" rel=stylesheet><link rel=stylesheet href=styles.css><h1>UUID or else</h1><p>There are many use cases where we need to use a unique ID.<br>In my experience, I only encouter 2 cases:<ul><li>ID to trace request from client to server, from service to service (microservice architecture or nanoservice I don't know).<li>Primary key for database.</ul><p>In my Go universe, there are some libs to help us with this:<ul><li><a href=https://github.com/google/uuid>google/uuid</a><li><a href=https://github.com/rs/xid>rs/xid</a><li><a href=https://github.com/segmentio/ksuid>segmentio/ksuid</a><li><a href=https://github.com/oklog/ulid>oklog/ulid</a></ul><h2>First use case is trace ID, or context aware ID</h2><p>The ID is used only for trace and log.<br>If same ID is generated twice (because maybe the possibilty is too small but not 0), honestly I don't care.<br>When I use that ID to search log , if it pops more than things I care for, it is still no harm to me.<p>My choice for this use case is <strong>rs/xid</strong>.<br>Because it is small (not span too much on log line) and copy friendly.<h2>Second use case is primary key, also hard choice</h2><p>Why I don't use auto increment key for primary key?<br>The answer is simple, I don't want to write database specific SQL.<br>SQLite has some different syntax from MySQL, and PostgreSQL and so on.<br>Every logic I can move to application layer from database layer, I will.<p>In the past and present, I use <strong>google/uuid</strong>, specificially I use UUID v4.<br>In the future I will look to use <strong>segmentio/ksuid</strong> and <strong>oklog/ulid</strong> (trial and error of course).<br>Both are sortable, but <strong>google/uuid</strong> is not.<br>The reason I'm afraid because the database is sensitive subject, and I need more testing and battle test proof to trust those libs.