Spring Cloud Contract vs Swagger

왜 나왔나?

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주도인 착각을 할 수도 있지만 결국엔 서버에서 정의된 항목을 선 가공해서 전달받는 것 뿐이다.

어설프게 도입하는 회사는 좆되겠네

대신에 정의를 잘 해 두면 이걸 요구사항으로 두고 서버,클라이언트 모두 개발 및 테스트를 할 수 있을 것 같다. 하지만 그렇게 잘 정의될만한 프로젝트가 많지 않다.
특히 초기 서비스 개발시에는 불가능. 리팩토링 단계에서나 적용해야할 것 처럼 보이는데…
이미 돌아가는 서비스에 시간을 들일 수 있을까

이걸 기반으로 한 테스트 코드작성도구가 제공되는건 장점이려나

타 언어와 호환되지 않는건 또 단점