왜 나왔나?
1. Why use Spring Cloud Contract?
Spring Cloud Contract works great in a polyglot environment. This project has a lot of really interesting features. Quite a few of these features definitely make Spring Cloud Contract Verifier stand out on the market of Consumer Driven Contract (CDC) tooling. The most interesting features include the following:
- Ability to do CDC with messaging.
- Clear and easy to use, statically typed DSL.
- Ability to copy-paste your current JSON file to the contract and edit only its elements.
- Automatic generation of tests from the defined contract.
- Stub Runner functionality: The stubs are automatically downloaded at runtime from Nexus or Artifactory.
- Spring Cloud integration: No discovery service is needed for integration tests.
- Ability to add support for any language & framework through Docker.
맞나? 좀 아닌듯
swagger와 역할이 겹친다.
swagger의 문제는
- response의 Schema가 불확실하게 표현되는 경우가 많다.
- Spring같은 경우 자동으로 생성되기 때문에 자꾸 변한다.
- 파라미터 케이스별로 값을 확인할 수 없다.
이런 부족한 부분에서 기능을 확장시키는 방향으로 하는게 낫지 않았을까?
소비자 주도? 말도 안된다. Client에서 response Contract를 정의해서 보내준다고 Server에서 거기에 다 맞춰서 만들어줄 수는 없다. 결국 요구사항만 전달하는 정도에 그쳐야한다는거다.
graphql도 client주도인 착각을 할 수도 있지만 결국엔 서버에서 정의된 항목을 선 가공해서 전달받는 것 뿐이다.
어설프게 도입하는 회사는 좆되겠네
대신에 정의를 잘 해 두면 이걸 요구사항으로 두고 서버,클라이언트 모두 개발 및 테스트를 할 수 있을 것 같다. 하지만 그렇게 잘 정의될만한 프로젝트가 많지 않다.
특히 초기 서비스 개발시에는 불가능. 리팩토링 단계에서나 적용해야할 것 처럼 보이는데…
이미 돌아가는 서비스에 시간을 들일 수 있을까
이걸 기반으로 한 테스트 코드작성도구가 제공되는건 장점이려나
타 언어와 호환되지 않는건 또 단점