מה למדתי מ Rocket על ניהול תלויות
רוקט היא ספריית פיתוח ווב ל Rust. למפתח המרכזי שלה קוראים סרחיו בניטז והוא מפתח את רוקט מאז 2016. אם אתם כמוני, כלומר אנשים שנלחצים מפרויקטי צד של בן אדם אחד שעדיין נמצאים בגירסה 0.5 אז אולי לא תרצו לבחור את רוקט בתור תשתית לפרויקט הבא שלכם, וזה בסדר. אבל אפילו אם זה המצב הספריה עדיין מעניינת ומציגה מבט רענן על פיתוח ווב בתוך שפה עם הגדרת טיפוסים סטטית. דוגמת ה Hello World שלהם נראית כך:
#[macro_use] extern crate rocket;
#[get("/hello/<name>/<age>")]
fn hello(name: &str, age: u8) -> String {
format!("Hello, {} year old named {}!", age, name)
}
#[launch]
fn rocket() -> _ {
rocket::build().mount("/", routes![hello])
}
והיא מייצרת נתיב עם שני משתנים, name ו age שבגלישה אליו יחזיר הודעת טקסט עם הערכים.
זה לבד נראה אחלה ועושה חשק להמשיך ללמוד, אבל הנושא של הפוסט היום הוא דווקא לא רוקט אלא פיצ'ר ספציפי של רוקט שנקרא Request Guards. הרעיון מאוד מזכיר את ה Middlewares של אקספרס ואומר שכשיש לי בקשה אז לפני שאני מגיע לקוד הטיפול בנתיב קודם צריך לעבור דרך ה"שומרים" שיקחו מידע מהבקשה ויאתחלו משתנים מסוימים, שאחרי זה עוברים כפרמטרים לנתיב.
הדוגמה הבאה ממחישה את הקונספט לא רע:
#[get("/sensitive")]
fn sensitive(key: ApiKey) { /* .. */ }
בהנחה שיש לנו טיפוס בשם ApiKey והטיפוס מממש התנהגות בשם FromRequest, אז לפני שרוקט תעביר את הטיפול לנתיב שהגדרנו היא תנסה "ליצור" ApiKey מהבקשה.
הדוגמה הבאה מציגה פונקציה יותר מפורטת שתיקרא רק אם משתמש במערכת מנסה לגשת לנתיב:
/// This route is chosen if the request guard for User passes (e.g. logged in).
#[get("/")]
fn home(user: User, _cookies: Cookies) -> Markup {
html! {
head {
title {"Welcome | Auth0 Rocket Example"}
link rel="stylesheet" href="static/css/style.css";
}
body{
h1 {"Guarded Route"}
div {p {
"You logged in successfully."
}}
div {p {
"Email: " (user.email)
}}
div {p {
a class="login" href="/profile" {"Another private route"}
}}
}
}
}
כשהקוד של User הוא:
#[derive(Debug, Serialize, Deserialize)]
struct User {
user_id: String,
email: String,
}
impl<'a, 'r> FromRequest<'a, 'r> for User {
type Error = ();
fn from_request(request: &'a Request<'r>) -> Outcome<User, ()> {
let session_id: Option<String> = request
.cookies()
.get("session")
.and_then(|cookie| cookie.value().parse().ok());
match session_id {
None => {
println!("no session id");
rocket::Outcome::Forward(())
}
Some(session_id) => {
println!("session id: {}", session_id);
let db = State::<DB>::from_request(request).unwrap();
let session_key = make_key!("sessions/", session_id);
match db.get(&session_key.0) {
Ok(Some(sess)) => {
let sess: Session =
deserialize(&sess).expect("could not deserialize session");
if sess.expired() {
return rocket::Outcome::Forward(());
}
let user_key = make_key!("users/", sess.user_id);
match db.get(&user_key.0) {
Ok(Some(user)) => {
let user: User =
deserialize(&user).expect("could not deserialize user");
rocket::Outcome::Success(user)
}
_ => rocket::Outcome::Forward(()),
}
}
_ => rocket::Outcome::Forward(()),
}
}
}
}
}
המבנה טוב כיוון שהוא מחבר בין משהו שהפונקציה צריכה - המשתמש - לבין שורת ההגדרה של הפונקציה. אי אפשר היה להיכנס לקוד הטיפול בנתיב בלי שעברנו בקוד שקודם מפענח את ה User מתוך הבקשה.
נשווה את זה לריילס שם כל נתיב אחראי על טעינת המידע ובדיקת המשתמש:
def show
@post = Post.find(params[:id])
authorize! :read, @post
render plain: "Welcome #{current_user.name}"
end
או ל Express שם אפשר להשתמש ב Middlewares בשורת הגדרת הפונקציה:
app.get('/post/:id', authorize_user, (req, res) => {
const user = res.locals.user;
res.send(`Welcome! ${user.name}`);
});
אז בריילס המצב הכי גרוע כי הכי קל לשכוח לקרוא ל authorize או לקרוא לו עם פרמטרים לא נכונים (קרה לי יותר מדי פעמים), אבל גם ב Express המצב בעייתי כי אנחנו מתבססים על תיאום בין המידלוור authorize_user שתכתוב את המידע לשדה ב req.locals באותו שם בו הנתיב מצפה למצוא אותו. בין שלושת האפשרויות הפיתרון של רוקט הוא הטוב ביותר מאחר ואי אפשר "לשכוח" לבקש את ה User (אם תשכחו פשוט לא תקבלו את המידע על המשתמש), ולא צריך לתאם שמות בין מספר מקומות שונים בקוד.