Cloudflare가 내 설정을 장악하는 것이 지겨워서 암호화된 폼 툴을 다시 작성했습니다
Source: Dev.to
Overview
formseal-embed는 클라이언트‑사이드 암호화된 연락 양식을 위한 드롭‑인 유틸리티입니다. 페이지에 삽입하면 브라우저에서 제출 내용을 암호화하고, 백엔드에서는 암호문을 받아 자체적으로 복호화할 수 있습니다.
원본 버전은 동작했지만, 일종의 카드 하우스와 같았습니다: 수정할 때마다 Cloudflare(KV, Workers, 챌린지/검증 파이프라인)를 떠올리게 되었죠. 상류에서 하나의 설정만 바뀌어도 하류 전체가 조용히 깨졌습니다. 그래서 다시 시작하면서 스스로에게 계속 물었습니다: 이게 여기 있어야 하는가, 아니면 내가 싫어하는 것을 다시 만들고 있는가?
The only real constraint
제가 스스로에게 내린 규칙은 하나였습니다: 도구는 POST 요청을 받는 어떤 엔드포인트와도 동작해야 한다는 것. 백엔드에 대한 가정, 벤더‑특정 훅, “X에 최적화됨” 같은 조건은 없습니다. URL만 있으면 동작합니다.
간단해 보이지만 모든 것을 바꾸어 놓았습니다. embed는 똑똑한 백엔드 트릭을 사용할 수 없고, CLI는 특정 플랫폼을 가정할 수 없으며, 모든 기능은 이것이 벤더 중립성을 깨뜨리는가? 라는 테스트를 통과해야 했습니다. 많은 아이디어가 살아남지 못했습니다.
The embed does less than you’d expect – on purpose
처음에는 embed를 똑똑하게 만들고 싶었습니다: 필드‑레벨 검증, 커스텀 오류 메시지, 자동 생성 마크업 등. 하지만 그런 결정은 도구를 사용하는 개발자가 해야 할 일이며, 도구 자체가 할 일이 아닙니다.
그래서 기능을 최소화했습니다. embed는:
name속성을 읽고,- 버튼 상태를 관리하고,
- 페이로드를 암호화하고,
- 이를 POST합니다.
그게 전부입니다. HTML은 여러분이 직접 관리합니다. 제한적으로 보일 수 있지만, formseal-embed가 이미 존재하는 어떤 폼 구조와도 동작한다는 보장을 제공합니다.
Why the CLI is Python and not Rust or Go
Rust(빠르고, 단일 바이너리, 런타임 없음)와 Go도 고려했지만, “어떤 머신에서든 fse init을 처음 실행할 때 이미 설치된 것만으로도 동작하게” 하는 모습을 떠올릴 수 없었습니다.
Python은 거의 대부분의 환경에 존재하고, 빌드 단계가 필요 없으며, 마찰을 전혀 발생시키지 않습니다. 설정용 CLI에서는 이러한 트레이드‑오프가 의미가 있습니다: 도구는 방해가 되어서는 안 됩니다.
What’s coming: fse doctor
테스트 중에 작은 설정 오류가 전체를 조용히 깨뜨리는 경우를 많이 마주했습니다—잘못된 엔드포인트, 잘못된 공개키 등. 디버깅이 고통스러웠죠.
fse doctor는 fse init 이후에 실행되어 전체 설정을 검사합니다: 구성, 엔드포인트 접근성, 공개키 유효성, 스키마 필드 등. 무엇이 잘못됐는지, 어떤 명령을 실행하면 해결되는지 정확히 알려줍니다. 아직 출시되지 않았지만 작업 중이며, 처음부터 존재했어야 할 기능처럼 느껴집니다.
The thing I kept having to resist
재작성에서 가장 어려운 부분은 암호화나 CLI 구조가 아니라, 기능을 추가하고 싶은 충동을 억제하는 것이었습니다. 합리적으로 보이는 모든 추가는 도구를 백엔드, 플랫폼, 검증 로직에 대해 의견을 갖게 만들었습니다.
벤더 중립성은 추가하는 기능이 아니라, 많은 합리적인 아이디어에 아니오라고 말함으로써 강제하는 제약입니다.
Come take a look
패키지는 npm에 @formseal/embed로 배포됩니다. 소스는 .
fse doctor가 체크했으면 하는 내용, CLI에 부족한 점, 혹은 암호화 파이프라인을 살펴보고 싶다면 이슈와 PR을 언제든 환영합니다. 폼이 라이브되기 전에 무엇을 검증해야 할지 다른 사람들의 의견을 듣고 싶습니다.
벤더‑락 문제를 서드‑파티 폼 도구와 겪어본 적이 있나요? 우회했나요, 아니면 그냥 받아들이고 진행했나요? 정말 궁금합니다.