Hacker News new | ask | show | jobs
by kylef 3765 days ago
Yes, this framework in particular doesn't demonstrate the benefits and uses of the type-safety and compile-time safety in Swift.

Check out Frank (https://github.com/nestproject/Frank#routes) which offers type-safe and compile-time safe path routing.

You define a closure to handle requests matching paths with type-safety. You are passed the correct parameter types and the correct amount of parameters directly to your closure. This gives you compile type safety.

    // Handle GET requests to path /users/{username}
    get("users", *) { (request, username: String) in
      return "Hello \(username)"
    }
In contrast, without this compile-time safety you will most likely be passed an array of Strings and you will have to pull items out.

    Route.get("users/:username") { request in
      if let username = request.parameters["username"] {
        // Return something with username
      } else {
        // TODO Return 404
      }
    }
Here you have to manually validate these parameters, there is also the lack of compile time safety in the way you are writing a hard-coded string for each parameters. There is a string "username" twice, both the path and when you pull out the parameter from the array. There is a large room for user error or typos here.
1 comments

Thanks for the clarifications. As soon as web text-based protocols were mentioned, I said "oh duh" to myself. There's nothing about the availability of a type system that forces a plain-data wrapper library to use it.