레일즈를 사용하던 기업들이 주 언어를 바꾼 이유가 궁금합니다

안녕하세요! 질문 감사합니다. 백엔드 2년차 개발자로서 기술 스택에 대해 고민하고, 레일즈에 관심을 가지게 되신 점 정말 반갑고 멋지네요. :) 말씀하신대로 국내에서는 레일즈로 시작해서 스프링 기반으로 기술 스택을 변경한 사례가 많은데요, 구체적인 이유는 회사마다 다를 수 있겠지만, 경험적으로 봤을 때는 우리나라 특성에 따른 개발자 채용이 어려운 점이 가장 크다고 생각해요. 물론 요즘에는 자바라고 해서 채용이 쉽다고 보긴 어렵지만 국내에서 사실상 표준처럼 여겨지는 Java 생태계가 더 유리했을 것 같아요. 성능적인 부분은 다른 해외 사례에서 충분히 입증을 해주고 있다고 생각하고, 당근마켓도 주요 서비스가 아직 레일즈 기반으로 되어있기 때문에 충분한 근거가 될 수 있을거에요. 마지막으로 당근마켓을 새로 다시 만들었다는 이야기는 마이크로서비스로 나눈 기능에 대한 이야기라면 이해가 되는데 코드가 엉망이라서라기보단 설계적 관점에서 진행된거라고 생각해요. 어떤 분이 말씀하신건진 모르겠지만 저보다 내부 사정을 잘 아는 사람은 없을 것 같네요 😅 생각하신대로 언어보다는 어떤 경험을 하느냐가 제일 중요한 것 같아요. 프레임워크는 도구일뿐이니 어떤 경험을 할 수 있는지를 판단 기준으로 삼으시면 성장하는데 큰 도움이 되실거에요. 좋은 질문 감사합니다.

안녕하세요 강사님 질문이 있어 글을 작성합니다.

안녕하세요, 질문 감사드려요! 아래와 같이 답변드릴게요.1. 서비스 계층과 레포지토리 계층 Rails에서는 Active Record 패턴을 사용해서 데이터 액세스를 직접 모델에서 처리하는 경우가 많아요. 그래서 전통적인 의미의 '레포지토리 계층'을 따로 두지는 않아요. 하지만 비즈니스 로직이 복잡해질 경우, Service Object나 Query Object 같은 패턴을 사용해서 서비스 계층을 나누기도 해요.2. 마이그레이션 파일 관리 마이그레이션 파일이 많아져도 성능에는 영향을 주지 않지만, 관리가 어려울 수 있어요. 이럴 때는 schema.rb 또는 structure.sql을 기준으로 기존 마이그레이션 파일을 정리하고, 새로운 베이스 마이그레이션을 생성하는 방법을 사용하기도 해요.3. DTO 객체 변환 여부 Rails에서는 보통 DTO 객체를 따로 만들지 않고, Active Record 모델을 그대로 JSON으로 변환해서 API 응답으로 보내는 경우가 많아요. 하지만 ActiveModel::Serializer나 json_builder 같은 도구를 활용하면 Spring에서 DTO를 사용하는 것처럼 특정 필드만 선택해서 변환할 수도 있어요.4. 요청 경로 관리 네, Rails에서는 routes.rb에서 모든 요청 경로를 정의하는 게 일반적이에요. 각 컨트롤러에서 개별적으로 경로를 관리하지 않고, RESTful 구조에 맞춰 resources 메서드를 사용해서 자동으로 경로를 생성하는 방식이 보편적이에요.질문해 주셔서 감사합니다!

강의 감사합니다.

안녕하세요, 개인적으로는 설정할 것들이 적은 standardrb를 추천드려요. 저도 개인 프로젝트에서는 standardrb를 사용하고 있기도 해요. 하지만 그것도 결국은 rubocop을 활용한 것이라서 하나씩 설정을 잡아가는 걸 선호하신다면 rubocop을 써보셔도 좋을 것 같네요!

kamal로 배포해보기 챕터는 아직 업데이트 전인가요?

안녕하세요, 현재 준비 중인 강의 항목인데, 영상과 내용이 없는 상태에서도 노출되고 있었네요. 기대하셨을 텐데 불편을 드려 죄송합니다. 이달 안으로 강의를 업로드할 예정이며, 준비되는 대로 안내 드리겠습니다. 조금만 기다려 주시면 좋은 내용으로 찾아뵙겠습니다! 감사합니다.

tailwindcss code generator 링크가 잘못된 것 같아요.

안녕하세요!https://chatgpt.com/g/g-hrRKy1YYK-tailwind-css-builder-windchat제작자 홈페이지에서 링크복사했었는데 랜딩 확인을 안했었네요ㅠ강의노트도 수정해둘게요!제보 감사합니다.

show api 작성시 생성된 @article을 instance 변수로 만드는 이유가 있나요??

안녕하세요, zbqmgldjfh님.단순한 API만 제공하는 Controller였다면 instance 변수로 선언하지 않아도 되는게 맞아요.가이드의 경우에는 View까지 그려줘야 하는데 View가 결국은 Controller를 통해서 그려지기 때문에 View 내부에서 article의 데이터에 접근이 필요한 경우에 위와 같이 선언해서 가져다 쓰는 용도로 쓰이고 있어요.그러지 않고 사용한다고 하면 View에서 API콜을 따로 해서 필요한 값을 받아가는 방식이 있을텐데 이 방식이 Ruby on Rails에서는 일반적인 사용패턴이라고 알고 있어요. 언급하신 다른 메소드가 참조하는 좋지 못한 방식이라는 점이 Rails에서는 before action으로 미리 객체의 값을 넣어두고 메소드에서는 참조만 하게 해서 동일 코드를 제거하는 효과를 가지기도 해요.before_action :set_article def set_article @article = Article.find_by(id: 123) end def foo "Title is #{@article.title}" end def bar "Description is #{@article.description}" end