Manage Learn to apply best practices and optimize your operations.

How many data sources in your apps? Let me count the APIs.

When explaining the concept of cloud computing to friends unfamiliar with it, I usually turn to my imaginary recipe-of-the-day mobile and Web app as an illustrative example. Something that should be seen by users as the very model of simplicity gets very complicated very fast under the hood. It’s enough to make any developer lose his or her appetite. Are your apps doing something similar?

The premise is simple: suggest a daily recipe based on a variety of factors. The genius is blending my ingredient list (multiple data sources) to produce a finished product that’s easy to use, sports a great-looking user interface, and that will entice users to take some revenue-generating action, such as ordering ingredients or cookware online, or subscribing to a magazine.

Data source #1: User info. To get recipes, the user has to sign up, at minimum, with a user name, password, e-mail address, and postal code. The postal code is crucial, because a key function of the app is to suggest recipes based on specific location and weather conditions. That ensures a user in Maine won’t get recipes calling for collard greens, and that users in Phoenix in July won’t get recipes for steaming hot soups. Also, recipes might be sent not only for today, but for several days out, allowing the user to acquire ingredients not on hand.

Data source #2: Weather forecast based on postal code to ensure that a hearty stew, best for a cold, snowy day isn’t sent in the midst of a rare December heatwave. Obtained via API calls from a third-party service, such as Weather Underground.

Data source #3: The app owner’s database of recipes along with photos and links to discussion threads. Maybe links to how-videos also.

Data source #4: Analytics that reveals which recipes are most popular by region and time of year. It’s another ingredient in determining which recipe to suggest.

Data source #5: This could also be fields in the user info database. It includes user preferences — favorite and least-favorite cuisine types, self-rated level of cooking expertise, food allergies, how often to suggest a recipe, ingredients to avoid (George H.W. Bush famously hated broccoli), etc. Capture family birthdates, and the app could suggest birthday cake recipes and gifts 10 days in advance.

Data source #6: Current and future farm-fresh ingredients availability by location. It’s no good to suggest a recipe calling for fresh cranberries if they’re out of season. Another API call to somewhere.

Data source #7: Coupon codes and other promotional enticements for purchasing non-perishable ingredients and cookware through the application.

Data source #8: Pricing comparisons at local supermarkets for meats and veggies, likely extracted via APIs from a service that collects this type of data.

Data source #9: If the user makes a purchase, multiple data sources come into play for credit-card processing, shipping address, shipment tracking, and so on.

Data source #10: History database of user actions, including which recipes were viewed, saved, printed, rated, and commented on. What items did the user purchase? Re-display a favorite recipe a year later? What other recipes did the user seek and display? Analytics could prevent five straight days of soups, even though the weather outside is frightful and might suggest that.

In addition, there might also be integration opportunities via APIs with retail sponsors: if you’re making clam chowder and the weather is snowy, can we suggest the following cold-weather apparel items, or winter sporting goods, or vacation trips to a tropical resort?

After all this comes the matter of designing and building an application that looks great, presents all the aforementioned data as a completely seamless experience, and performs blazingly fast.

The point here is that nothing is simple. The specs for this app would be complicated. And, it takes a huge amount of talent to build an app that users enjoy and look forward to using repeatedly.

Are you building cloud and mobile apps that integrate data from a large number of sources? What’s your data mashup process and how do ensure stellar performance? Teach us how you solved these problems; we’d like to hear from you.

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Great article Mr. Shore, I'm currently working on becoming an app developer myself, and this article made understanding multiple data sources and their uses much easier. Keep up the great work!

Ryan M
Cancel
Good article showing how all aspects of the design should be considered. It's best to plan your data sources ahead of the actual coding. Trying to retro fit a new data source or database to an existing application may not be an easy task. Your example might be a little extreme for most people but you cover just about any variation of a recipe search.
Cancel

-ADS BY GOOGLE

SearchAWS

TheServerSide

SearchFinancialApplications

SearchBusinessAnalytics

SearchCRM

SearchSalesforce

Close