React는 풀스택 프레임워크(가 되어가는 중)임
(robinwieruch.de)- 서버 컴포넌트와 서버 액션을 추가한 React는 풀스택 프레임워크로 진화중
2010년 프레임워크 전쟁 시작
- 2010년 Backbone, Knockout, Ember로 시작된 프레임워크 전쟁은 Angular와 React가 빠르게 뒤따랐고, 그 결과를 아무도 예측할 수 없었음
- 오랫동안 클라이언트 사이드 렌더링(CSR) JavaScript 애플리케이션이 지배적이었음
- 이러한 애플리케이션은 단일 페이지 애플리케이션(SPA)이라고도 하며, 일반적으로 작은 HTML 파일과 큰 JavaScript 파일로 구성됨
- 코드 분할이 도입되기 전까지는 그러했음
프론트와 백엔드의 분리
- 이 기간 동안 프론트엔드 개발은 다양한 JavaScript 프레임워크와 라이브러리가 지배했음
- 백엔드는 일반적으로 특정 언어에 묶이지 않았고, REST가 API 통신의 표준이 되었음
- 나는 프리랜서 웹 개발자로서 주로 .NET, Java, Python, PHP 백엔드와 함께 일했음
- TypeScript/JavaScript는 그린필드 프로젝트이거나 백엔드를 제어할 수 있는 작은 프로젝트에서만 백엔드에서 봤음
- 그러나 풀스택 React의 부상으로 이것이 바뀔 수 있음
- 2010년에서 2020년 사이의 기간에 대한 개발자들의 인식이 경력 시작 시기에 따라 다른 것이 흥미로움
- 2010년 이전에 시작한 개발자들은 서버 사이드 렌더링(SSR) 환경에 있었고, 최근 서버 사이드 기술로의 회귀에 더 편안해 보임
- 반면 많은 다른 이들은 거의 10년 동안 클라이언트 사이드 렌더링(CSR) 애플리케이션에서 REST API로만 작업했음
- 이제 그들은 새로운 풀스택 React 세계를 어떻게 받아들여야 할지 모르고 있음
TypeScript가 업계 표준으로 등장
- 최근 몇 년 동안 TypeScript가 업계 표준으로 떠오름
- TypeScript는 프론트엔드 개발자에게 유형화되고 강력한 프로그래밍 언어를 제공
- 개발자들이 TypeScript를 받아들이면서 돌아갈 수 없는 지경에 이름
- 코드의 작은 변화가 개인과 산업 전반에 큰 영향을 줄 수 있다는 것이 흥미로움
TypeScript와 REST의 어려움
- TypeScript가 REST에 미친 영향은 임시방편적 해결책이 많음
- OpenAPI(구 Swagger)는 REST API 문서화를 위해 존재했지만, 이제는 주로 타입 API 인터페이스를 생성하는데 사용됨
- 클라이언트-서버 아키텍처에서 완벽한 타입 인터페이스를 만들 수 있음에도 불구하고, 시작부터 제대로 구현하는데 실패하는 프로젝트가 많음
-
개인적인 노트 : "OpenAPI 기반 아키텍처에서 좋은 경험을 한 개발자도 있겠지만, 안타깝게도 필자는 그렇지 않음"
TypeScript가 분위기를 바꿈
- TypeScript가 여기서 분위기를 어떻게 바꾸었는지 보는 것이 꽤 흥미로움
- 한편으로는 REST(문서화 목적의 OpenAPI)를 사용하는 비유형화된 SPA가 "괜찮아" 보였음
- 그러나 TypeScript가 표준이 되고 규범으로 여겨지면서, 생성된 타입 인터페이스는 프론트엔드 코드베이스에서 더 높은 기준에 익숙해졌기 때문에 다루기 불쾌해졌음
- 생성된 타입 인터페이스의 단점은 명확함:
- 항상 생성 단계가 포함되어 있음
- 생성된 출력이 복잡함
- 초기 설정에 따라 생성된 코드가 항상 올바르지는 않음
RPC와 tRPC의 등장
- RPC는 새로운 개념은 아니지만 tRPC 덕분에 React 생태계에서 인기를 얻음
- 8만 줄 코드 애플리케이션에서 6개월 동안 솔로 개발자로서의 경험에 따르면, 백엔드에서 함수를 호출해 데이터를 읽고 쓰는 것은 계시와도 같았음
- TypeScript를 사용하는 스택 양쪽에서 이보다 더 생산적이라고 느낀 적이 없음
- 개인적으로 몇 년 전 (생성된) 타입 GraphQL 아키텍처에서만 비슷하게 생산적이라고 느꼈음
- 2023년 한 해 동안 tRPC보다 더 나은 것은 상상할 수 없었음
- 백엔드에서 함수를 호출해 데이터를 읽고 쓰는 것은 혁명적으로 느껴졌음
- 하지만 그게 내가 필요한 전부였을까? 아니었음
Server Components와 Server Actions의 혁신
- 나에게 진정한 돌파구는 2024년 Server Components와 Server Actions에서 왔음
- 이들은 서버를 호출할 뿐만 아니라 다른 쪽에서 코드를 구현하고 실행할 수 있도록 하여 서버와의 격차를 해소함
- Server Components는 서버에서 React 컴포넌트를 실행할 수 있게 하여 JSX로 UI를 반환하기 전에 데이터 소스(예: 데이터베이스)에 직접 액세스할 수 있게 함
- Server Actions는 후드 아래에서 HTTP API 엔드포인트를 생성하여 원격 프로시저 호출과 마찬가지로 함수를 실행하여 호출할 수 있음
- Server Components와 Server Actions는 React를 풀스택 프레임워크로 변모시킴
- 프론트엔드를 풀스택 환경으로 전환하는 흥미진진한 시기임
React의 Server Components와 Server Actions 지원
- React 자체는 Server Components와 Server Actions에 대한 기본 요소와 사양만 제공함
- React 위에 구축된 메타 프레임워크는 클라이언트와 서버 간의 지시문을 해석하는 번들러로 격차를 해소할 수 있음
- Next.js는 Server Components와 Server Actions 구현을 선도하고 있음
- Next.js는 이전에 서버 사이드 렌더링(SSR)을 지원했지만, 이제 Server Components와 Server Actions를 통해 개발자는 데이터베이스 및 메시지 큐와 같은 서버 측 리소스에 액세스할 수 있음
풀스택 개발의 시작
- React를 사용한 풀스택 개발은 이제 막 시작되는 단계임
- 개발자가 Server Components와 Server Actions를 통해 데이터베이스에 직접 액세스하기 시작하면서 단순한 CRUD 애플리케이션을 넘어서는 복잡성을 길들이는 과정이 있을 것임
- 철저한 교육을 통해 프론트엔드 개발자는 레이어, 설계 패턴 및 모범 사례를 사용하여 백엔드 아키텍처 구현을 곧 마스터할 것임
- 솔직히 말해서, 아무도 React 컴포넌트에서 ORM 함수 호출을 보고 싶어하지 않기 때문임
패러다임 전환에 대한 기대
- 나는 이 패러다임의 전환에 대해 매우 기대하고 있음
- React 개발자가 UI에서 데이터베이스까지 수직적 기능을 구현하는 새로운 시대를 준비할 것
nextjs server action은 개발자가 제어할 수 없는 랜덤 API 엔드포인트를 public하게 노출하는 문제가 있는데 굉장히 취약한 부분이라고 생각합니다.
그거 이미 해결했습니다. 14.1.1 부터 수정된 버전 사용하면 됩니다.
https://github.com/advisories/GHSA-fr5h-rqp8-mj6g
혹시 언급하신게 어떤 취약점인지 알 수 있을까요?검색하면 SSRF 취약점이란게 나오긴하는데 맞는지 잘 모르겠어서요. next js 공부하는 참인데 궁금해서 여쭤봐요.
애시당초 SPA를 밀던 사람들의 의도는 뭐였을까요? jquery로 DOM 조작하던 시절보단 훨씬 나은데, 백엔드 프론트엔드 설계와 개발에 필요한 개념은 안 없어지고 위치만 이동하는 것 같네요. 라우팅만 해도 서버에서 클라이언트로 옮겼다가 서버사이드 렌더링 유행때문에 다시 서버로 옮기려고 하고요
3년 후에도 과연 코딩 학원이나 강좌에서 SPA 스타일 리액트를 가르칠지도 의문입니다