다음 단계는 데이터를 표시하는 것입니다. 그래서 lib pewter.action.ts 안에서 현재 가지고 있는 함수들 중 일부를 접을 수 있습니다.

프로젝트를 생성하고, KV 스토리지에 저장된 프로젝트 목록을 워커 라우트를 통해 보여줄 수 있는 'get projects'라는 다른 프로젝트를 만들고 싶습니다.

그걸 저희가 내보내서 새로운 함수인 `get projects`를 만들 수 있습니다. 그 함수는 비동기 함수로 정의될 것입니다.

그리고 블록을 열어서, pewter 워커 URL이 없는지 확인해 보겠습니다. 그리고 이것은 상수에서 가져오는 것입니다.

기본적으로는 환경 변수를 불러오는 과정인데, 지난 강의에서 바로 여기 추가했던 내용입니다.

이것을 저희의 백엔드라고 생각하실 수 있습니다. 존재하지 않는다면, console.warn을 출력하고 진행하겠습니다.

누락된 비트 페테르 워커 URL을 건너뛰고 히스토리를 가져오라고 말합니다. 그래서 세부 정보를 가져올 수 없게 되고 빈 배열을 반환하게 될 겁니다.

하지만 만약 그것을 가지고 있다면, try-catch 블록을 열게 될 것입니다.

알다시피 저희는 그렇게 진행하는 것을 선호합니다. 에러를 잡을 때, 콘솔에 에러를 출력하거나, 서명에 필요한 프로젝트를 가져오지 못했다는 메시지를 표시하거나, 아니면 그냥 프로젝트를 가져오지 못했다는 메시지를 다시 보여드릴 수 있습니다.

빈 배열을 반환합니다. 하지만 여기서는 저희가 생성한 모든 프로젝트를 가져오려고 시도해 볼 수 있습니다.

그것은 `const response`를 `await pewter.workers.exec`과 같이 실행(execute)하도록 설정함으로써 할 수 있습니다.

그리고 저희는 피우터 워커 내에서 다음과 같은 함수를 실행하고 싶습니다. 피우터 워커 URL은 /api/projects/list로 기억하실 겁니다.

여기 Roomify 워커 내에서 바로 그 기능을 수행하는 함수가 하나 있습니다. API를 통해 프로젝트 목록을 가져오는, 즉 `api get api projects list`라는 함수인데, 이 함수는 모든 프로젝트를 반환합니다. 저희는 간단히 이 함수를 호출합니다.

우리의 백엔드에서 get 메서드를 사용합니다. 그리고 이 요청을 하면 응답으로 데이터를 받게 될 거예요. 응답 상태가 괜찮은지 빠르게 확인해 볼 수 있습니다.

답변이 적절하지 않다면, 콘솔에 오류를 표시하고 프로젝트 저장은 실패하더라도 이력 정보는 가져올 수 있습니다.

이후에 'await response dot text'와 같이 표시하여 추가 정보를 보여드릴 수 있습니다. 배열을 비워 반환하면 됩니다.

네, 하지만 응답을 성공적으로 받아온다면 데이터를 추출할 수 있을 겁니다.

응답을 기다리는 동안 파일이 `await response.json`과 같아질 것이며, 데이터 유형은 프로젝트 질문부호, 즉 선택적 요소로 정의할 수 있습니다. 이는 다양한 디자인 항목들의 목록이 될 것입니다.

저희 애플리케이션 내에서 진행하는 프로젝트를 지칭하는 용어라고 할 수 있습니다. 각 디자인 항목은 ID, 이름, 소스 이미지 및 경로, 렌더링된 이미지 및 경로와 같은 모든 세부 정보를 포함하고 있으며, 마지막으로 저희는...

배열 점은 데이터 질문 배열 점입니다. 프로젝트가 있다면 배열인 경우 해당 프로젝트 배열을 반환하고, 그렇지 않으면 빈 배열을 반환합니다. 이제 두 가지 다른 경로를 정의했으므로.

