Constraints on ID types like item ID, board ID, account ID and userID

Better make it a string. That’s more future proof.

Yes it is currently string in my DB. Actually I considered it string throughout also in code validation, but then the some testing infra used by monday.com in approval process cluttered my db with random strings (non-numbers), and then I had to remove those entries. So I thought if it was int/number from start, I could add those validations to prevent these sort of tests/attacks.

But then that’s the point, making it a string means that, should it ever change, your code will still work. In this case, this is similar to a stored board id which was then deleted by the user and now the board no longer exists.

Yes this makes sense too

On validation, i check it is a string of digits, validator.js has methods for this. Even if you’re checking if its a string, you should check its a string that conforms to your expectations - that would have caught their testing attempts had you don’ that.

I can change that in the future if monday ever changes the string to alpha-numeric (and create some pattern manually that conforms to their rules since they won’t be so nice as to provide one, nor even document their rules when they do so… unless they use some well known type like a UUID, KSUID, etc.)

Its best to use strings also because GraphQL returns these values as string types, and I think they fixed the mutations like board relation, dependency, people, etc. that didn’t accept strings.

Yes now I have changed my backend code to check for if string is a number.
Other thing is they send it as number in their encoded session tokens, that’s why I also had this confusion.

yes.

I use Zod for parsing and validating. So I do z.coerce.string().refine(validator.isInt) and that turns the numbers into strings. Then I just treat them as strings from then forward.