<aside> 💡 인삿말
안녕하세요
저희가 회의 단계에서 너무 궁금했던 부분들이 있어서 질문 남기게 되었습니다!!
별도로 주황색 으로 체크업 해두었는데 해당 부분이 너무 궁금합니다!
</aside>
레시피 상세 보기 페이지 에서는 레시피 상세 정보 와 댓글 리스트 를 유저들에게 보여주게 됩니다. 해당 페이지에서 서버에 정볼르 요청 할 때, 다음의 선택지 중에 어떤 것이 RESTful API 에 맞는 방식일까요?
GET /api/recipes/:recipeId 에서 두 가지를 한 번에 제공하는 것
<aside> 🗒️ REST 가이드라인에 맞추려는 노력은 좋지만, 프로젝트 상황에 맞게 보다 더 편리한 방법으로 결정해 주면 좋을 것 같습니다.
</aside>
GET /api/recipes/:recipeId 과 GET /api/comments 에서 별도로 제공하는 것
<aside>
🗒️ 설계하는 분의 선택이 크긴 하나 보통은 API 엔드포인트에서 요청하는 리소스를 가져오는 것이 일반적입니다. 예를 들어 GET /api/recipes에서는 레시피에 대한 리소스를 가져오는 것. (상황에 따라 레시피와 관련된 데이터를 가져오긴 합니다.)
</aside>
취업 시장에서의 Redux 에 대해서 어떻게 생각하시나요? 해당 기술이 시장에서 플러스 요소가 될 수 있을까요?
<aside> 🗒️ 일반적으로 우리가 만드는 웹 애플리케이션에서 복잡한 상태 관리를 위해서 Redux 등과 같은 것을 필수로 사용하는 경우는 많지 않습니다. 다만, 프론트엔드의 규모가 커지면서 전역으로 상태를 관리해야 될 필요성이 생기면서 상태 관리 라이브러리를 도입을 결정하게 됩니다. 그렇다보니 취업시장에서는 리덕스 경험이 있다면 우대하는 것은 맞으나 우리는 성공적인 프로젝트 수행이 목표이기 때문에 사용하지 않는 것을 추천드립니다.
</aside>
Redux 에 유저 토큰 만 사용하는 것 괜찮을까요?
<aside> 🗒️ 위와 비슷하게 리덕스에 유저 토큰 만을 사용하면 굳이 리덕스를 사용할 필요가 없습니다. 리덕스에 유저 토큰만 사용한 것이 취업에 플러스가 되지도 않고요. "프론트엔드에서 어떤 문제를 해결하기 위해서 리덕스를 사용했다"이것이 설명이 되어야 합니다. "왜 리덕스를 사용했지"라는 질문에 답을 할 수 있다면 취업에 정말 많이 도움이 될 겁니다.
</aside>
실전 프로젝트에 프론트엔드 쪽에서 기술 챌린지를 다음과 같이 고민하고 있습니다.
우리 프로젝트의 API 에는 어떤 방식이 적합할까요?
- 그리고, 반응형 웹 사이트를 구현한 후에 PWA 를 적용할 수도 있다고 이해했는데 개념 이해가 맞을까요?
<aside> 🗒️ 사용자 관점에서 모바일 환경에서 보이는 것이 좋다면 PWA를 선택해도 좋을 듯 합니다. 다만, PWA를 사용한다고 하여서 꼭 반응형으로 구성해야 하는 것은 아닙니다. 오히려 PWA를 사용하면 모바일 페이지만 구현을 해도 되겠지요.
</aside>
위 내용들을 중요하게 생각하고 작업을 하려고 하는데, 어떤 식으로 진행하는 것이 가장 효율적 일까요?
<aside> 🗒️ 코드 컨벤션 같은 경우는 eslint를 쓰면 바로 해결됩니다. 성능 최적화를 포함한 에러 처리 같은 경우는 팀 내부적으로 규칙을 정해서 구현을 해주시면 됩니다. 이것과 같은 경우는 혹시 필요하면 멘토링 시간에 더 말해 드릴게요.
</aside>
다음과 같은 lib 을 사용하려고 하는데, 어떻게 생각하시나요?
현재 고려 : 빌더 vite, 폼 react hook form, 얼럿 swwetalert2 추후 고려 : 무한 스크롤 Intersection Observer, 슬라이드 React-Slick
<aside> 🗒️ 선택하신 기술들은 좋습니다. 다만, 선택한 이유를 명확하게 설명 가능하도록 정리를 해두시면 좋을 듯 합니다.
</aside>
브라우저 개발자 도구에서 lighthouse 를 사용해서 성능 개선 을 하고 싶은데, 어떤 점을 고려해야 할까요?
그리고 해당 기술의 도입 시기를 개발 단계부터 고려 하면서 진행 해야 할까요?
<aside> 🗒️ 성능 최적화 경험이 없는 상태에서 개발 단계부터 최적화하려고 하면 고려해야 하는 것들이 많습니다. 그 때문에 개발도 늦춰 질 것이고요. 우선 개발을 마무리해 두고 시간이 남으면 Lighthouse를 통해 분석을 해 보는 것을 추천드립니다. 그 과정은 제가 도와 드릴 수 있도록 할게요.
</aside>
트러블 슈팅을 꼼꼼히 하고자 하는데, 해당 부분은 GitHub Issue 로 진행해도 깔끔할까요?
<aside> 🗒️ 깃허브 이슈도 좋습니다.
</aside>
ORM 을 쓰는 것과 안쓰는 것의 의사 결정 차이에서 저희의 생각을 정리해보았습니다. 해당 부분에서 피드백을 받을 수 있을까요?
- ORM 을 쓴다면, Sequelize 가 아니라 TypeORM 이나 Prisma 를 써보려고 하는데 Node 현업 시장 에서 거의 쓰고 있는 걸로 아는데 맞는지. 맞다면 저희가 시장 조사를 해보니 Sequelize, TypeORM, Prisma 들이 많이 나오는데 TypeScript 기반으로 개발을 한다면 어떤 친구를 고르는 것을 추천하시는 지 하고 그 이유 가 궁금하다.
- ORM 을 안쓴다면, pg, mysql2 를 이용해서 테이블을 직접 만들고 쿼리문을 작성하고 SQL Injection 처리를 직접 해보는 것이 메리트가 있을까? 아니면, 서비스의 특성을 봤을 때 굳이 쿼리문을 직접 작성하는 것은 어떤 시선으로 보여질 것 같은지.1. Prisma 보다는 TypeORM 사용을 추천드립니다. 하지만, Sequelize에 대한 경험이 많지 않다면 Sequelize 부터 사용해 보세요. 이런 과정을 거쳐야 TypoeORM의 장단점 혹은 왜 써야 하는지를 조금 더 구체적으로 이해할 수 있을 거에요.
<aside> 💡 Prisma 보다는 TypeORM 사용을 추천드립니다. 하지만, Sequelize에 대한 경험이 많지 않다면 Sequelize 부터 사용해 보세요. 이런 과정을 거쳐야 TypoeORM의 장단점 혹은 왜 써야 하는지를 조금 더 구체적으로 이해할 수 있을 거에요.
Sequelize를 사용해도 세세한 쿼리가 필요할 경우 Raw Query를 사용하기도 합니다. SQL Injection 방지 경험을 해보는 것 좋다고 생각이 들긴 하지만모두 Raw Query로 처리할 경우 개발 기간이 오래 걸릴 것으로 예상됩니다. 그렇기 때문에 생산성을 위해서는 Sequelize를 사용해 주세요.
</aside>
MySQL 테입르을 쪼개기 전과 쪼개기 후를 비교해서 성능 비교를 하고 싶은데, 해당 툴 이 존재할까요? 어떤 방식으로 이를 측정할 수 있을까요?
<aside> 💡 성능 측정은 직접 쿼리를 해 보고 속도를 측정하거나 API 반응 속도로 측정 가능할 것 같습니다.
</aside>
EC2 인스턴스를 만들고 SSH 로 접속할 때, *.pem 키를 쓰는 데 이걸 서로 어떻게 공유 해야할 지 모르겠습니다? 저희가 사용하고 있는 전송 수단은 이메일 하고 카톡 밖에 없는데 이런 친구를 사용하는 것밖에 없을까요?