여기 이 워커 파일 내에서 프로젝트 목록을 가져오고, ID로 프로젝트를 가져오는 액션들을 모두 작성해야 합니다. 공유는 더 이상 하지 않기 때문입니다.

이전과 마찬가지로 홈 파일에서 위치 정보를 활용하는 대신, 사용자에게 바로 시각화 페이지로 연결해 드리겠습니다. URL에서 ID를 가져와 해당 프로젝트 정보를 불러오는 방식으로 진행하겠습니다.

더 정확한 데이터를 보여주기 위해, 그리고 주의 깊게 지켜보셨다면 아시겠지만, 코드 래빗께서 이전부터 그렇게 해야 한다고 말씀해주셨습니다. 자, 우선 다시 한번 그쪽으로 이동해 보겠습니다.

경로(routes) 홈으로 이동하여 저희 홈페이지에 접속하실 수 있습니다. 그리고 새로운 '프로젝트 가져오기(get projects)' 기능을 사용하여 결과를 프로젝트 목록 바로 아래 상단에 표시해 보겠습니다. 새로운 레퍼런스 변수 '생성 중(is creating)'을 만들겠습니다.

프로젝트 레퍼런스를 사용하고, 시작 시 레퍼런스를 false로 설정한 다음, 업로드 핸들러 아래에 위치해야 합니다.

먼저 점검을 해서 프로젝트 참조가 현재 생성 중인지 확인할 수 있습니다. 그렇다면 false를 반환합니다. 왜냐하면 현재 프로젝트를 생성하고 있기 때문입니다. 그렇지 않다면, 간단히 설정하면 됩니다.

진실로 확인한 후에 업로드를 진행할 수 있습니다. 이 모든 과정을 try 블록으로 감싸서, 여기 있는 전체 코드, 즉 return true를 포함한 모든 코드를 try 블록 안에 넣을 수 있도록 하겠습니다.

마지막으로, finally 블록을 뒤에 추가할 수도 있습니다. 이 finally 블록은 단순히 isCreatingProjectRef.current를 false로 설정하는 역할을 할 뿐입니다. 이제 애플리케이션으로 다시 돌아가서, 특히…

홈페이지에 방문하셨을 때, 당장 프로젝트를 보지 못하실 수도 있습니다. 괜찮습니다. 프로젝트를 키-값 저장소에 저장하기 위해 워커를 호출해야 하기 때문입니다.

그것을 하는 것은 간단할 거예요. 저희는 lib pewter actions으로 가서, 프로젝트 생성 밑에 있는데, 바로 여기 있습니다. 먼저 pewter worker URL에 접근할 수 있는지 확인해야 합니다.

저희는 그 주석 세공업체 URL을 찾아볼 수 있을 것 같습니다.

네, 좋습니다. 여기 이 if 문은 존재 여부를 확인하기 위해 필요한데, create if no pewter worker url 안에 바로 위치해야 합니다.

콘솔 경고 메시지가 표시되고 null 값이 반환됩니다. 그런 다음, 여기 이 try 블록 시작 부분에서 pewter 작업자를 호출하여 프로젝트를 kv에 저장합니다. 여기에서 확인할 수 있으며, 저희도 메모를 남겨두었습니다.

우리가 해야 할 일은 백엔드 URL에서 다른 액션을 호출하는 것입니다. 기억하시겠지만, 여기에서 pewter.workers.exec를 호출했었죠. 여기에서도 비슷한 작업을 수행할 겁니다.

이것을 복사해서 여기 붙여넣을게요. response는 wait pewter workers exec입니다. 이번에는 프로젝트의 저장 함수를 호출할 건데요, 이건 post 메소드를 가지고 있어요.

방법과 더불어 헤더와 같은 추가 정보도 함께 전달해야 하는데, 이 헤더는 콘텐츠 타입이 애플리케이션 JSON 형식이 될 것입니다.

