파이썬 전환도 충격적인데 프레임웍 선택은 더욱 충격입니다.
fastapi는 API를 만들기 위한 물건이지, MPA를 만들기 위한 물건이 아닙니다. 장고를 쓰던가 플라스크를 쓰던가 해야했습니다. 근데 haeless형태도 아닌데 fastapi를 쓰겠다는건 뭔 생각인지 모르겠습니다.
-
?
밴치마크가 다가 아니고요... fastAPI는 기본적으로 API를 위해 만들어진 물건입니다. headless 방식의 CMS에 이걸 쓴다면 찰떡궁합이겠지만, 그누보드는 언어만 바꿨지 헤드리스 형태로 바뀌지는 않았습니다. -
제 경험상, 지난 20년간 PHP를 버리고 다른것 가서 잘된 사례를 한번도 보지 못했는데,
'그누보드 파이썬버전' 이 아니라 '그누보드6'라고 못 박아 버렸으니...
개인의견으로는 그누6가 sql prepared statement 지원 및 기존 file param 방식의 절차형 방식에서 oop mvc 객체지향 으로 바꾼 버전이 나왔어야 하지 않나 생각해봅니다.. -
?
그게 바로 라이믹스네요
그누 6는 파이썬으로 가서 MVC + ORM 을 해버리고..
XE3 이(라라벨) 망해버린탓이 제일큰듯
라라벨이 말씀하신 그것이니까요 아니면 라이믹스로 갈사람 다가고
-
API가 Content-Type: text/html을 반환하면 그게 MPA죠. 특별할 것이 없습니다. 반대로 스킨에서 HTML 싹 다 빼 버리고 Content-Type: application/json을 반환한다면? 흔히 말하는 API가 됩니다.
지금은 기존 사용자층이 쉽게 적응할 수 있도록 DB 구조도 비슷하게 유지하고, 출력하는 내용도 HTML을 기본으로 둔 것 같지만, 나중에 필요하면 headless로 사용할 수도 있도록 미리 기초를 닦아 놓으면 좋겠다, 라는 정도는 충분히 고려하고 내린 결정일 거라고 생각합니다. 별도의 프론트엔드 프레임워크를 갖다 붙이거나, 앱과 연동하는 API만 제공하는 것이 대세라는 것은 삼척동자도 아니까요.
쟝고를 쓸 거라면 굳이 그누보드를 쓸 이유가 없습니다. XE3와 똑같은 상황이 되지요.
Flask는 쟝고보다 가볍게 다룰 수 있지만, 솔직히 FastAPI와 큰 차이는 없습니다. Flask로 API를 만들 수도 있고, FastAPI로 MPA를 만들 수도 있지요. 파이썬을 가장 많이 사용하는 분야(과학계, 데이터 분석, AI/ML 등)에서 FastAPI가 핫한 덕에 도움을 받기도 수월하고, Flask는 연식이 좀 있다 보니 옛날 느낌이 나기도 해요. 둘 중 어느 쪽을 썼더라도 충분히 이해할 수 있는 선택이라고 봅니다.
남은 문제는 사용자들의 호응을 얼마나 잘 이끌어내고, 부드럽게 넘어갈 수 있느냐 하는 것인데... 이건 솔직히 프로그래밍 언어나 프레임워크의 문제라기보다는 커뮤니케이션의 문제이고, 이 부분에 있어서 SIR은 XEHub보다 훨씬 괜찮은 실적을 보유하고 있기에, 섣불리 비관적인 전망을 내놓고 싶지는 않습니다.
api 를 붙이기 더쉽겠다는 생각이 드네요
파이썬 자체가 느려서 장고는? 플라스크도 마이크로 프레임워크인데 fastapi 의 하위호환이라 안했나봐요
sanic 이랑 fastapi 가 파이썬프레임워크중에서 제일빨라요