laconia
laconia copied to clipboard
Generate a unique number
Story
As a developer, I would like to be able to generate a sequence number easily, So that I don't need to revert to RDBMS just to generate a unique sequence Or spend a long time making this work by reading blogs
Discussion
- How might laconia.js help this? How might the API look like?
- Should a sequence be generated by API Gateway? See this article
- DynamoDB can be used to generate sequences. What's everyone thoughts of make this easy for developer to do this?
- There was also scaling issue i.e. we need to make sure that sequences can be generated in parallel by supporting multiple rows.
I’m appalled that people still feel the need to do this :-)
My (admittedly limited) view is that it’s very rare that a sequence number is really really needed, it’s just that was how key allocation worked in RDBMSs so got used as a side-effect. Looking at the examples given in the article:
- order numbers generally don't need to be sequences, though purchase order numbers are a genuine use case, but this is quite a niche domain
- the college registration requirement sounds vague. If you have a genuine need to sort by application order, then use the application date (likely to be a genuine data field in the domain rather than something synthetic)?
- a counter is only a sequence under the hood. The abstraction would be something like counter.inc() and would return the new value. This is roughly what the article implements but exposes the sequence number in the response. If having a counter is a frequent requirement for serverless devs then let's implement that cleanly rather than exposing the implementation
Thanks for the input @ljcoomber
- I didn't actually have the need for the sequence number, what I needed is a unique number across the application. Sequence implies uniqueness, unique doesn't always imply a sequence.
- In our particular use case, it was actually demanded by the customers of our application; things like UUID is too long for their printed materials. We tried various approaches (a lot) to generate a unique number without a data store, until we acknowledged that it's just not possible! We actually adopted to the approach used in that article, but without the API Gateway part (we did this 2 years ago).
Building something that's too niche is undesirable. Would unique number be less niche?
Assuming that generating a unique number is less niche, an abstraction of counter
wouldn't fit the use case. Probably uniqueNumber.next()
?
I don't know how niche unique number would be, but I like the more specific use case and API proposal.
Could the UUID include chars as well as numbers?
Ah yes, I actually avoided the word UUID because it has a very specific format i.e. 32 hexadecimals.
Great! Renaming the title...