일단 오해하지 않도록 먼저 정의하면 내가 말하는 풀스택이란 프론트 + API 작업임
프론트 개발자로 일하면서 프론트 / 백 분화는 어느 시점부터 비효율적이라고 생각함
프론트가 API 나올 때까지 손가락 빨 게 아니라 직접 API 만들고 프론트에서 연결하는 게 훨씬 낫겠다는 거지
이 방식의 장점은 두 가지가 있음
1. 프론트가 서버의 데이터 형태를 알 수 있음
프론트 측에서 타입을 좆대로 만들지 않고 서버에 근거해서 만들 수 있음(SSOT)
2. 서비스에 적합한 API를 설계할 수 있음
프론트는 화면을 직접 만드는 사람이기 때문에 어떤 정보가 필요한지 가장 잘 알고 있음
잘 아는 사람이 직접 만드는 게 더 효율적이겠지?
물론 그렇다고 백엔드가 쓸모 없다는 건 아님
내 요지는 프론트가 백엔드 작업의 일부를 해야 한다는 거임
눈을 떴구나 좆소로 오거라
+클로드 코드(코딩), 지피티(코덱스), 제미나이, 커서(curs0r) 최대 70% 싸게 가능함
https://goodmanytips.com/clolo/
대기업 중견 아니면 원래 그렇게 하잖아 ㅋㅋㅋㅋㅋ 중소중에 나누는 곳은 좋은 지 모르겠던데 - dc App
프론트 공고 보면 풀스택이거나 프론트 앱/웹 둘 다 만들거나 둘 중 하나더라
원래 웹개발자가 다하던건데 언제부터 리웩트니 뭐니 하면서 다 갈라쳐 놓음. 웹개발은 풀스택으로 다시 돌아갈꺼고 못하면 도태다. 풀스택이라고 말하는것도 웃기네. - dc App
리웩트 그냥 시간낭비임. 바닐라 자스로도 구현 다 가능한것도 다른 프론트엔드 서버에서 돌리는거 부추기는 ㅂㅅ 원래 php 처럼 백엔드 프론트엔드 한번에 다만드는게 웹개발이었음
작은규모 프로덕트나 시스템이면 풀스택이 좋을수도 있겠지만 규모가 커지면 불가능함 사람 한명이 할수있는 일은 한계가 있음 그리고 책임 분산을 위해서라도 나눠져야함 - dc App
si는 이미풀스택임 jsp 뷰 리액트 한번씩은 다본듯
프론트 백엔드 기준자체가 병신되서 그럼.. 개인적인 주관은 프론트는 그냥 딱 템플릿정도임. 레이아웃, 컴포넌트 강조하자면 css 그 외에는 백엔드가 주관하는게맞다봄.
그럼 뒤에 아키텍쳐 짜고 데브옵스는 누가함? 그것도 풀스택이면 할줄 알아야지
프론트 백엔드 분리가 의미없을 규모면, 인프라도 그냥 대충 하면 되긴 하잖아 ㅋㅋㅋ 근데 그걸떠나서 나는 프론트, 백엔드 나누는것보다는 SD랑 옵스로 나누는게 더 효율적이라고 생각함
Jsp php 쓰던 시절로 돌아가자는 거노
원래 모킹으로 프론트도 동시에 개발해야되는거 아님?