maxdeviant

Thanks for the report, this should be fixed now!

We've adjusted it so that the CLA can now be viewed without signing in.

Sorry about that!

I'm not familiar with Keycloak. I glanced at their docs briefly, and it looks like Keycloak manages your users for you?

WorkOS only handles SSO, so all of our users are still stored in our own database. This is one of the big reasons we went with WorkOS as opposed to something like Auth0 or AWS Cognito.

Yes. This is exactly what we do at work.

It makes sure that you never pass a `LocationId` where a `UserId` is expected; the type system literally will not allow it.

Dark looks really cool. When I heard about it before my initial reaction was a huge "nope", but after watching the videos I'm curious to try it out.

It's amazing just how little friction there is for you to get an API endpoint backed by a datastore up and running. That being said, there are a bunch of unknowns. Having my entire application, even down the language it's implemented in, being proprietary is a little scary.

Will definitely be looking forward to playing around with this. Just as soon as I get my signup email ;)

The problem I have with this style of validation is that it doesn't "make illegal states unrepresentable". If the validation is not run then it is still possible for instances of `ContactData` that violate the business rules to enter the system.

  > Our reservation business requires that contact data entities are only accepted if all of the following conditions are satisfied:
  >
  > - The e-mail address is valid
  > - The phone number is valid
  > - Either e-mail address, or phone number, or both are present

In this case, all of the above rules can be encoded into the type system itself. Here's how I would approach this particular problem:

  struct PhoneNumber(String);
  
  impl PhoneNumber {
      fn new(value: String) -> Result<Self, ValidationError> {
          if is_valid_phone_number(value) {
              Ok(Self(value))
          } else {
              Err(ValidationError)
          }
      }
  }
  
  struct EmailAddress(String);
  
  impl EmailAddress {
      fn new(value: String) -> Result<Self, ValidationError> {
          if is_valid_email_address(value) {
              Ok(Self(value))
          } else {
              Err(ValidationError)
          }
      }
  }
  
  enum ContactData {
      PhoneOnly(PhoneNumber),
      EmailOnly(EmailAddress),
      PhoneAndEmail {
          phone: PhoneNumber,
          email: EmailAddress
      }
  }

This approach, when applied alongside Rust's modules and visibility modifiers, would make it impossible for any of these types to be in an invalid state.

F#