Axum은 tokio와 hyper를 제대로 사용하기 위해서 만들어진 서버 프레임워크인 만큼 다른 Tokio 생태계의 라이브러리들과 매끄럽게 연결됩니다. 특히 다른 프레임워크에서도 많이 사용하고, 다양한 미들웨어(middleware) 기능이 미리 구현되어 있는 미들웨어 크레이트인 tower와의 연동이 매우 간편합니다. 이러한 이유에서 Tokio 생태계에서 제공하는 다양한 기능을 쉽게 통합해서 사용하려면 Axum이 가장 적합한 선택입니다.
--- p.7

또한 특정 경로를 다른 경로로 변경할 때도 여러 번 경로를 수정해야 하는 번거로움이 있습니다. 예를 들어 /user 경로를 /my_user로 바꾸려면 라인 4개를 일일이 고쳐야 하기 때문에 번거로운 데다 실수로 이름을 잘못 넣을 가능성도 있습니다. 이런 이유에서 route 메서드를 계속 연결하는 방법은 라우터에서 정의하고자 하는 경로와 핸들러의 가짓수가 많을 때는 바람직하지 않습니다. / 이처럼 경로와 핸들러가 많아지는 경우 코드가 길어지고 관리가 어렵기 때문에, 하나의 경로에 여러 개의 핸들러를 묶는 방법을 사용하면 문제를 간단하게 해결할 수 있습니다. route 함수의 두 번째 매개변수로 get, post, put, delete 메서드를 연결해주면 됩니다.
--- p.50

Entity에서 EntityTrait를 사용해 테이블 레코드를 표현했던 것처럼 ActiveModel에서는 ActiveModelTrait를 사용해 변경 가능한 테이블 레코드를 나타내고 있습니다. 해당 트레이트를 구현하면 구조체의 각 필드에서 객체의 값을 변경하는 함수인 insert와 update를 사용할 수 있습니다. 두 함수는 객체의 변경사항을 데이터베이스에 적용하는 역할을 수행합니다.
--- p.117

그런데 만일 id 필드에 정수형이 아닌 문자열이 들어오거나, 데이터베이스 쿼리 도중 에러가 발생하면 어떻게 될까요? 문자열을 정수로 변환하는 함수인 parse::〈i32〉에서 unwrap을 호출하기 때문에 정수형이 아닌 문자열이 입력되는 경우에는 즉시 패닉이 발생하게 됩니다. Axum은 핸들러에서 패닉이 발생하더라도 애플리케이션이 종료되지 않고 다른 요청을 계속해서 처리할 수 있습니다. 하지만 패닉이 발생하면 해당 핸들러는 곧바로 종료되기 때문에 사용자에게는 어떤 문제로 요청이 제대로 처리되지 않았는지가 전달되지 않습니다. 그러면 사용자는 요청이 잘못된 것인지, 서버에 문제가 생긴 것인지 알 수 없기 때문에 같은 요청을 여러 번 보내거나 서버 측의 문제인지를 직접 확인해야 하는 불편함이 생깁니다.
--- p.133

Users와 마찬가지로 업서트(upsert)를 위한 별도 모델이 필요하고 핸들러도 거의 동일합니다. 다만 get_product 함수에서 쿼리 파라미터의 종류가 많기 때문에 불필요한 타입 검사를 피하기 위해 쿼리 파라미터에서도 UpsertModel을 사용한다는 점이 약간 다릅니다. 만일 쿼리 파라미터에 타입을 HashMap〈String, String〉과 같이 지정했다면 id와 price가 해시맵에 포함되어 있는지, 그리고 타입이 정수형인지를 별도로 검사해야 하기 때문에 코드가 길어지고 복잡해졌을 것입니다. UpsertModel은 역직렬화 과정에서 타입을 자동으로 처리해주기 때문에 코드가 훨씬 간결해집니다.
--- p.143

압축하지 않을 때 응답 시간이 줄어든 것은 압축 알고리즘의 실행에 시간이 소요되기 때문인데, 파일의 크기가 크거나 서버와 클라이언트가 물리적으로 멀리 떨어져 있는 경우에는 데이터를 압축하는 데 드는 시간보다 작은 크기의 압축된 데이터를 보내는 것이 더욱 효율적이기 때문에 걱정하지 않아도 됩니다. / 참고로 추가하지 않은 피처의 압축 방법으로 Accept-Encoding 헤더를 포함해 보내더라도 Axum에서는 에러가 발생하지 않는 것을 볼 수 있습니다. 하지만 데이터가 압축되지 않은 상태로 전송되기 때문에 정확한 압축 방법을 명시해서 보내는 것이 효율적인 데이터 전달을 위해서 중요합니다.