헤더 옆에, 본문도 전달해야 합니다. 본문은 JSON 문자열로 변환된 객체로, 프로젝트 정보와 공개 여부를 포함하게 됩니다. 프로젝트는 페이로드(payload) 유형이고, 공개 여부도 함께 전달해야 할 것입니다.

아마 공개로 설정될 걸로 생각되어서, 여기다가 적어두고 이 가시성이 어디서 오는지 확인해 보려고 합니다. 분명 얻을 수 있을 거라고 생각합니다.

여기서 두 번째 매개변수로 create project 함수에 visibility를 전달합니다. 기본적으로 private로 설정될 것입니다. 자, 이제 백엔드를 호출하는 create project가 생성되었습니다.

또는 워커를 호출할 수 있습니다. 바로 아래에서 응답이 괜찮은지 확인할 수 있어요. 콘솔 에러를 출력해서 프로젝트 저장에 실패했다는 메시지를 표시할 수도 있습니다.

그리고 응답 파일인 response.txt를 await로 추가하여 왜 그런지 알 수 있습니다. 마지막으로 null을 반환할 수 있습니다.

만약 제대로 저장했다면, `response.json()`을 통해 데이터를 추출할 수 있습니다. 그 결과는 객체 형태로 반환될 것이며, 데이터는 `await response.json()`과 같이 표현될 것입니다.

프로젝트가 설계 항목이 될지, 아니면 설계 항목 배열이 될지, 혹은 아무것도 아닐지에 따라 결정될 것입니다. 저희는 설계 항목 배열만 필요합니다.

하나의 프로젝트를 제대로 진행하기 위해, 우리가 저장해둔 프로젝트를 말이죠. 이제는 페이로드를 반환하는 대신, 데이터 질문표 또는 프로젝트를 반환할 겁니다. 만약 그것이 존재하지 않는다면, 간단히...

시도하기 전에 null을 반환하도록 하겠습니다. 먼저 비주얼라이저 페이지에서 프로젝트 생성 함수를 호출하는 방식과 동일하게, 사용자가 처음 업로드할 때 프로젝트 생성 함수를 호출합니다.

입력 이미지를 해당 방식으로 처리하고, 그 이미지가 KV에 저장됩니다. 그런 다음 시각화 페이지로 리디렉션되면 AI 이미지가 생성되고, 다시 프로젝트 생성을 호출합니다.

이제 AI가 생성한 이미지, 소유자 등 정보를 저장해야 합니다. 따라서, 이 pewter actions 파일 내에서 getProjectById 액션을 만들어 보겠습니다.

바로 여기, getProjects가 있고, 이제 getProjectById를 개발할 수 있습니다.

이 코드는 영상 키트 링크 설명란에 제공해 드릴게요. 이미 개발한 것들과 매우 유사하기 때문입니다.

똑같은 방식으로 시작합니다. ID를 전달합니다. 그리고 피워터 워커 URL이 누락되었는지 확인합니다.

그렇지 않다면, 저희 워커 내에서 다른 엔드포인트를 호출하여 ID를 전달하고, 해당 프로젝트의 상세 정보를 가져올 수 있습니다.

몇 가지 오류 처리를 진행한 후, 해당 프로젝트의 데이터를 추출하여 반환합니다. 이것이 전부입니다.

자, 이제 드디어 이 모든 것들을 사용할 수 있습니다. 이걸 백엔드 또는 워커 액션이라고 부르죠. 프론트엔드에서 활용할 수 있습니다.

이제 라우트 시각화 도구로 이동해서 프로젝트 생성 함수를 호출하거나, 기본적으로 프로젝트를 업데이트할 수 있습니다.

여기 보시면 저희도 노드를 남겨두었는데, 이 노드를 활용하려면 몇 가지 상태와 매개변수를 더 만들어 상황을 추적할 수 있어야 합니다.

먼저, 리액트 라우터에서 제공하는 파라미터 사용 기능을 활용하여 현재 검토 중인 프로젝트의 ID를 추출할 수 있습니다.

