Strapi 생각 나는대로 적는 사용기

 

 

 

strapi를 발견하고 나서 계속 써보았다. 첫 사용기를 쓴지 꽤 오랜 시간이 지난거 같다.

2020.12.28 - [프로그래밍] - Strapi 사용기 첫번째

Strapi 사용기 첫번째

 

지금 작성하는 글은 v3를 기준으로 작성한 글이다.

v4에서는 개선이 있거나 바뀌어 있는 부분이 있을것이다.

필자도 v4로 업그레이드 하고 싶은데 바빠서 못하고 있다.
v4와 v3의 커스텀 방식도 달라져서 꺼려지는 것도 한 몫하긴 한다.

 

NestJS처럼 체계가 잡혀있는 프로젝트 구조.

자동으로 생성되는 프로젝트의 구조를 보면 모델을 기준으로 자동으로 경로들이 생성된다.

Express를 사용해 본 사람들은 알것이다. 자유도가 높은 만큼 프로젝트 구조를 개인이 모두 짜야하는 상황이 생긴다.

Express만 써본 나로써는 자동으로 만들어주는 체계가 잡혀있는 프로젝트 구조가 마음에 들었다.

 

 

Admin 기본 제공은 1인 개발자 입장에서는 최고의 기능.

Django보다 이쁜 admin 화면을 그냥 만들어준다. API 만들기도 편하고 Admin도 제공하니 서버에만 집중하면 된다.

참고로 나는 프론트엔드 지식이 4,5년 전부터 단절되었기 때문에 너무 좋았다. 웹을 추가로 작업을 할 필요가 없었다.

 

혼자서 개발하는가?
admin도 만들어야 하는가?
Js에 익숙한가?
3가지 상황이 공존한다면 strapi는 꽤 좋은 선택지라는 생각이 든다.

 

 

Strapi를 사용하다보면 요구사항이 디테일해 질 수록 프레임워크의 장점이 옅어진다.

strapi의 가장큰 장점은 클릭 몇번만 하면 DB에 테이블 + CRUD API 생성이 자동으로 이루어진다.

이정도 편의성이라면 백엔드 개발자 입장에서는 서버 API만드는것이 두렵지 않게된다. 

클릭 몇번으로 나의 일을 쉽게 끝낼 수 있는 느낌에 자신감과 뽕이 차오르기 때문이다.

 

하지만 실제 서비스를 위해서 REST API 서버를 만들다보면 조금은 복잡한 요구사항들이 생기게 된다.

 

예륻들면, "게시판에 글을 등록하는 기능을 만들어 주세요." 라는 요청을 받았다면 클릭 몇번이면 해결이 가능하다고 생각한다.

"게시판에 글을 등록하는 기능을 만들어 주세요, 그리고 등록하고 나서 유저들에게 알림이 가는 기능을 넣어주세요. 그리고 알림보낸 내용은 목록에 계속 쌓이게 해주세요."라는 요청을 받는다면 이때 고민이 생기게 된다. 

 

"게시판에 글 등록하기 + 알림 메시지 보내기 + 알림 목록 쌓기" 를 하나의 request로 처리하고 싶다면 커스텀이 들어가게 된다. 이렇게 커스텀을 하게되면 클릭몇번으로 만든 API도 소용이 없게된다.

 

그리고 트랜잭션을 사용해야하는 상황이 생기면 무조건 커스텀을 할 수 밖에 없다.

table에 lock을 걸어야 하는 경우에도 커스텀을 피할 수 없게 된다.

추가로 커스텀을 하다 보면 ORM인 knex 나 bookshelf를 공부해야하는 상황이 생기게 된다.

 

커스텀을 피 할 수는 없다. 하지만 커스텀의 빈도가 많아질수록 strapi를 사용하는 의미가 옅어진다.

내가 직접 API를 만드는 양이 많아지기 때문이다.

 

은근 불편한 Update Query

https://docs-v3.strapi.io/developer-docs/latest/development/backend-customization.html#queries

Backend customization - Strapi Developer Documentation

프레임워크에서 제공하는 update query는 find 조건에 부합하는 row가 없으면 에러를 뱉는다. (Not found entity)
그리고 조건에 맞는 row가 여러개면 하나의 row만 업데이트 된다.

내가 예상한대로 row들이 업데이트가 제대로 되지 않으면 결국 kenx / bookshelf를 이용하게 된다.