Rails 7.1 출시

 (github.com/rails)
2P by GN⁺ | ★ favorite | 댓글 1개
  • config.load_defaults 7.1 사용 시 ActiveSupport::MessageVerifier와 ActiveSupport::MessageEncryptor의 기본 직렬화가 Marshal에서 ActiveSupport::JSON으로 변경되며, 기존 Marshal 메시지는 계속 읽을 수 있음
  • ActiveRecord::Base.serialize가 기본적으로 YAML을 사용하지 않도록 변경되고, 기존 기본값은 config.active_record.default_column_serializer = YAML로 복원 가능함
  • 새 7.1 캐시 포맷이 추가되어 새 앱의 기본값으로 사용되며, 기존 앱은 config.load_defaults 7.1 또는 config.active_support.cache_format_version = 7.1로 활성화 가능함
    • 6.1 또는 7.0 캐시 포맷으로 기록된 항목은 7.1 포맷에서 읽을 수 있음
    • Rails 7.1 롤링 배포에서는 첫 배포에서 캐시 포맷을 유지하고, 이후 배포에서 7.1 캐시 포맷을 활성화해야 함
  • :message_pack 및 :message_pack_allow_marshal 직렬화가 MessageEncryptor, MessageVerifier, config.active_support.message_serializer에 추가되며, msgpack gem >= 1.7.0 필요
  • ActiveSupport::KeyGenerator, MessageEncryptor, EncryptedConfiguration, Active Record 암호화 객체의 inspect에서 비밀값 노출을 막고, ActionView::Helpers와 ERB::Util의 XSS 보호가 보강됨
  • has_secure_password에 password_challenge 검증과 #{attribute}_salt 메서드가 추가되고, authenticate_by가 계정 존재 여부에 따른 타이밍 기반 열거 공격을 줄이도록 추가됨
  • Active Record에 복합 기본키·복합 외래키 관련 지원이 확대되고, 튜플 문법 where, 복합 키 배치 정렬, 스키마에서 복합 기본키 추론을 지원함
  • PostgreSQL 지원에 enum 이름 변경·값 추가·값 변경 마이그레이션 명령, exclusion constraint, unique constraint, INCLUDE 인덱스 옵션, NULLS [NOT] DISTINCT 인덱스 지원이 추가됨
  • SQLite3 어댑터는 Write-Ahead-Log normal syncing mode, capped journal size, shared memory buffer, shared cache 설정으로 평균 2× 성능 향상이 명시되고, double-quoted string literal을 비활성화하는 strict strings mode가 기본 활성화됨
  • Active Record 전체 테이블 배치 반복은 기본적으로 range iteration을 사용해 성능이 개선되며, PostgreSQL 1천만 레코드 테스트에서 querying 253s→30s, updating 288s→124s, deleting 268s→83s 결과가 제시됨
  • MemCacheStore와 RedisCacheStore의 connection pooling이 기본 활성화되며, 비활성화하려면 캐시 스토어 설정에서 pool: false 지정 필요
  • Trilogy 데이터베이스 클라이언트용 어댑터가 추가되어 adapter: trilogy 또는 trilogy:// 형식의 DATABASE_URL 사용 가능
  • ActiveRecord::QueryLogs의 기본 태그 형식이 SQLCommenter 형식으로 변경되며, config.active_record.query_log_tags_format = :legacy로 기존 형식 사용 가능
  • 지원 중단 및 제거 항목으로 ActiveSupport::Deprecation 싱글턴 사용, SafeBuffer#clone_empty, #merge의 rewhere 인자, add_foreign_key의 deferrable: true, TestFixtures#fixture_path, 여러 deprecated Active Record 설정과 API 정리 포함
  • Action View 테스트에 ActionView::TestCase.register_parser가 추가되어 렌더링 결과 파서를 등록할 수 있으며, 기본 파서로 :html과 :json 제공됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Rails는 훌륭하고, 지금은 그 어느 때보다 좋아졌음
    커리어 초반에는 Django와 Laravel을 주로 쓰다가, 이후 요즘 흔히 하는 프런트엔드 작업으로 옮겼고, 올해 다시 Rails + Hotwire 프로젝트를 맡게 됐음
    얼마나 단순해졌는지 진심으로 놀랐고, 이렇게 쉬울 수 있다는 걸 대부분 잊어버린 게 아쉬움. 지금 업계에 들어오는 사람들은 이런 단순함을 경험하지 못할 수도 있다는 점도 무섭다
    Rails를 안 써봤거나 “PHP는 못생겼다 / Rails는 죽었다 / JavaScript는 지저분하다” 같은 얘기만 듣고 접었다면, 잠깐 남의 말은 무시하고 열린 마음으로 한번 써보길 권함
    같은 저장소에서 엔지니어 1,000명이 일하는 환경에는 최선이 아닐 수 있지만, 소규모 팀에는 경쟁자가 없고 다른 것보다 훨씬 앞서 있음. 솔직히 Laravel 정도는 비슷하게 좋을 수도 있음

    • 여기에 Phoenix LiveView도 넣고 싶음
      초기 개발 속도에서는 Rails가 늘 이긴다고 봄. 관례가 워낙 촘촘하고 잘 설계돼 있어서 비슷하게 따라오는 게 거의 없음. Laravel이 따라오고 있긴 하지만 아직은 아니라고 봄
      다만 LiveView는 모든 의미에서 더 잘 확장됨. 인증, 데이터베이스 접근, 작업 큐, 메일러, 완전한 테스트 도구 등 기본 제공도 많고, 직접 JavaScript를 거의 안 써도 되며, 훌륭한 가상 머신인 BEAM도 있음
      적어도 이런 프로젝트들이 모두 “한 발 물러서자”는 싸움을 해줘서 좋음. 직장에서는 React와 Relay를 쓰는데, 프런트엔드 JavaScript를 오래 써왔고 어느 정도 한다고 생각해도 넘어야 할 장애물이 너무 많아 지침
    • Django와 비교해서, 적어도 지금은 둘을 동급으로 보지 않는다는 점이 흥미로움. Rails를 Django보다 선호하는 구체적인 이유가 있는지 궁금함
    • Rails를 좋아하지만, 내 나라에서는 거의 아무도 안 쓰고, 쓰는 회사들은 거의 마법사급 개발자를 찾음
      일자리를 못 구하니 경험도 충분히 못 쌓고, 결국 그런 마법사들에게 밀림. 그 채용 공고는 12개월 넘게 열려 있기도 함
      대신 수요가 있는 곳이라서 세상에 JavaScript를 더 뿌리고 있음
    • 내가 아는 Rails 개발자 상당수가 ember.js로 옮겼음. ember.js도 수많은 서드파티 플러그인이 계속 깨지는 방식이 아니라 관례 기반 프레임워크라서 그렇다
      구조적으로는 ember-data 접근이 마음에 듦. 데이터셋의 왼쪽 조인/오른쪽 조인 같은 작업에서 자동화할 수 있는 부분이 많고, 통합된 목 서버도 있음
      다만 너무 잘 동작해서 그런지 다른 것들만큼 멋져 보이지는 않는 듯함
      https://emberjs.com/

  • 13,000줄짜리 Rails 7.0 앱을 7.1로 올렸는데, 7.0과 7.1의 차이[0]를 제외하면 테스트 설정 코드 1줄만 바꾸고 전부 동작했음
    쉬운 업그레이드 경로라는 면에서는 성공이라고 봄. 이제 재미있는 부분은 7.1의 새 기능을 쓰도록 일부 코드를 리팩터링하는 일임
    관심 있다면 Rails / Docker 예제 앱도 7.1로 올려둠 https://github.com/nickjj/docker-rails-example
    Rails 7.1에 Dockerfile이 포함되긴 했지만, Docker Compose를 써서 개발과 프로덕션에서 바로 동작하는 경험을 만들고 Postgres, Redis, Action Cable, Sidekiq 등을 포함하는 식으로 여전히 더할 수 있는 선택지가 많음
    [0]: https://railsdiff.org/7.0.8/7.1.0

  • 꽤 큰 Rails 6 코드베이스에 React가 잔뜩 붙어 있는 상태에서, Hotwire를 쓰는 새로운 “비” JavaScript 방식으로 올리려는 중임. 행운을 빌어줘
    Rails는 기본값을 지킬 때는 훌륭하지만, 그 기본값을 벗어나는 순간 고통의 땅이 됨

    • 비교적 최근의 Rails 7 코드베이스에서 일하고 있음. 처음에는 Stimulus를 쓰기 시작했지만, 몇 가지 이유로 React 전환을 고려 중임
      프런트엔드 엔지니어를 채용하려면 React 후보군이 몇 자릿수 더 큼. 일반적인 작업에 쓸 바닐라 JavaScript 패키지를 찾아 Stimulus 컨트롤러로 감싸는 일도 React 패키지를 찾는 것보다 점점 어려워짐
      Stimulus는 컨트롤러 단위 테스트를 작성할 방법도 딱히 제공하지 않음. React에서는 평소처럼 jest와 react-test-renderer를 쓸 수 있음
      게다가 최근의 Turbo TypeScript 논란은 Hotwire 생태계의 장기 운영에 대한 신뢰를 주지 못했음
      아직 결정을 내리지는 않았음. Stimulus가 프런트엔드 코드를 쓰는 아주 Rails다운 방식처럼 느껴지는 건 분명 장점이고, 이미 Rails에 익숙한 소규모 팀에는 특히 그렇다
    • “Rails는 기본값을 지키면 좋고 벗어나면 고통스럽다”는 건 모든 프레임워크에 해당함
      애플리케이션이 꽤 단순하고 프레임워크의 방식과 잘 맞으면 프레임워크는 훌륭함. 더 복잡하고 유연한 구성이 필요하면 라이브러리를 봐야 함
    • Rails의 JavaScript 통합에 대한 믿음을 잃었음
      이제는 slim으로 서버 측 렌더링을 하거나, API 전용으로 만들고 프런트엔드를 분리함
      Rails는 JavaScript를 하려고 CoffeeScript, 에셋 사전 컴파일, webpack 등 방향을 너무 많이 바꿨음
    • 기존 React 프런트엔드를 Hotwire로 옮기는 일을 Rails 자체 업그레이드와 동시에 하라고 권하고 싶지는 않음. 먼저 독립적으로 Rails 7.1까지 올리는 게 좋다고 봄
      참고로 Rails 7+에서 단일 페이지 앱 JavaScript를 다루는 방식도 예전보다 훨씬 합리적임. 사실상 원하는 빌드 도구를 Rails 앱과 분리해서 쓰면 됨
      개발 중에는 rails s와 함께 yarn build --watch 같은 걸 같이 실행해야 하지만, 개인적으로는 나쁘지 않고 훨씬 단순해진다고 봄
      우리 회사는 Rails 업그레이드를 자동화하는 소프트웨어를 만들고, Rails 업그레이드를 대신 해주는 전체 서비스도 제공함. 관심 있으면 steve (at) infield.ai로 연락하거나 https://app.infield.ai/users/sign_up에서 무료 Rails 업그레이드 계획을 생성할 수 있음. 신용카드는 필요 없음
      자세한 내용은 https://docs.infield.ai/docs/creating-an-upgrade-path 참고
    • https://vite-ruby.netlify.app/guide/rails.html를 써보길 권함
      내 경우에는 거의 webpack 대체재처럼 바로 들어맞았음

  • Rails를 좋아하고 Rails 2 때부터 간헐적으로 써왔음
    아주 좋은 프레임워크이고, 가끔 웹사이트를 띄워야 하는 나 같은 사람에게는 정말 저항이 가장 적은 경로임
    다만 새 노트북에서 Rails를 돌리도록 세팅하는 과정이 괴로움. node가 필요하고, 그러면 npm도 필요함. 백엔드 개발자라서 node를 어떻게 세팅해야 하는지, 어떤 순서로 해야 하는지 잘 모름
    자주 하는 일이 아니라 매번 싸움처럼 느껴짐. 결국 해내긴 하지만 왜 마침내 전부 맞아떨어졌는지는 늘 확신이 없음
    필요한 것들을 한꺼번에 맞춰줘서 rails가 그냥 동작하게 해주는 설치 프로그램이 있으면 좋겠음. rvm 설치기는 ruby 위에 rails는 세팅해주지만, 그 밑의 node 시스템까지 세팅해주지는 않음

    • asdf라는 버전 관리자가 nodejs 관리에 좋음. Ruby는 다뤄본 적 없음
      https://asdf-vm.com/
    • “백엔드 개발자라서 node 세팅을 모르겠다”는 말은 이해함
      Node가 주로 프런트엔드 도구로 알려져 있고 Rails도 그 용도로 쓰지만, 기억하기로 Node는 적어도 처음에는 JavaScript 런타임을 백엔드로 가져오려고 만들어졌음
      패키지 관리자 없이도 Windows에서는 그냥 node.exe이고, npm을 내려받아 풀고 node와 npm을 PATH 환경 변수에 넣으면 되는 걸로 앎
    • Rails 7의 전체 전제가 바로 node 의존성 제거임
    • Rails를 해본 적이 없어서 궁금한데, “Ruby on Rails”가 왜 nodejs를 필요로 하는지 알고 싶음
      그리고 node 설치는 꽤 쉬움. 사실 너무 쉬움. 훨씬 더 어렵고 학위가 필요했으면 좋겠음
    • Ruby/Rails 커뮤니티는 내가 본 것 중 가장 좋고 친절한 편임. 하지만 그중 최악은 단연 JavaScript 혐오임
      JavaScript는 다른 것과 마찬가지로 도구일 뿐임. 좋든 싫든 매우 중요한 도구이고, 좋든 싫든 오랫동안 남아 있을 것임
      조금 열린 마음으로 최소한 기본은 배워보면 일이 더 쉬워질 것임

  • Rails + HTMX와, 아주 상호작용이 많은 페이지에만 약간의 JavaScript를 뿌리는 방식이 다시 부흥하길 바람
    Rails를 Slim/HAML과 함께 쓰는 건 정말 즐거움. 원하면 ViewComponents 같은 라이브러리로 부분 렌더링을 더 쉽게 할 수도 있음. 여기에 웹 컴포넌트를 더하면 꽤 상호작용적인 페이지를 만들 수 있고, 특정 페이지에서 정말 필요하면 React도 쓸 수 있음
    HATEOAS는 애플리케이션 복잡도를 크게 줄여줌. 그래도 API가 필요하다면 서로 다른 MIME 타입에 응답하는 것도 매우 쉽고, 원하면 같은 엔드포인트를 공유할 수도 있음
    경험상 React를 쓰는 애플리케이션 대부분은 사실 React가 전혀 필요 없음. 팝업 메뉴 몇 개 때문에 React를 씀
    그래서 React 없이, 혹은 아주 조금만 React를 쓰는 큰 앱들이 나오기 시작하면, 오늘날 우리 애플리케이션이 얼마나 불필요하게 복잡한지 깨닫는 사람이 생기길 바람
    그런데 이미 “다들 React를 쓰니까 React로 바꿔야 한다”는 얘기를 보고 있음. 한숨 나옴
    꿈은 꿀 수 있지

  • 공식 발표는 여기 있음: https://rubyonrails.org/2023/10/5/Rails-7-1-0-has-been-released
    상위 수준의 세부 내용이 조금 더 있고, 새 변화들 중 일부를 써볼 생각에 기대됨. 특히 새 비동기 쿼리 메서드는 빠른 성능 개선에 꽤 유용할 것 같음

  • 백엔드에서의 Rails는 받아야 할 평가를 충분히 못 받고 있음
    다만 프런트엔드 쪽은 아주 오랫동안 엉망이었음

    • “프런트엔드 쪽은 오랫동안 엉망이었다”는 데 반대하지 않지만, 프런트엔드 자체도 오랫동안 엉망이었음
      지금은 Rails 7.1 + Hotwired + Importmaps 조합으로 작업하기 즐거움
      하지만 브라우저에서 최소한 ES6와 Import Maps 지원이 좋아질 때까지 기다려야 했음
      이 글의 날짜를 보면 https://web.dev/import-maps-in-all-modern-browsers/ 2023년 3월 28일에 모든 현대 브라우저에서 importmaps를 쓸 수 있다고 발표했음
      그러니 지금까지는 Webpack, Yarn, 그 밖의 JavaScript 보조 도구를 피할 방법이 없었음
      이제는 importmaps가 있고 브라우저의 ES6 지원도 충분히 좋으므로 https://caniuse.com/?search=es6, 추가 도구가 거의 필요 없이 현대적인 JavaScript를 쓸 수 있음
    • 동의함. 여기서 선택지는 뭐가 있을까? API 전용 모드의 Rails인가?
    • 새 Hotwire 기능을 좋아함. 프런트엔드에서 뭐가 마음에 안 드는지 궁금함

  • 몇 주 전 친구가 “Rails 릴리스가 발표됐는데 네가 업그레이드 PR을 안 올렸다면, 정말 일어난 일인가?”라고 농담했음
    자, 이제 PR 올릴 차례임. 몇 달째 대기 중인 7.0 PR 뒤에 쌓아야 하더라도

  • 경험상 많은 팀이 ActiveRecord로 깔끔한 코드베이스를 만드는 데 어려움을 겪음

  • 때리지 말아줬으면 하는데, 아직 Rails 4.2를 쓰고 있고 만족함
    내가 직접 하거나 B2B 회사들을 위해 하는 JavaScript 없거나 적은 백엔드 SaaS 작업에 필요한 건 다 제공하고, 저사양 VPS에서도 돌아감
    답할 시간이 있다면, 왜 업그레이드해야 하는지 궁금함

    • 나도 예전 버전을 씀. 우선 최신 패치/마이너 버전까지는 올릴 수 있는지 확인해야 함
      오래된 버전의 핵심 문제는 연결된 gem의 취약점임. 예를 들어 nokogiri는 Rails 메이저 업그레이드 없이는 올릴 수 없을 수 있음
      다만 대부분의 앱은 예를 들어 복잡한 XML 파싱을 하지 않으니, 취약점 상당수는 해당되지 않음. 그래서 안전한지 확인하는 유지보수가 조금 필요함. 버그를 막기 위해 몽키 패치를 넣는 경우도 자주 있음
      업그레이드하면 보안이 좋아지고 유지보수 시간이 줄어듦. 하지만 끊임없는 업그레이드 비용도 고려해야 함. 또 다른 요인은 새 버전에서 더 빠른 Ruby 지원을 받을 수 있다는 점임
      보통 Rails 앱을 만들 때는 최신 릴리스를 쓰지만, 인기가 많거나 앱이 아주 오래돼서 새 시스템에서 뭔가 동작하지 않는 경우가 아니면 이후 Rails 버전은 올리지 않음
    • 보안 때문에 업그레이드해야 함
답변달기