I am curious
about how different teams approach building new features when multiple developers or teams need to be involved in integrating or building a new feature within a product (excluding external service integration)
Interface Agreement approach
One commonly used approach is establishing an "interface agreement" between developers, such as the frontend and backend devs, before building a feature. For instance, before creating a new API or feature, developers come to an agreement on the request/response structure, defining the API interface. This allows them to work independently, without having to wait for the other developer to finish their part before integration.
Issue with this Approach
While this method works well on a smaller scale and is efficient for agreeing on interfaces for a few APIs, it becomes challenging when building an entire product or a feature that spans multiple use cases or APIs. The difficulty arises because it's tough to foresee or visualize how the entire set of interfaces will look upfront.
This challenge is more pronounced in traditional SQL databases, where you typically have a clear understanding of the data type, interface, or data to be retrieved and sent back.
The complexity increases, especially with NoSQL databases, where the stored data can be unstructured, and it might not conform to your expectations. For example, you might assume it should be an array, but, unexpectedly, it turns out to be a string for some reason (unless you are using an ORM or ODM).
The problem intensifies further when using dynamically typed languages like JavaScript, where issues may only become apparent when your frontend starts throwing errors.
Top comments (0)