답변.

API 아키텍처 스타일의 선택은 확장성, 속도, 유연성, 호환성 및 API 소비자의 특성 요구 사항에 따라 다릅니다.

• REST: 간단함(HTTP, JSON), 멱등 작업, 캐싱 및 툴에 대한 폭넓은 지원 덕분에 대부분의 내부 및 외부 통합에 적합합니다.
• gRPC: 높은 성능과 양방향 스트리밍, 낮은 대기 시간 및 엄격한 스키마(Protobuf)를 위해 사용됩니다. 내부 서비스 및 마이크로서비스에 적합하며, 성능 요구 사항이 호환성 요구 사항보다 높은 상황에 적합합니다.
• GraphQL: 클라이언트가 데이터 구조를 선택할 수 있게 해 줍니다. 유연성이 필요하며 트래픽을 최소화해야 하는 외부 모바일 및 프론트 엔드 클라이언트에 적합합니다.

코드 예시(gRPC 서비스 Go):

// 프로토콜 설명
service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// 구현
func (s *server) SayHello(ctx context.Context, req *pb.HelloRequest) (*pb.HelloReply, error) {
  return &pb.HelloReply{Message: "Hello " + req.Name}, nil
}

주요 특징:

• 다양한 아키텍처 스타일(REST, gRPC, GraphQL)은 서로 다른 문제를 해결합니다.
• gRPC는 속도와 유형화에 대한 높은 요구 사항을 가진 내부 API에 더 적합합니다.
• GraphQL은 많은 요청 변형과 다수의 프론트 소비자가 있는 복잡한 공개 API에 최적입니다.

함정 질문.

GraphQL을 사용하여 모든 REST 또는 gRPC API를 대체할 수 있습니까?

아니요, GraphQL은 항상 합리적이지 않습니다 — 캐싱, 로깅을 복잡하게 만들고 API 보호를 어렵게 하며, REST 또는 gRPC가 더 간단하고 신뢰할 수 있는 간단한 작업에는 과잉일 수 있습니다.

REST는 엄격한 유형화를 보장할 수 있습니까?

부분적으로만 가능합니다. REST는 계약의 일관성(Swagger/OpenAPI)에 의해 정의되지만, 본질적으로 느슨한 형식(JSON/HTTP)과 함께 작동하고, 예를 들어 gRPC는 Protobuf 스키마 덕분에 강력한 정적 유형화를 보장합니다.

어떤 경우에 gRPC를 공개 API에 사용하는 것이 권장되지 않습니까?

gRPC는 브라우저와의 호환성이 떨어지고 HTTP/1.1 인프라(예: 프록시, 방화벽)와 통합이 잘 되지 않습니다. 공개 웹 API에는 REST나 GraphQL이 더 좋습니다.