그리고 사용자 ID도 받아와야 하는데, useOutletContext에서 가져온 데이터를 구조 분해 방식으로 얻을 수 있습니다.

그리고 그것은 이와 같은 인증 컨텍스트 유형이 될 것입니다.

그럼 새로운 상태를 만들 수 있습니다. 저는 use state 스니펫을 사용해 보겠습니다.

그리고 그것은 프로젝트로 불릴 것이며, 초기에는 null로 설정될 프로젝트를 의미합니다. 그리고 그 타입은 디자인 항목이거나 초기에는 null로 설정될 것입니다, 왜냐하면 처음에 null이기 때문입니다.

그리고 마지막으로, 프로젝트 로딩을 위한 부분을 처리할 예정입니다. 상태 스니펫은 '프로젝트 로딩'으로 설정하고, 이제 진행하겠습니다.

True로 설정하겠습니다. 그리고 현재 이미지에서는 초기 렌더링으로부터 업데이트를 더 하지 않을 예정입니다. 백엔드에서 오는 데이터를 사용하기 때문입니다.

그래서 이 위치 상태를 사용할 필요조차 없을 거라고 생각해요. 그래서 제거하고 위치 정보를 제거할 수 있을 거예요. 백엔드에서 모든 데이터를 직접 가져올 테니까요. 이제 여기, 이 런 생성 안에서, 이것이 더 이상 필요하지 않아요.

홈페이지에서 전달받는 초기 이미지 대신, 디자인 항목의 특정 유형을 파라미터를 통해 이 함수로 직접 받고 있습니다.

그 다음에는 ID가 누락되었는지, 아니면 아이템에서 직접 가져온 원본 이미지가 없는지 확인합니다. 만약 그렇다면 다시 돌아가서 3D 뷰를 다시 생성하지만, 이번에는 업데이트하도록 하겠습니다.

아이템 점 소스 이미지 내에서, 그리고 이 아이템은 저희가 이 함수를 호출할 때 전달하게 될 아이템이 됩니다. 자, 이제 업데이트된 아이템은 어떻게 보일까요? 저희는 업데이트할 수 있습니다.

여기에 해당 텍스트를 입력하세요. 업데이트된 항목은 처음에 초기 항목 데이터를 펼친 후 렌더링된 이미지를 추가한 객체와 동일합니다.

그것은 결과로 렌더링된 이미지로 보여질 것입니다. 또한 결과 렌더링 경로로 설정될 렌더링 경로도 필요합니다.

업데이트 시간을 기록하는 타임스탬프도 추가될 예정이며, 이는 date.now로 설정될 것입니다. 또한, 소유자 ID도 필요합니다.

item.ownerID 또는 userID, 또는 이 둘이 없다면 null로 설정해 주세요.

마지막으로, isPublic 상태는 item.isPublic 또는 존재하지 않는다면 false로 설정됩니다.

그러면 이 업데이트된 항목을 확보한 후, '저장' 액션을 'await create project'로 호출할 수 있을 겁니다. 그리고 최종적으로 이 항목으로 연결하면 됩니다.

아이템을 포함하는 객체를 전달할 수 있는데, 이 객체는 이제 렌더링된 이미지와 경로를 포함하며, 이 경우 가시성을 비공개로 설정한 업데이트될 아이템이 됩니다.

마침내 해당 항목을 성공적으로 저장했다면, '프로젝트 저장됨' 상태로 설정하고 현재 이미지를 렌더링된 이미지로 업데이트할 수 있습니다.

그렇게 저장되었습니다. 렌더링된 이미지 또는 결과 렌더링 이미지를 사용했습니다.

우리는 또한 use effect를 조금 사용해서 모든 것이 제대로 업데이트되도록 해야 할 거예요.

그래서 이것은 삭제할 거예요. 그리고 비디오 킷 링크, 설명란에 두 개의 추가적인 use effect를 제공할 테니, 그걸 추가할 거예요.

