엔진 먼저, sidecar 는 나중

"엔진을 완성해. API 를 열어. sidecar 는 나중에 오게 해. 그 순서로, 절대 뒤섞지 말고."

순서가 곧 레슨

API-first 는 경계가 어디 인가만이 아냐 — 무엇이 언제 지어지는가야. Ember 가 먼저 지어지고 API 를 열었고, 그제야 Cinder 가 컨슈머가 됐어. Bonfire 는 그 순서를 그대로 물려받아: 엔진 완성, API 개방, sidecar(Sidekick 의 깊은 기능, 결국의 Live 브리지)는 나중. 내장 UI 가 첫 클라이언트인 건 정확히 엔진의 API 가 진짜라는 걸 증명하는 클라이언트라서야.

왜 sidecar 를 일찍 안 짓나

흥분되는 sidecar 를 엔진과 나란히 짓고 싶어 — Live 브리지, 화려한 코칭 모드. 근데 반쯤 된 엔진 API 에 대고 지은 sidecar 는 모래 위에 짓는 거야. 엔진 표면이 아직 움직여; 네가 소비하는 모든 엔드포인트가 다음 주에 모양이 바뀔 수 있어. 그래서 sidecar 가 요동쳐: 다시 쓰고, 다시 깨지고, 다시 쓰고. 타깃을 끝내는 대신 움직이는 타깃을 쫓는 데 힘을 써. 더 나쁜 건, 안 끝난 sidecar 가 엔진 API 가 진짜 옳기 전에 얼리라고 압박해.

예측이 아니라 concrete-first

'예측해서 일반화하지 마' 와 같은 규율이야(Track 8 에서 다시 봐). 첫 소비자가 단단해지기 전에 두 번째 소비자를 안 짓고, 상상의 필요로 API 를 설계 안 해 — 눈앞의 진짜 클라이언트 하나(UI)를 위해 설계하고, 깨끗하고 진짜인 경계가 다음 클라이언트도 챙겨줄 거라 믿어. concrete-first 는 위에 뭔가 추측성으로 짓기 전에 엔진과 그 첫 UI 클라이언트가 끝나고 증명되는 걸 뜻해. sidecar 는 끝난 엔진의 보상이지 동반 필수가 아냐.

Code

엔진 -> API -> sidecar, 절대 뒤섞지 말고·text

Ember:    엔진 빌드 ──→ API 개방 ──→ Cinder 가 소비
Bonfire:  엔진 빌드 ──→ API 개방 ──→ UI 가 소비 ──→ (나중) Live 브리지
                                       ▲ 첫 클라이언트 = API 가 진짜라는 증명

# sidecar 는 API 가 진짜인 다음에 와, 절대 전이 아니라.
# 반쯤 된 엔진 API 위의 sidecar 는 그냥 요동쳐.

Exercise

네가(또는 팀이) 소비자와 그 의존성을 나란히 지은 프로젝트를 떠올려 봐. 의존성의 인터페이스가 바뀌면서 소비자가 먹은 재작업이 얼마야? 이제 반대 순서를 상상해: 의존성을 먼저 끝내고 얼린 다음, 안정된 표면에 대고 소비자를 지음. 아낀 재작업을 가늠해. 그 차이가 순서를 뒤섞은 비용이야.

Hint

요동은 'API 가 바뀌어서 클라이언트를 또 다시 썼어' 로 나타나. 그 재작성을 세 봐. 생산 쪽이 소비 쪽 시작 전에 끝나고 안정되면 대부분 사라져.