chore: update title

blog/graphql-schema-2024-07-11.md

@@ -1,5 +1,5 @@
 ---
-title: Design a GraphQL Schema So Good, It'll Make REST APIs Cry
+title: Design a GraphQL Schema So Good, It'll Make REST APIs Cry - Part 1
 authors:
   - name: Amit Singh
     title: Head of Growth and Strategy @ Tailcall

blog/graphql-schema-part-2-1-2024-07-21.mdx

@@ -1,5 +1,5 @@
 ---
-title: Design a GraphQL Schema So Good, It'll Make REST APIs Cry - Part 2.1
+title: Design a GraphQL Schema So Good, It'll Make REST APIs Cry - Part 2
 authors:
   - name: Amit Singh
     title: Head of Growth and Strategy @ Tailcall

blog/graphql-schema-part-2-2-2024-07-22.mdx

@@ -1,5 +1,5 @@
 ---
-title: Design a GraphQL Schema So Good, It'll Make REST APIs Cry - Part 2.2
+title: Design a GraphQL Schema So Good, It'll Make REST APIs Cry - Part 3
 authors:
   - name: Amit Singh
     title: Head of Growth and Strategy @ Tailcall
@@ -24,7 +24,7 @@ In our [previous post](/blog/graphql-schema-part-2-1), we explored how to make a
 
 ## Recap of Additive Changes
 
-In [Part 2.1](/blog/graphql-schema-part-2-1), we discussed the importance of making additive changes to your GraphQL schema to expand its capabilities while maintaining backward compatibility. By adding new fields, types, and arguments, you can enhance your API without causing disruptions to existing clients. We also emphasized the importance of providing transition paths to ensure a smooth adoption process.
+In [Part 2](/blog/graphql-schema-part-2-1), we discussed the importance of making additive changes to your GraphQL schema to expand its capabilities while maintaining backward compatibility. By adding new fields, types, and arguments, you can enhance your API without causing disruptions to existing clients. We also emphasized the importance of providing transition paths to ensure a smooth adoption process.
 
 ### Safe, Dangerous, and Breaking Changes
 

blog/graphql-schema-part-2-3-2024-07-23.mdx

@@ -1,5 +1,5 @@
 ---
-title: Design a GraphQL Schema So Good, It'll Make REST APIs Cry - Part 2.3
+title: Design a GraphQL Schema So Good, It'll Make REST APIs Cry - Part 4
 authors:
   - name: Amit Singh
     title: Head of Growth and Strategy @ Tailcall
@@ -24,9 +24,9 @@ In our [previous post](/blog/graphql-schema-part-2-2), we explored how to modify
 
 ## Recap of Additive Changes and Modifications
 
-In [Part 2.1](/blog/graphql-schema-part-2-1), we focused on additive changes, emphasizing the importance of expanding your schema's capabilities without disrupting existing clients. By adding new fields, types, and arguments, you can enhance your API while maintaining backward compatibility.
+In [Part 2](/blog/graphql-schema-part-2-1), we focused on additive changes, emphasizing the importance of expanding your schema's capabilities without disrupting existing clients. By adding new fields, types, and arguments, you can enhance your API while maintaining backward compatibility.
 
-In [Part 2.2](/blog/graphql-schema-part-2-2), we delved into modifying existing schema elements, discussing how to handle changes such as updating default values, transforming non-null fields to nullable, and changing field types. We highlighted the need for clear communication, providing transition paths, and leveraging schema design tools to minimize client disruptions.
+In [Part 3](/blog/graphql-schema-part-2-2), we delved into modifying existing schema elements, discussing how to handle changes such as updating default values, transforming non-null fields to nullable, and changing field types. We highlighted the need for clear communication, providing transition paths, and leveraging schema design tools to minimize client disruptions.
 
 ### Safe, Dangerous, and Breaking Changes