프로젝트가 제대로 표시되도록 보장할 거예요. 첫 번째는 컴포넌트가 마운트되었는지 확인하기 위한 변수를 추가하는 거예요.

그 안에는 로드 프로젝트가 있는데, 존재하지 않을 경우 시작 시 로딩 상태를 false로 설정합니다.

하지만 그렇다면, 프로젝트를 불러오기 시작하고, ID로 현재 프로젝트를 가져옵니다.

이것이 우리가 만들었던 함수예요. 꼭 불러오시는 것을 잊지 마세요.

그리고 그걸 상태에 설정하고, 현재 이미지와 로딩 상태를 false로 설정해요.

그리고 그냥 호출하고 언마운트합니다. 두 번째 유즈 이펙트는 뭔가 잘못되는지 확인하고 있어요.

프로젝트가 로딩 중이거나 프로젝트에 소스 이미지가 없다면 그냥 반환해요. 하지만 모든 것이 괜찮고 렌더링된 이미지가 있다면 렌더링된 이미지로 업데이트를 하는 거에요.

대략 이것으로 끝입니다. 이제 다시 JSX 안에서, '제목 없는 프로젝트'라고 말하는 대신 실제로 렌더링할 수 있게 되었습니다.

프로젝트 질문 부호 이름, 혹은 저희가 이름을 가지고 있지 않다면 거주지라고 말씀드리고 해당 프로젝트의 ID를 렌더링할 수 있습니다. 일단은 생성자를 고객님께서 지정하도록 해두겠습니다. 현재로서는 모든 프로젝트가 그쪽에서 생성하고 있습니다.

이것들은 개인 정보이며, 여기 이 렌더러 플레이스홀더는 실제 프로젝트의 소스 이미지에서 가져오는 것입니다. 또한 소스 이미지를 여기 아래에 전달할 수도 있습니다.

이미지의 출처가 좋네요, 이제 이 전체 애플리케이션을 테스트해 볼 준비가 되었습니다. 새 프로젝트를 생성하여 그렇게 할 수 있습니다. 여기로 이동하면 완전히 비어 있거든요. 그럼 바닥면을 업로드해 보겠습니다.

계획을 보시면 제가 이전에 사용했던, 거의 비어있는 것을 사용할 예정입니다. 업로드 후 체크 표시가 뜨고 리디렉션되어야 하는데, 검사 기능을 확인해보시면 알 수 있습니다.

요소를 확인하신 후 콘솔로 이동하시면 '프로젝트 생성에 실패했습니다'라는 메시지가 표시될 것입니다. 코드베이스에서 '프로젝트 생성에 실패했습니다'를 검색해 보시면 홈 파일의 39번째 줄에서 발생하거나 적어도 그 근처에서 발생합니다.

그건 제 건이고, 프로젝트 생성 서버 액션을 호출해 보려고 할 때 발생하는 오류입니다. 이 오류는 저희 pewter 워커 파일에서 생성하려고 할 때 발생하는 것 같습니다.

하지만 Jun이를 이용해서 정확히 어디서 발생하는지 알아봐야겠네요.

이 오류 메시지 전체를 복사해서 주니에 붙여넣고, 제가 뭘 잘못했고 이 오류가 어디서 발생했는지 파악해 주실 수 있을까요?

그렇게 간단합니다. 이제 주석 작업 파일, 주석 처리 작업 파일의 구조를 가져오고, JSON 입력의 예기치 않은 종료가 발생할 것입니다.

잠깐만요, 이미 뭔가 하고 있네요. 바로 여기 코드가 수정되었어요. 잘못된 헤더를 제거하고, 포스트 요청 바디를 제대로 형식화해서요.

흥미롭네요. 설명을 기다려 보도록 하겠습니다. 때로는 이 차이점을 보면 변화를 알아차리기 어려울 때가 있습니다.

그리고 다른 파일들의 구조도 확인하여 오류가 다른 곳에 있는지, 아니면 저희 코드의 실수로 인한 고립된 사례인지 살펴봐야 할 것 같습니다.

