In my previous article, I discussed the emergence of Backend as a Service (BaaS) as a solution for the traditional server side stack. Instead of spending months building a backend, mobile and web app developers can now leverage services to help them deliver higher quality apps in less time than ever before. In this post we look at a few of the common features that a BaaS solution brings to the table. We will also show the API endpoints that developers can use to take advantage of these features in their apps.
What do mobile apps need?
In today's competitive...
In the inaugural stop on our API Design Tour, we talked with the Digital River API Team about their approach to API design. The video and slides from our session are here. Below are some more of the design questions we put to the team.
In working with API teams all over the world, a design pattern we've seen work really well is the API Facade Pattern. We touched on the concept in the Web API Design eBook and then in March of this year we explored the API Facade Design Pattern in a bit more depth in a series of short webcasts. We've created a new eBook with the API Facade material that you can download for your favorite e-reader and will hopefully find useful.
In 1995, Clayton Christenson coined the term Disruptive Innovations in his article titled "Disruptive Technologies: Catching the Wave." His contention was that some new products or services that appear in the marketplace are so revolutionary that they render existing technologies obsolete. We are seeing a new example of this phenomenon with the emergence of a sector being referred to as "Backend as a Service"—BaaS. BaaS is replacing the traditional server-side stack as a dependable, feature-rich option for powering mobile and web apps.
Sidelining the competition
Proponents of existing technologies may initially perceive new innovations to be no more than novelties,...
Thanks to all who participated in the inaugural stop on our new API Design Tour series in which Brian Mulloy talked with the Digital River API Team about the approach that Digital River took to designing and implementing their API.
"Cachiness factor" is the degree to which your API design supports the caching of responses. Low cachiness means that a relatively higher than optimal number of requests is forwarded to the back end for retrieving data; a high cachiness factor means that the number of requests serviced through the cache layer is reduced and optimized.
Every time a request is sent to the API provider endpoint, the provider incurs the cost of servicing the request. Investing in a good caching mechanism...
Thanks to all who participated in last week's Webcast, "Skeuomorphs, Databases & Mobile Performance," in which @sramji discussed applying the lessons learned from previous eras' computing models to build better end-user experiences and architect for performance on today's mobile devices.
The video and slides for the session are below. We'd love to continue the discussion on the api-craft forum.