วีดีโอ

I tried to cover the main advantages and disadvantages from both the Database and the UI point of view. but if you have further points that you want people to know, feel free to add your notes

Glad you enjoy it!

Thank you, I really appreciate!

The video is more about the frontend sending large data and dividing it up in chunks. but the same may apply on the backend side where a service has to send large data to another service.

Thank you! really appreciated.

Thank you! i'm glad you enjoyed it

You can use 3rd party libraries that provides already simple functions to generate the uuidv7/ulid. github.com/LiosK/uuidv7 github.com/kripod/uuidv7 github.com/aarondcohen/id128 github.com/ulid/javascript

Glad you liked it! thanks for watching!

Thank you!

Thanks! I'm glad you enjoyed it

Thanks for checking them out! I hope they were helpful.

Great! I'm glad it was helpful

Hi, Thank you! I'm glad the video were helpful. Where I currently work Java is the main language, along with javascript/typescript and Python, but in my free time I still prefer toying with C, Go and Rust. If you have any suggestions to improve the videos or you have any specific topic that you are interested in, let me know and if I have the knowledge I'll try to cover it.

Hi! I'm glad the content was helpful. There will surely be more videos on database and backend stuff. If you have any specific topic that you are interested in, let me know and if I have the knowledge I'll try to cover it.

It's not a problem it's a characteristic of UUID v4. If you need an ID that can be generated offline (similar to UUIDs) but with some sequentiality ULID, UUID v7 or Snowflake ids are what you looking for. Checkout this video that talks about the different behaviour, from a storage point of view, of the two type of IDs th-cam.com/video/2MbFDR7qt5U/w-d-xo.html.

Hi, thanks for watching! 1. You can have any data filtering in your query. The pagination query must contains the filter AND the key condition (filter-cond AND key-cond). In the example of news feed is quite common have something like: WHERE topic = 123 AND (date, id) < (prev_date, prev_id) 2. backward direction is a "limitation" of the keyset pagination. If you use infinite scrolling you don't need a query to go back, since you already have all the previous data locally. If you start from a specific position the only way to go back is to do the query but with the reverse sort order, which means that you have to keep two indexes for both directions.

@@th30z-code 1. When using data table/grid in frontend we usually deal with arbitrary sorting. Can the pagination still handle that kind of sorting well. 2. You are right, we already have all the prev data locally. Make sense. Thank you so much

Arbitrary sorting does not play well with databases. unless there is a specific index for the sort order, It's a lot of memory and cpu usage. so every time a request comes in there is a full table scan and a sort operation. It's ok for 10 apps with few users that access the table/grid sporadically, but if you have a bit of traffic it is better to fetch all the main columns you see in the table and sort them locally. If you have large fields (e.g. blobs, or something hidden with an expander) you can fetch them on demand using the key of the row. Fetching everything should cost less than asking the db to sort everytime. In terms of data should not be that much (e.g. 32bytes per column, 10 columns 10k rows are 3MB)

From a data block point of view ULID and UUIDv7 are almost the same thing, since they are both 48bit timestamp + "random data". But the 6bit for version and variant of the UUID format makes them incompatible. The conversion from ULID to UUID will result in losing information. Truncating those 6bits and replacing them with v7 and the variant should not be a problem, but in the worst case it may generate collisions. Converting from UUIDv7 to ULID is not a problem since there is no data loss. From a textual representation point of view, the ULID has the advantage to be shorter. Unfortunately there is no standard support for that, but with few lines of code you can also encode the UUID to Base32 and the Base32 to UUID assuming you are interested in converting them (e.g. if you are using type UUID "type" that your language provides). I hope I have answered your question. Thanks for watching!

@@th30z-code yeah I wonder if the difference of 6 bits would make a difference in practical application as of course the length would effect how likely a birthday collision may occur in a distributed system. I am also checking with the spec writer if it would make sense to also standardise on an optional extended ULID that would include a checksum as there may be a chance that people may be writing these IDs down on paper as well. Was looking at Crockford bade32 checksum char which adds 4 more symbols, but his use of = in checksum chars would be hard to use in a url... So might be better if it was appended with a _ to the original ULID string but where the extra characters are the CRC-8 or something easily implemented check instead.

In practices you can ignore the probability to generate a collision with both UUID/ULID. I've seen many systems in production blindly trusting the random implementation (but don't use javascript Math.random(), or any pseudo-random generator for your implementation). But yeah, from a numeric point of view, the missing 6bit makes a difference: with ULID the probability of collision in a given millisecond is 1 out of 1208925819614629174706176 (2^80). with UUIDv7 the probability of collision in a given millisecond is 1 out of 18889465931478580854784 (2^74). but it's still a really really low probability. To me, as for all the error handling logic, the question is: Is my code putting a life at risk or not. if not, you can trust the implementation and don't bother about the collision probability. If your ULID/UUID are generated from an enumerable number of machines, you can switch to a different ID generation strategy and remove completely the problem of collisions and even reducing the length of your IDs. Check out the Twitter Snowflake IDs: th-cam.com/users/shortseHr2EIRcYZY

Yeah, sorry you are not the first one reporting the confusion between "client side" and "server side" even if quoted. what I meant was more like IDs generated and passed to the storage/service (client side) vs IDs generated by a single source which is probably the storage itself (server side). so things like Snowflake Ids to me are "client side" since they are not coordinate or created by a central point, but yeah on the comparison I left them a bit out and assumed the larger IDs. you are also right that is not that simple as passing the ID and use that directly, but it's easier to explain the concept of coordinated vs uncoordinated operations without having to go through all the security stuff. For example when you work with mobile apps, and you have to work offline you always have things like (user_id, device_id, uuid) which means that an attacker must have the device session to be able to play with the uids directly. thanks for the feedback!

I'm glad it was useful!

Thank you! I'm glad it was useful

Even if the database doesn't know about the type (UUIDv7), the layout of the UUIDv7 (the timestamp in the beginning) is made specifically to make the IDs sort by timestamp, and you can leverage btree indexes. so, you can make an efficient between, less-than, greater-than query even if the uuid is stored as binary or text (hex retain the numeric order) '01893bdf-37a3-0000-0000-000000000000' < '01893be0-8c25-0000-0000-00000000000' If the database implementation is aware about the UUIDv7 type, and gives you the ability to filter only by timestamp. it can just look at the first 48bit, and discarding the rest. the sort order given by the uuid layout is already correct.

@@th30z-code awesome, thanks

Glad you enjoyed it!