그리고 업데이트 소식이 있습니다. 프로젝트 저장 로직에서 두 가지 주요 문제로 인해 문제가 발생했습니다. API 호출 구조가 잘못되었고, pewter 워커로 요청을 보낼 때 요청 본문이 헤더 안에 잘못 중첩되었습니다.

세상에, 진짜 그렇게 됐어요? 본문이 헤더 안에 이렇게 들어와 있는 거군요. 아, 맞네요. 객체가 여기 시작해서 여기 끝나는 걸 볼 수 있는데, 지금은 밖으로 꺼내 놓았네요.

알겠습니다. 작동하는군요. 그리고 또 다른 문제는 주석 세공인(pewter worker) 부분인데, 여기에서 프로젝트 ID가 존재하지 않지만 소스 ID는 존재하는 경우에 대한 느낌표를 제가 빠뜨린 것 같습니다.

그것은 저희가 원하시는 바가 아닙니다. 프로젝트 ID와 원본 이미지는 모두 필수 입력 항목입니다.

이 변경사항들은 정말 좋네요. 그리고 Junie 덕분에 잘 알아차렸어요. 이 부분이 worker 파일 안에 있었기 때문에, pewter 안에서 업데이트해야 해요. 수정된 projects.save 파일을 복사하세요.

이 코드는 워커 안에 바로 위치할 거예요. workers.save 파일을 복사하거나, 변경 사항이 그거 하나뿐이어서 전체 파일을 복사해서 페테르로 돌아가서 현재 코드를 덮어쓰고 저장하면 돼요.

오른쪽 클릭하시면 성공적으로 배포되었음을 확인할 수 있습니다. 저장하자마자 자동으로 배포되었기 때문에 다른 작업은 필요 없습니다. 즉, 이제 저희는 이 기능을 사용할 수 있어야 합니다.

프로젝트를 다시 생성해 보겠습니다. 제가 다시 동일한 보기 흉한 2D 층도면을 업로드할 예정입니다.

업로드를 진행했는데 리디렉션되었습니다. 확인해 보니 3D 시각화를 공식적으로 렌더링하고 생성하고 있는 것을 알 수 있습니다. 뭔가 진행 중인 것 같고, 드디어 얻었습니다. 제가 생각하기로는 처음인 것 같습니다.

이제 이 파일을 룸리피 내에서 새로운 프로젝트로 저장했습니다. 따라서 편집기를 나가서 홈 페이지를 다시 불러왔을 때, 여기에서 확인할 수 있을 거예요. 왜 그런지 코드를 한번 살펴봅시다.

홈으로 이동하면 초기에는 프로젝트가 비어 있는 배열로 설정되어 있다는 것을 알 수 있습니다. 하지만 업로드를 처리하면 시각화 화면으로 이동합니다.

하지만 실제로는 프로젝트를 업데이트하는 곳은 어디에도 없습니다.

그 부분은 그냥 없었던 거죠. 새로운 유효 효과를 추가해서, 단 하나의 함수인 'get projects'를 포함시킬 수 있습니다. 비동기 함수가 될 것이고, 오직 하나의 역할만 수행할 것입니다.

await getProjects를 호출해서 아이템을 가져오는 거고요. 다행히 이미 그 함수를 만들어 놓았으니, 그냥 state setProjectsItems로 설정하면 될 거예요.

그리고 여기에서 getProjects 함수를 호출할 수도 있습니다. 그리고 타입에 대해 불평한다면, 여기서 느낌표를 추가해도 괜찮습니다. 왜냐하면 프로젝트를 돌려받을 것이기 때문입니다.

또한 이 함수가 getProjects로 불리는 점을 감안하면, 이 임시 함수를 fetchProjects로 이름을 짓는 것이 더 적절해 보입니다.

이렇게 하면 충돌이 없을 거예요. 그리고 이 프로젝트는 저희의 활동에서 비롯된 프로젝트를 가져와야 합니다.

