9. • JSON / REST / Small Payloads
• Documentation / Testability
• Clarity
• Security
Prolific Interactive
What do we want from our
APIs?
10. • Synchronize models between platforms
– Keep engineers from implementing in silos
– Establish a common vocabulary
• Developed open-sourced framework that
meets our requirements easily
Prolific Interactive
How did we get these?
13. • No view
• PHP Based
• Mongodb backed
• Automated iodocs documentation
• Exports to mobile models
• Packaged testing framework
Prolific Interactive
MABI Framework
14. • Auto-generate as much as possible, but give
control
– REST Controllers
– Documentation
– iOS/JS/Android Models
• Mongodb documents represent Objects
Prolific Interactive
Quick Setup
17. class Recipe extends MABIModel {
/**
* Unique identifier for the recipe.
*
* @var string
* @field id
*/
public $recipeId;
/**
* The average rating for this recipe across all
users
*
* @var float
*/
public $averageRating;
/**
* @var Food[]
*/
public $foods;
/**
* The rating that the app needs to receive. Only
* filled for the current user
*
* @field external
* @var int
*/
public $myRating;
/**
* All of the ratings for this recipe for all users
*
* @field internal
* @var array
*/
public $ratings;
@var specifies the type
Core string and float examples
Automatically loads Food class (another
Model)
@field annotations add extra field-specific
functions
'external' means that the value is only
output by the API but not stored anywhere
'internal' means that the value is stored
and used by the server but not output by the
API
Prolific Interactive
21. /**
* The stats methods contain general aggregate
* numbers for recipes, foods, etc.
*
* @middleware MABIMiddlewareSharedSecret
* @middleware MABIMiddlewareAPIApplicationOnlyAccess
*/
class StatsController extends MABIController {
...
public function getMealCount() {
...
}
public function postNewStat() {
...
}
...
}
Serves GET /stats/mealcount
Defines middleware that
restricts access to anything
in the controller to registered
Applications
Serves POST /stats/newstat
Prolific Interactive
22. /**
* @docs show-model
*
* Contains the endpoints to get detailed information about a certain recipe, and
also perform actions on it (e.g.
* rate it).
*
* @middleware MABIMiddlewareSharedSecret
* @middleware MABIMiddlewareAPIApplicationOnlyAccess
* @middleware MABIRESTAccessReadOnly
* @middleware MABIIdentityMiddlewareSessionHeader
* @middleware MABIIdentityMiddlewareRESTOwnerOnlyAccess
*/
class RecipeController extends MABIRESTModelController {
...
/**
* Updates the rating that the user gave this recipe using the users's id. If the
user has
* not rated the recipe before, it will add a new rating.
*
* @docs-param rating int body required Should pass in the user's rating for the
Recipe. Must be an integer from 1 to 5.
*/
public function restPostRated() {
...
$this->model->ratings[$userModel->userId] = $rating;
...
}
...
}
Restricts access to only the
read endpoints that can read
objects or collections
Serves POST /recipes/<id>/rated
$this->model is already loaded with a
Recipe Model based on its id
Prolific Interactive
Restricts access to only
logged in users that own
the resource
27. • Automatic setup from Mobile to Server
• Continue adding mobile specific extensions (in-app
purchasing, passbook, etc.)
• Other basic framework features
Prolific Interactive
Future
28. Summary
Don’t take communication for granted
Drive data definitions across your product
Get things up quickly so everyone can work
Fine-tune your API specifically for mobile
Prolific Interactive
Can usually be found doingrandom things at happy hourslike dressing up as a 50slifeguard and riding fake blow-up sharks
Want to give a little bit of a background of what we do, and how we’ve reached these issuesMobile Products AgencyDevelop highly functional mobile apps for large clientsRent the RunwayLululemonAs well as startups through our acceleratorFrom the ground up including backend and also lone mobile apps
Apps vsproducts -products are a subset of apps that involve a whole ecosystemUser experience isn’t always just UI, a lot of it is the data and integrations that back itMeet long-term business and user goalsHow do we as engineersdo this?
CreativityWouldn’t be in business without hiring creative individualsQualityWhat clients expectMakes communication easierCommunicationMany people working on complex thingsThe quality/comm combo is what is always tricky.We need to get this right for all of our apps/customers.There are so many mature web practices right now to handle this, but mobile is still pretty fresh in this type of management
These platforms aren’t just a little different/buggy, they’re completely different paradigmsDesigners “should” even redo the design based on how different these areIt seems that the backing API is what is actually the most flexibleI see it as the opportunity to set clear definitions across all of our platformsOne way people are solving this problem is with BAAS solutions
Basically, if you don’t want to/can’t do ANY backend development, this is a good way to go.Not so great if you want to control your product in the long-termThese cons don’t work for us. We want:OwnershipEnvironment FlexibilityFine-tuningWe want full ownership of our code and process. So, we broke down what the most important parts of an API were to our developers and found:
JSON/rest – small packagesBased on nightmare stories from customers and personal preferences we found some common denominators
Why not MVC Frameworks?Views muddy up cleanliness of modelsMake mobile standards easier to implement (throw out things like cookies, html, javascript, etc.)My job is to care about making these things workThe quality and communication mix was handled in a lot of different ways in the past.We know that within an organization having everyone speaking the same language, vocabulary, programming the same way is the best way to do this
No viewModels act like views (different amounts of data)Controllers are strictly endpoint-basedThere will always be massaging to match UI and organize packagesPHP BasedClear OO“Strongly” typedAnnotation Driven shortcutsTransitioning from MVC Frameworks is easyMongodb backedMongodb’s documents are very compatible with how we view useful mobile models look likeWorking on other data sourcesiodocs documentation creationPackaged testing frameworkIn order to quickly set up
This makes us able to get a usable version of the API in minutes. Then the team can smoothly build out the backend as the front end refines the UI
Keep everything overridableMiddlewareSince this framework is communication and process related, middleware plugins are quite usefulSecurity/Access/AuthenticationExtensionsBundle up large portions of functionality including controllers and modelsUsed for things like authentication schemes, email providers, push notification providers, etc.
Admin UisCan be plugged in directly through a database or via the api or split the controllersComplex integrationsLink can be as deep or as shallow as we want itAlternative Data SourcesGlenlivet
More database backingSupport other documentation/testing frameworksJSONP for mobile webCaching/PerformancePartial Model LoadsStrengthen CLI Interface
JSON/rest – small packagesBased on nightmare stories from customers and personal preferences we found some common denominators
