은 아닌데,


원래 변수명에 GUBUN을 남발하면서 이것도 되고 저것도 되는 만능 게시판을 만들면서 놀려고 했는데,


석달째 되니까 힘들어서 안되겠다.



기본은 REST API 흉내

왜 흉내냐면 애초에 형식부터 POST는 읽기 전용, 쓰기는 PUT, 수정은 PATCH로 잡았고, GET 파라미터도 남발했기 때문에 흉내 맞음 ㅇㅇ

아무리 봐도 REST는 이론 자체가 결함인 거 같아서 그냥 내 맘대로 가는 걸로


프론트는 내장은 번들링 안 한 vue, 외장은 번들링 안 한 react랑 react-dom cdn

외장은 나중에 ㅠ


DB는 goqu+날쿼리로 해서 오라클 빼고 메이저 4개 다 지원하는 걸로

goqu는 구글링해보면 어딘가에 기능은 많지만 성능이 떨어진다는 2015년도 글이 있는데,

goqu를 쓴 이유가 struct scan 편하게 하는 거랑, 얘가 cgo 없는 cznic/sqlite 를 쓸 수 있는 유일한 아이다.

막상 써보니 쿼리빌더도 무지성으로 막 굴리기 딱 좋아서 앞으로도 계속 쓸 거 같다.



cgo쓰면 왜 안돼냐면 애초에 내가 go에 정 붙이기 시작한게


* 무설정 크로스컴파일이랑 - 리눅스 서버 내놔라고 했는데 윈도우 서버 세팅해놓고 다 됐어여ㅋ 거리는 비전산업체 고객님들 ㅠ

* 다른 솔루션 / 프레임워크나 외부 런타임에 의존하지 않는 거랑 - 기억이 잘 안나는데 rust도 gcc나 비주얼스튜디오가 필요한 경우가 있었다. JAVA, 파이썬 등 전통 플밍언어는 뭐 그냥 그렇고 ㅋ

* 동시성 편한거, 웬만한 라이브러리는 필요한거 다 있다는 거 등등인데 - 실제로 동시성은 라이브러리로 감싼거 위주로 쓰니까 쓰거나 고민할 일도 잘 없다


문제는 cgo가 들어가면 gcc로 컴파일해야 되고 경우에 따라서 크로스컴파일이 안되는 경우도 있고,

특히, 되긴 되는데 https://github.com/Kagami/go-face">https://github.com/Kagami/go-face 이런 식으로 gcc랑 헤비하게 붙인 경우에는 내가 c, cpp을 보는건지 go를 보는건지 알지도 못하고, 에러라도 뜨면 추적도 똑바로 못하고 정신줄 놓게 되는 경우가 많다.



이제 얘는 천천히 짬내서 놀등가 하고

또 돈 벌러 나가야지



홈페이지 게시판 만드시는 분덜 정말정말 존경함니다 ㅇㅂㅇ



암튼 끗


practice-golang/9minutes: GUBUN board (github.com)