Data APIs

Table 17-4 Data APIs

Best Practice	What to avoid and why
Request Only What You Need. Leverage the powerful capabilities of Data APIs, such as GraphQL, to precisely request only the data fields your application needs.	By avoiding queries for whole objects or large resources when only specific elements are required, you minimize over-fetching. This targeted approach optimizes bandwidth usage, enhances application performance, and strengthens security by reducing the amount of unnecessary data transmitted.
Use Appropriate Date Inputs. When specifying date parameters in your queries, always strive to avoid open-ended inputs that could result in retrieving excessively large or unbounded datasets. Instead, provide clear, concrete date ranges to narrow the scope of your data requests.	This best practice helps ensure faster query responses, streamlines debugging efforts, and alleviates unnecessary server load—ultimately contributing to a more efficient and reliable application.
Check for Partial Success. If errors occur with specific fields, data API responses may include partial data.	Always inspect the "errors" field in the API response. Implement proper handling for partial successes so that if complete data is unavailable, your application can degrade gracefully — providing users with meaningful feedback and the best possible experience under the circumstances.
Cache Responses. Consider using local or in-memory caching for queries that are performed repeatedly, particularly when working with data that does not change often.	Effective caching strategies can help reduce unnecessary network traffic, decrease latency, and improve your application’s overall performance.
Prevent Server Backpressure Design your API client to avoid generating excessive requests that can overwhelm the server, leading to backpressure or throttling.	If messages are being generated in the server at a pace much higher than the pace of the consumption of the messages, these messages will accumulate in the server’s memory. Too many messages in the server’s memory will result in errors because the memory gets full.
Consolidate Attributes from Similar Views. The complexity of a query increases with the number of views (or data sources) involved.	To optimize performance, always attempt to source required attributes from the same view when practical. For example, retrieve property data from the Primary View rather than mixing it with the Property View, which can introduce unnecessary complexity and potential overhead.
Ensure data mapping is accurate for your needs. Make sure you are fetching the information your business needs. You can use existing documentation for this purpose.	Data APIs are based on Subject Areas. These Subject Areas have a high number of attributes and each of them are mapped to fetch the information from a specific table/column on the database.
Design your GraphQL queries while considering the existing product limits for the Data APIs. Check the OHIP User Guide for details on these limits.	Using queries that consistently exceed product limits will lead to a high error rate, poor user experience, and reduced performance of the solution.
The Subject Areas behind these Data APIs use a star model which means there’s a primary view from where all joins start. Make sure to always include the appropriate filters here.	These Data APIs are essentially generating SQL Queries in the background. If the appropriate filters are not used in the star model, the queries won’t perform as expected increasing the chances of errors.
Create a multi-request API call if you are selecting columns from multiple child folders from a Subject Area. Example: If you need all phone numbers and all addresses of profiles, then create a muti-request call with the same criteria.	This will prevent a cartesian join between Profile, Phones, and Addresses, resulting in more optimal performance. Otherwise, the query would return a row for every combination of profile, phone, and address, instead of only the distinct phones and addresses.
Extract the updated records. For recurring requests where the same query is executed regularly, fetch only the records that have changed since the last time data has been extracted.	Fetching the records that have been updated will avoid extraction of unwanted or duplicate data. This will ensure an effective and scalable extraction process.