잼스택이라는것이 2020년부터 근래에 자주 언급된다.
- Jamstack = JavaScript, API, Markup -- "LAMP스택" 같은식으로 만들어진 용어.
- 2015년 만들어진 용어. 백엔드와 tight coupling없이 frontend에서 돌아감.
- Git-CMS or headless CMS.
- 웹을 빠르고 쉽게 스케일링 하기 위한 아키텍쳐.
- pre-rendering, decoupling.
읽을거리
- https://www.infoworld.com/article/3563829/jamstack-the-static-website-revolution-upending-web-development.html
- https://www.infoworld.com/article/3638054/unstoppable-jamstack-and-the-gatsby-opportunity.html
- https://www.infoworld.com/article/3546336/9-reasons-to-build-your-web-app-with-the-jamstack.html
개인관점:
- FE (frontend)중심적 개발이 많아지면서 FE코드를 pre-generate하여 많은 작동을 사용자의 웹브라우져에서 실행, 서버와는 graphql API를 이용하는 형태.
- site-map을 이용하여 pre-generate하는것 -- 이런 형태의 개발은 JavaScript개발자 중심의 웹앱이 되고, 기존의 사용자 중심의 CMS (UI로 contents를 DB에서 다루는) 에서 멀어진다. 기존 UI방식으로 사용자에게 컨트롤을 넘겨줄수도 있으나, 실제 개발방식을 보면 JavaScript개발의 방식과 컬쳐, 개발자 중심으로 싸이트가 운영이 되어 작은것을 바꾸는데에도 많은 손이 가지만, 요즘의 비지니스가 원하는 빠른 변경요구에 대처하려면 사실 이 방식밖에 없을수도 있겠다. 웹앱중심으로 백앤드는 단순히 DB등의 백엔드 서비스를 엑세스 하는 역활로 단순화 될수 있는데, 문제는 프론트엔드 개발자가 백엔드및 시큐리티, 등 백엔드의 이해가 부족하면 나중에 큰 문제가 발생할 여지가 있다.
개발 유행:
- JavaScript (React)
- API (GraphQL): Golang, Rust, Node.js
위험도:
- 자바스크립트 언어 자체의 난해함.
- 난무 하는 라이브러리.
- 라이브러리를 통한 지속적 시큐리티이슈.
- FE개발 중심과 빠른 변화에 대처하기에 힘든 백엔드.
- Git에 대한 더 많은 의존.
- 대기업, 은행, 정부 등에서는 지양하고, 아직은 기존의 Angular와 자바 등의 백엔드를 쓰는것이 합당.
- GraphQL서버에 과부하가 걸리기 쉽고, 이것은 DevOps, 벡앤드 개발자의 보이지 않는 골치꺼리가 되고 FE개발자는 비지니스에 벡앤드 팀의 문제로 블레임하기 쉽다.
- 그렇기에 소위 fullstack dev를 원하는데 이게 그리 간단한 문제가 아니지만 회사에서는 그것을 상관안한다.
결국엔 돌아돌아 다시 예전으로 돌아오고 있는듯한 느낌이다. FE가 복잡해지고 더 많은것을 처리하는것은 결국엔 옛날의 client-server방식으로 VB로 FE를 처리하는듯하게 No Code/Low Code형식으로 FE개발쪽은 그렇게 흘러가고 JS는 더욱더 machine 중심, generated 코드 중심으로 흘러갈듯하다. 백엔드는 결국엔 모두 클라우드의 서비스를 이용하는 형태로 될것이며, 이것을 통합하여 거대 클라우드 서비스 회사들은 No Code/Low Code를 실현하게 될것으로 보인다. 이 모든것이 자동화 되여야 할수 밖에 없는 상황으로 갈것이고 그렇게 자잘한 개발은 현저히 줄어들거나 없어질것으로 보인다. 대신 모든것을 디자인/아키텍트를 하는 형태로 바뀔것으로 생각된다.