![How categories work in commercetools platform
[
{
// root category
"id": "1",
"key": "shoes",
"parent": null,
"ancestors": []
},
{
// subcategory of `shoes`
"id": "2",
"key": "sport-shoes",
"parent": { "id": "1", "typeId": "category" },
"ancestors": [{ "id": "1", "typeId": "category" }]
}
]](https://image.slidesharecdn.com/graphqlmeetup1-howweusegraphqlatcommercetools-170721085004/85/GraphQL-Munich-Meetup-1-How-We-Use-GraphQL-At-Commercetools-16-320.jpg)
GraphQL Munich Meetup #1 - How We Use GraphQL At Commercetools
- 1. { name web role company } type User { id: String! name: String! web: Web! role: Role! company: String! } { “name”: “Nicola Molinari”, “web”: { “twitter”: “emmenko”, “github”: “emmenko”, }, “role”: “SOFTWARE_ENGINEER”, “company”: “commercetools” } ⇒ ⇒
- 2. We should share more brown field examples.
- 3. How We Use GraphQL At Commercetools
- 5. React Europe 2015 Release of GraphQL Spec
- 6. Oleg Reading the GraphQL Spec ‘till late that night.
- 7. From there was born http://sangria-graphql.org/ Scala GraphQL implementation
- 10. UI Application To manage the data in the platform. UI Application To manage the data in the platform.
- 11. UI Application To manage the data in the platform. UI Application To manage the data in the platform. ● Powered by React ● Designed to be User Friendly ● Focus on Enterprise Features
- 12. Nowadays building good UI Applications is hard. >> JavaScript Fatigue
- 13. https://code-cartoons.com - Lin Clark Data Fetching: underfetching / overfetching
- 14. Experience #1
- 15. Feature User can see and explore a category tree.
- 16. How categories work in commercetools platform [ { // root category "id": "1", "key": "shoes", "parent": null, "ancestors": [] }, { // subcategory of `shoes` "id": "2", "key": "sport-shoes", "parent": { "id": "1", "typeId": "category" }, "ancestors": [{ "id": "1", "typeId": "category" }] } ]
- 17. Fetching categories with their children (REST API) `parent = null` (root categories) `parent = “1”` (subcategories of “1”) id: “1” `parent = “2”` (subcategories of “2”) id: “2” 3 requests
- 18. User can see and explore a category tree, and see the number of subcategories and the number of products assigned to the category. (new) Feature
- 19. Fetching categories, # of subcategories, # of products `parent = null` (root categories) `parent = “1”` (subcategories of “1”) id: “1” `parent = “2”` (subcategories of “2”) id: “2” 2n+1 requests # sub. # prod. 0..n 0..n # sub. # prod. 0..n 0..n
- 20. “2n + 1” problem
- 21. > 100 requests in a project with an average number of categories
- 23. { categories(parent: “1”) { id childCount productCount children { id childCount productCount } } }
- 25. We were able to solve a big problem with a small effort.
- 26. What if we would build it with REST?
- 27. What if we would build it with REST? ● Build a new endpoint with the extra fields
- 28. What if we would build it with REST? ● Build a new endpoint with the extra fields Increase maintenance
- 29. What if we would build it with REST? ● Build a new endpoint with the extra fields Increase maintenance It’s a public API, but just for one case
- 30. What if we would build it with REST? ● Build a new endpoint with the extra fields Increase maintenance It’s a public API, but just for one case ● Add the extra fields to the existing endpoint
- 31. What if we would build it with REST? ● Build a new endpoint with the extra fields Increase maintenance It’s a public API, but just for one case ● Add the extra fields to the existing endpoint Possibly a huge performance hit
- 32. What if we would build it with REST? ● Build a new endpoint with the extra fields Increase maintenance It’s a public API, but just for one case ● Add the extra fields to the existing endpoint Possibly a huge performance hit There were not enough use cases to justify a change in the API
- 33. With GraphQL
- 34. With GraphQL ● Easy to extend the schema
- 35. With GraphQL ● Easy to extend the schema ● Does not affect maintainability (only 1 API / endpoint)
- 36. With GraphQL ● Easy to extend the schema ● Does not affect maintainability (only 1 API / endpoint) ● Performance hit on a field level, only when requested
- 37. Extend the existing API without affecting its performance.
- 38. Enable optimizations on a field level.
- 39. Experience #2
- 40. Client HTTP API /user /projects /organizations /project-settings Bootstrapping the client application
- 42. Problems
- 43. Problems ● Data was not normalized
- 44. Problems ● Data was not normalized ● > 50% of the data was never used
- 45. Problems ● Data was not normalized ● > 50% of the data was never used ● Complicated business logic, hard to follow and understand
- 46. Problems ● Data was not normalized ● > 50% of the data was never used ● Complicated business logic, hard to follow and understand ● We had some crucial bugs related to that logic
- 47. Feature Show a list of user permissions.
- 48. Technical Refactoring + User Story
- 49. Don’t work on Tech Debts alone. Instead always include them in a User Story if they bring User Value.
- 50. Technical Requirements for the Refactoring
- 51. Technical Requirements for the Refactoring ● Reduce the number of network requests to one when bootstrapping the application
- 52. Technical Requirements for the Refactoring ● Reduce the number of network requests to one when bootstrapping the application ● The client should only get the data that is asking for
- 53. Technical Requirements for the Refactoring ● Reduce the number of network requests to one when bootstrapping the application ● The client should only get the data that is asking for ● Reduce the complexity of the business logic
- 54. Technical Requirements for the Refactoring ● Reduce the number of network requests to one when bootstrapping the application ● The client should only get the data that is asking for ● Reduce the complexity of the business logic ● Have normalized data + caching
- 55. Technical Requirements for the Refactoring ● Reduce the number of network requests to one when bootstrapping the application ● The client should only get the data that is asking for ● Reduce the complexity of the business logic ● Have normalized data + caching ● Being able to easily extend the model / schema
- 56. Technical Requirements for the Refactoring ● Reduce the number of network requests to one when bootstrapping the application ● The client should only get the data that is asking for ● Reduce the complexity of the business logic ● Have normalized data + caching ● Being able to easily extend the model / schema ● Make it easier to gather metrics
- 58. Client HTTP API /user /projects /organizations /project-settings Create the GraphQL schema first
- 59. Client HTTP API /user /projects /organizations /project-settings Deploy the new endpoint alongside the existing APIs /graphql
- 60. Client HTTP API /user /projects /organizations /project-settings Migrate the client to use Apollo /graphql
- 61. Client HTTP API /user /projects /organizations /project-settings (optional) Remove the old APIs /graphql
- 62. Incrementally migrate your APIs into a GraphQL endpoint.
- 63. Technical Requirements for the Refactoring ● Reduce the number of network requests to one when bootstrapping the application ● The client should only get the data that is asking for ● Reduce the complexity of the business logic ● Have normalized data + caching ● Being able to easily extend the model / schema ● Make it easier to gather metrics
- 64. Technical Requirements for the Refactoring ✅ Reduce the number of network requests to one when bootstrapping the application ● The client should only get the data that is asking for ● Reduce the complexity of the business logic ● Have normalized data + caching ● Being able to easily extend the model / schema ● Make it easier to gather metrics
- 65. Technical Requirements for the Refactoring ✅ Reduce the number of network requests to one when bootstrapping the application ✅ The client should only get the data that is asking for ● Reduce the complexity of the business logic ● Have normalized data + caching ● Being able to easily extend the model / schema ● Make it easier to gather metrics
- 66. Technical Requirements for the Refactoring ✅ Reduce the number of network requests to one when bootstrapping the application ✅ The client should only get the data that is asking for ✅ Reduce the complexity of the business logic ● Have normalized data + caching ● Being able to easily extend the model / schema ● Make it easier to gather metrics
- 67. Technical Requirements for the Refactoring ✅ Reduce the number of network requests to one when bootstrapping the application ✅ The client should only get the data that is asking for ✅ Reduce the complexity of the business logic ✅ Have normalized data + caching ● Being able to easily extend the model / schema ● Make it easier to gather metrics
- 68. Technical Requirements for the Refactoring ✅ Reduce the number of network requests to one when bootstrapping the application ✅ The client should only get the data that is asking for ✅ Reduce the complexity of the business logic ✅ Have normalized data + caching ✅ Being able to easily extend the model / schema ● Make it easier to gather metrics
- 69. Technical Requirements for the Refactoring ✅ Reduce the number of network requests to one when bootstrapping the application ✅ The client should only get the data that is asking for ✅ Reduce the complexity of the business logic ✅ Have normalized data + caching ✅ Being able to easily extend the model / schema ✅ Make it easier to gather metrics
- 70. Client HTTP API /user /projects /organizations /project-settings GraphQL Metrics with Apollo Optics /graphql
- 73. Next steps: optimize queries slow queriesfast queries
- 77. Our Learnings
- 78. Our Learnings ● Incrementally adopt GraphQL to your existing API
- 79. Our Learnings ● Incrementally adopt GraphQL to your existing API ● Incrementally adopt tools like Apollo / Relay next to your code, to reduce boilerplate code and complexity
- 80. Our Learnings ● Incrementally adopt GraphQL to your existing API ● Incrementally adopt tools like Apollo / Relay next to your code, to reduce boilerplate code and complexity ● GraphQL allows to easily extend your API with small effort
- 81. Our Learnings ● Incrementally adopt GraphQL to your existing API ● Incrementally adopt tools like Apollo / Relay next to your code, to reduce boilerplate code and complexity ● GraphQL allows to easily extend your API with small effort ● Performance hits are on a field level, only when requested
- 82. Our Learnings ● Incrementally adopt GraphQL to your existing API ● Incrementally adopt tools like Apollo / Relay next to your code, to reduce boilerplate code and complexity ● GraphQL allows to easily extend your API with small effort ● Performance hits are on a field level, only when requested ● Easy to identify bottlenecks on specific fields and to optimize those