Solidify use cases

[blm768]

The original use case for this project involved improving type safety of phone number storage and making it more compact. With the realization that a fixed-size format was inadequate, development has moved toward a new variable-length PhoneNumber type, which, although more compact than raw strings, doesn't provide major space savings. On top of that, I realized that applications which store phone numbers in a database tend to do their own parsing and validation on the front end, which somewhat reduces the impact of the type safety advantanges.

At some point, the advantages of having a dedicated PhoneNumber type would need to outweigh the costs (i.e. potential for instability, administrative overhead for installation and maintenance, etc.) for this library to see meaningful use.

With all that being said, what additional use cases exist for libphonenumber bindings in PostgreSQL? There's likely something I'm not thinking of.

[Caerbannog]

Use case : guessing the home country of a user from his phone number to switch features based on the market. An alternative is parsing with regular expressions when few countries matter for the business.

[blm768]

Use case : guessing the home country of a user from his phone number to switch features based on the market.

That could be useful, although I'd imagine that in many cases, that would be happening in the application logic (which could generally use libphonenumber directly) rather than in the database.

[EvanCarroll]

On top of that, I realized that applications which store phone numbers in a database tend to do their own parsing and validation on the front end, which somewhat reduces the impact of the type safety advantanges.

It's never sufficient to only do validation on the front-end. The unity here is when the front end and back end use the same code to do validation. That's quickly approaching with webassembly. World isn't fully there yet though, and google does generate a js library that uses libphonenumber, https://github.com/google/libphonenumber/tree/master/javascript

This reduces the maintenance on anyone to using libphonenumber on the backend, and libphonenumberjs on the frontend.

[blm768]

It's never sufficient to only do validation on the front-end.

True, yes. In recent projects, though, I've found it works pretty well to have phone number validation in the frontend and application layer, with less strict validation in the database. Validation at the application layer tends to produce better error messages than the database can with, say, a CHECK constraint.

[EvanCarroll]

Sure, but ideally they're both equally strong and doing the same thing. You validate on the front end because you can get better errors and quicker responses. You validate on the backend to make sure they're using only front-ends with validation, and not a crafted post request with curl. ;)

[blm768]

You validate on the backend to make sure they're using only front-ends with validation, and not a crafted post request with curl. ;)

To clarify, what I was describing does include backend validation. It just happens in application code, not the database.

• Frontend: performs validation for convenience (probably using the JS port of libphonenumber)
• Backend application code: validates for correctness (using either JS or native libphonenumber)
• Database: either uses libphonenumber again (redundant if all application-layer components validate) or just has a basic regex CHECK constraint to make sure we're not accidentally inserting total nonsense (simple, low maintenance cost).