In the fast-paced world of application development, efficiency and collaboration are key to delivering high-quality products on time. At Santry, we’re taking a design-first approach to API development, leveraging mock servers to power parallel development of our mobile application and backend infrastructure. This method allows us to optimize workflows, reduce bottlenecks, and ensure a seamless integration between the frontend and backend of our application.
Here’s how we’re using design-first development to build Santry, a food inventory and recipe suggestion application, and why this approach is a game-changer for modern app development.
What Is Design-First Development?
Traditionally, in code-first development, APIs are built after the backend is developed, leaving frontend teams waiting for backend functionality to be completed. This can lead to delays and miscommunication between teams.
Design-first development, on the other hand, flips the process. It starts with designing the API contract—a detailed specification of all endpoints, schemas, and data flows. This API design becomes the single source of truth for both frontend and backend teams.
Benefits of Design-First Development:
- Parallel Development: Frontend and backend teams can work simultaneously using a shared API contract.
- Clear Communication: API specifications act as a blueprint, reducing misunderstandings.
- Early Feedback: Mock servers allow teams to test and validate API functionality before backend implementation begins.
- Faster Iterations: Changes to the API design can be iterated quickly without affecting backend code.
At Santry, we’ve adopted this approach to streamline the development of our Santry API.
How Santry Uses Design-First Development
The Santry API is the foundation of our mobile app, powering features like food inventory management, recipe suggestions, and notifications. To ensure a smooth development process, we follow these steps:
Step 1: API Design with OpenAPI Specification
We use the OpenAPI Specification (OAS) to design our API. This includes defining:
- Endpoints (e.g.,
/users,/inventory,/recipes) - Request and response schemas (e.g.,
User,FoodItem,Recipe) - Authentication methods (e.g., JWT via Firebase Authentication)
- Query parameters for filtering and sorting
- Error handling and response codes
The result is a detailed API contract that acts as a single source of truth for our teams.
Step 2: Mock Server for API Simulation
With the API design complete, we use a mock server to simulate the Santry API. The mock server:
- Mimics API responses based on the OpenAPI specification.
- Returns realistic data for endpoints (e.g., food item details, recipe suggestions).
- Handles query parameters (e.g., filtering food items by expiry date).
- Supports error responses for testing edge cases (e.g.,
401 Unauthorizedor404 Not Found).
This allows both frontend and backend teams to develop and test their components without waiting for the other.
Step 3: Parallel Development
- Frontend Team: The mobile app team uses the mock server to integrate API calls and test features like inventory management and recipe suggestions. For example, they can retrieve mock food items from
/inventoryor generate fake recipes from/recipes/suggestionswithout requiring a live backend. - Backend Team: Meanwhile, the backend team focuses on implementing the actual API logic, database interactions, and business rules. They can work independently, knowing the API contract will remain consistent.
Both teams stay aligned by referring to the shared OpenAPI documentation.
Step 4: Validation and Integration
Once the backend implementation is complete, we replace the mock server with the live API. By this stage:
- The frontend is already fully integrated with the mock API, so switching to the live API involves minimal changes.
- The backend is thoroughly tested against the API contract, ensuring compliance with the agreed design.