만약 올바른 import라면, 더 이상 느낌표를 사용할 필요가 없어요. 정확히 무엇을 반환하는지 알고 있기 때문이죠.

이제 홈페이지를 다시 로드하면 새로 생성한 레지던스를 확인할 수 있을 거예요.

그리고 저희는 그 카드 부분으로도 이동할 수 있습니다. 그 부분은 홈에서 저희가 가지고 있는 프로젝트들이 있는 곳에 있습니다.

네, 좋습니다. 여기 업로드 카드입니다. 그리고 프로젝트 카드 그룹이 있는 곳 바로 아래쪽에, 클릭 시 시각화 ID로 이동하도록 설정할 수도 있습니다.

자 이제 이걸 클릭하시면 프로젝트 상세 정보 페이지로 이동하실 수 있습니다.

정말 멋지네요. 다음 강의에서는 마우스를 좌우로 움직이면서 이미지의 전후를 볼 수 있도록 해주는 훌륭한 시각화 컴포넌트를 구현해 보겠습니다.

사용자들이 앱이 얼마나 큰 영향을 미치는지 직접 확인할 수 있도록 할 수 있습니다. 하지만 그걸 하기 전에 지난 몇 강의에서 저희 앱에 많은 코드와 기능을 추가했습니다.

네, 그렇다면 커밋을 진행해 보겠습니다. 터미널 내에서 git add dot git commit -m, 페테르 워커스를 구현하는 명령어를 실행하실 수 있습니다.

3D 바닥면 제작과 프로젝트 생성 작업이 포함됩니다.

그리고 `git push` 명령어를 실행하실 수 있습니다. 그런 다음, GitHub 저장소로 다시 돌아가시면 동일 브랜치에 최근 푸시 기록이 표시될 것이고, 이제 풀 리퀘스트를 열어볼 수 있습니다.

검토할 라인 320개입니다. 코드래빗이 뭐라고 할지 한번 살펴볼까요? 죽은 코드가 보이네요.

자, 지금 상태가 얼마나 심각한지 한번 확인해 보겠습니다. 우리가 구현한 내용이 무엇인지도 살펴봐야겠네요.

이 PR은 새로운 Pewter 워커 모듈을 통해 디자인 프로젝트를 저장, 목록화 및 검색하기 위한 REST API를 제공하는 백엔드 프로젝트 관리 시스템을 도입합니다.

프론트엔드에서 프로젝트 로딩 기능이 시작 시에 작동하도록 업데이트되었고, 프로젝트 생성 시 영구 저장을 지원하며, 시각화 뷰어와 상태 기반 프로젝트 데이터 간의 탐색 기능을 사용할 수 있게 되었습니다.

저기, 저희도 여기쯤에 어떤 다이어그램이 있는 것 같아요. 네, 이번 경우에는 여러 부분으로 나누어져 있습니다.

상단은 프로젝트 생성 흐름이고, 하단은 프로젝트 불러오기 흐름입니다. 따라서, 프론트엔드에서 새 프로젝트를 만들면, pewter를 거치게 됩니다.

액션 레이어를 거쳐서, 페테르 워커 API와 통신하고, 마지막으로 키-값 저장소인 데이터베이스에 접근하여 프로젝트를 저장합니다. 불러올 때도 같은 방식으로 액션을 통해 통신하게 됩니다.

데이터베이스에서 정보를 읽어 작업자분들께 전달하고, 프론트엔드로 다시 돌려보내는 작업입니다. 네, 코드래빗의 의견을 들어보겠습니다.

먼저 큰 문제가 하나 있습니다. 제가 실수로 워커 URL을 커밋해 버렸는데, 그것 자체는 큰 문제는 아니지만, env local은 절대로 .gitignore에 포함되어서는 안 됩니다.

나중에 혹시 다른 사람들이 접근하면 안 되는 걸 추가한다면, 절대로 거기에 넣으면 안 됩니다.

