From f13ba12caabb0f0873af04ef35a10c4b686f7ca2 Mon Sep 17 00:00:00 2001 From: Simone Di Maulo Date: Thu, 21 Nov 2024 23:02:23 +0100 Subject: [PATCH] Fixes typo --- content/posts/microservice-architecture-api-maturity.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/microservice-architecture-api-maturity.md b/content/posts/microservice-architecture-api-maturity.md index c2682e1..6fff552 100644 --- a/content/posts/microservice-architecture-api-maturity.md +++ b/content/posts/microservice-architecture-api-maturity.md @@ -88,7 +88,7 @@ At this stage, the team starts using strict API contracts. They will use standar Implementing a strict API contract is not free of overhead, especially for brownfield projects. Adopting a formal API definition on legacy projects requires some work. The team must write all the specs for the currently implemented API, that can be a very long work if they have a large API surface. -To mitigate that and start adopting best practices, They can also choose to start writing specs for new implementations and then then fill in the old API definition over time. +To mitigate that and start adopting best practices, They can also choose to start writing specs for new implementations and then fill in the old API definition over time. On the other hand, adopting a contract-first approach to a new project can have some overhead too, but it has also some nice side effects and the benefits far outweigh the cost. Having an API contract: