next.js를 사용한지 반년이 되어간다 (필자는 아직 애기 개발자 실무 1년 5개월?)
클라이언트 API 서비스도 같이 담당하고 있다.
이제야 nextJs에 익숙해져간다고 생각했는데, 갑자기 사수분께서 ServerAction을 사용해보자고 하셨다!!
필자: 네? 어떤거지?
진짜 이러한 모습이었다 하지만 새로운 걸 경험하는 건 좋아한다 ^^
일단 다음 프로젝트에 들어가기 전에 ServerAction을 구글링 해봤다.
그래서 아~ 이런거구나 하고 일단 부딪혀 보고 간단한 Create Read fetch 작업을 해봤다. 하라면 해야지,,,
한번 느낀 걸 적어보겠다
ServerAction은 Next.js 13.4버전 이상에서 지원해주는 기능이라고 한다!
기존에는 서버와 통신을 하기위해서는 API를 만들고 클라이언트단에서 api 통신을 했지만 이 과정을
전부 서버 컴포넌트에서 처리한다.
기존 서버와 통신
서버
api/test.ts
export function GET(request:Resquest): NextResponse<Response>{
return NextResponse.json({
status:"",
data:{
id:"",
name:""
}
})
}클라이언트
const getData = (request: Request):Promise<Response> =>
fetch('URL', {body:"",headers:{}}).then(res => res.json())
const [data, setData] = useState<Response>();
useEffect(() => {
getData({}).then(setData);
},[])Server Action을 사용한 통신
서버
// test/serverAction.ts
"use server";
export async function fetchData(userId) {
const data = clientPrisma.dbTable.findUnique({where:{id : userId}, select : {name : true}});
return data;
}클라이언트
const [data, setData] = useState<ResponseType>();
useEffect(() => {fetchData(params).then(setData);},[])엄청 간단해진 것 같다
이러하게 ServerAction은 "use server" 사용하여 서버 컴포넌트를 정의할 수 있고 이 안에서 데이터 fetching이 이루어진다.
또한, 간편한 API 라우팅!
예를 들어,api 폴더라는 곳에 넣고 작동한다. 하지만 serverAction은 별도의 api 라우트를 정의하지 않고, 컴포넌트 내에서 서버 액션을 정희하고 호출할 수 있다!
ex) test/serverAction.js
이렇게 함으로써 클라이언트와 서버 간의 상호작용을 쉽게 처리할 수 있는 것 같다
아직 많이 사용하진 않았서 제대로 설명이 부족했는데 분명 장단점이 있을 것 같다! 그 부분은 직접 적용하면서 경험해 보고 와서 다시 작성해보겠다.
이 글을 보시는 분은 없으시겠지만 글을 작성하고 3개월이 흘렀다
안그래도 저번에 작성한거에 이어서 더 작성해야 싶었는데 최근에 바쁘게 살아서 정신없이 시간이,,,
nextjs 14 app router를 사용하고 있다. 현재 클라이언트 서비스는 ServerAction으로 만들고 있다.
기존에는 ServerAction을 사용하면서 익숙해진 건진 모르겠지만 편하다고 생각한다.
1. 데이터 캐시
기존에는 데이터 저장 관리를 React-Query(Tanstack-Query)로 많이 사용했는데 ServerAction을 사용하면 그 기능을 지원해 준다.바로~~~ Next/cache 내장 라이브러리인 revalidatePath이다.
예를 들어 Post로 생성 및 업데이트할 데이터를 React-Query로 캐시 키값을 조작하거나 해줘야 했다. (클라이언트에서 데이터 관리를 하고 있었다)
onSuccess : async () => {
toast.success("");
queryClient.invalidateQueries({ queryKey: ["query-key"]});이런식으로 말이다.
하지만 클라이언트 API 서비스를 ServerAction을 사용하면서 데이터 관리를 쉽게 할 수 있다.
try
{
await updateNotice({블라블라...})
revalidatePath("/해당 url")
}catch(e){
console.error(e);
}서버에서 해당 url에 담긴 데이터들이 상태가 업데이트 된다.
얼마나 간단한가? revalidatePath(next/cache) bb
2. 보안
기존에는 API 호출 시 네트워크상에 함수가 실행된 걸 볼 수 있고 그 과정에서 어떤 데이터들이 오고 가는지 확인할 수 있었다 하지만 ServerAction을 사용하면 서버에서 실행되기 때문에 클라이언트에 노출이 되지 않아 보안적 측면에서 좋다고 생각한다기존 작업 네트워크창에서 보면 아래의 사진과 같이 response가 뜨는걸 확인할 수 있었다
ServerAction으로 도입 후 아래와 같이 클라이언트단에서 뜨지 않는 것을 확인할 수 있다
이를 통해 보안이 강화되고, 클라이언트가 실행하지 말아야 할 로직이 클라이언트로 노출되지 않게 된다
후기.
사실 사용해 본 느낌으로는 익숙해져서 편리한 것도 있고 장점으로 보이는 것도 있다.
그런데 ServerAction이 제일 좋다?라는 말보단 프로젝트 상황에 맞게 쓰는 게 가장 중요한 것 같다.
요즘 느끼는 건 요즘 "이게 유행이다", "대세다", "이게 좋다" 라기보단 개발할 때 현 상황에 좀 더 맞고 부수적인 것까지 고려해서 사용을 하는 게 제일 좋은 것 같다.
앞으로 무궁무진한 프론트에 계속 부딪혀볼 예정이다.