그래서 코드리빗에서 아주 좋은 프롬프트를 받았는데, 커밋된 env 파일을 레포지토리에서 제거하고 dot env dot local을 git ignore에 추가하라는 내용입니다. 한번 복사해 볼까요.

코드래빗에서 친절하게 제공해주신 프롬프트인데, 준이가 어떻게 활용할 수 있는지 한번 보겠습니다. 우선 터미널을 열어서 어떤 파일들이 있는지 확인해볼게요. 찾아보니까 파일을 찾았네요.

이 환경 로컬 파일을 제거하도록 요청받을 텐데, git 캐시에서 제거하고 .gitignore 파일에 추가한 다음, 이 자리 표시자를 사용하여 env.example 파일을 만들면 됩니다. 정확히 그게 하는 일입니다.

우리가 하고 싶은 일을 했어요. 자, 이제 git ignore를 수정했고, env example도 추가했으니 git status와 git push를 실행할 수 있겠네요. 좋습니다. 이걸 커밋하면 레포지토리에서 제거되겠어요.

완벽하네요. 터미널에서 git 상태도 확인하고 git push도 실행해 보겠습니다. 자, 이제 다른 의견들도 확인해 보겠습니다.

타임스탬프가 없을 경우 잠재적으로 잘못된 날짜가 될 수 있는 경미한 문제가 하나 있습니다. 저희 타임스탬프는 항상 존재할 거라고 생각합니다. 그래서 괜찮습니다. 프로젝트 생성 시 오해를 불러일으키는 경고 메시지가 있습니다.

이건 히스토리 패치를 건너뛰는 얘기인 것 같은데, 이 ENV가 없으면 프로젝트를 생성할 수 없다는 의미인 것 같아요. 그래서 수정 사항은 그냥 프로젝트 저장 과정을 건너뛰는 것으로 말하는 거죠.

네, 그렇게 추가하셔도 괜찮습니다. 그리고 주석 세공인 분은, 일관성을 위해 성공 응답에 Access-Control-Allow-Origin 헤더를 추가하는 작은 문제가 있습니다.

저희 오류 응답에서 접근 통제 허용 출처(Access-Control-Allow-Origin) 헤더를 반환하는데, 다른 라인에서는 그렇지 않은 것 같습니다. 일관성을 위해 해당 라인에도 추가해 주시면 감사하겠습니다. 자, 또 다른 문제가 있습니다.

저희 팀에서 프로젝트 키가 인증된 사용자 ID에 따라 제한되지 않는다는 문제가 제기되었습니다. 39행에서 사용자 ID를 가져오지만, 42행에서는 저장 키에 통합되지 않는 것으로 확인되었습니다.

핵심은 단순히 룸이파이 프로젝트 ID 하나만 사용하는 것이라서, 인증된 사용자는 ID를 추측하거나 재사용함으로써 다른 사용자의 프로젝트를 모두 변경할 수 있습니다.

동일한 문제가 리스트 및 가져오기 엔드포인트에도 존재합니다. 제안된 해결책은 사용자 ID를 키로 추가하는 것입니다.

지금 바로 수정할 수도 있지만, 영상 마지막 부분에서 개인 프로젝트와 공용 프로젝트를 구현하는 과제로 드리는 것이 좋을 것 같습니다.

이것이 여러분에게 도전 과제가 될 수 있는 부분 중 하나일 수 있습니다. 이 또한 가 divisibility(나누어 떨어짐)에 관한 것이며, 개인과 공공의 관계에 대한 내용이 될 것입니다.

네, 마지막 하나가 남았네요. 현재는 공개(public)를 'true'로 고정 코딩해두었지만, 나중에 이 토글을 이용해서 공개(public)와 비공개(private)로 전환할 수 있습니다. 즉, 지금은 문제없이 진행할 수 있는 상태입니다.

네, 그렇게 병합하시면 됩니다. 그리고 다음 수업에서는 그 시각화 도구를 구현해 보겠습니다.