Facebook is a PHP-based web application over a MySQL database. As such, Facebook must face two basic problems. First, there's the security of user information. Second, the visibility of user information on the web. Basically, Facebook deals with these problems using URL rewriting or, more precisely, a well-known architecture of URLs. As a rule of thumb, when Facebook has to handle user information simply as mere settings, data transaction or, more broadly, as internal preferences, it uses the form facebook.com/script.php?parameter=value, that is, a "dirty" URL with several parameter/value pairs attached to it. On the contrary, when Facebook has to display user information publicly (that is, in a way that search engines can handle), URLs are always treated in an human-friendly way, such as www.facebook.com/username.
Bear in mind, however, that Facebook URLs change depending on the user's status, that is, if a user is or is not logged in. For example, when you're logged in and you run a search for a person, then his/her public profile URL is displayed using a SEO-friendly URL. Conversely, if you're not logged in, URLs are often returned using the ID of the profile, such as 11099990, for example. From a server-side scripting perspective, there are a few things to bear in mind:
- username vs user ID
Working with a database, you may find the latter solution easier, because you don't have to deal with string formatting, for example when you have to turn the first and last name of a person into a username such as
gabrieleromanato. But if you want to preserve a good level of visibility on the web for your users, the former is always a good solution. - URL rewriting
Either if you're using an MCV architecture for your application or a mixed one, you should define several rules in your web server configuration for handling URL rewriting. As a rule of thumb, try to split your URLs into two main categories (e.g. internal URLs and public URLs) and then write your rules accordingly.