If you’re using seevl for YouTube and Deezer, or watched our introduction video, you’d understand our cross-platform music discovery experience. Yet, building on multiple platforms has multiple engineering constrains. You need to use several APIs and toolkits to deal with, manage user authentications on different places, etc. To overcome this challenge, we’ve decided to build a platform, not a website or an app.
A website or a platform?
When building solely a website or an app, your thoughts are based on a closed-minded process: a particular market, a particular device, and/or a particular user-interface. That’s a perfect start, but it restricts your vision and ability to scale or adapt quickly – different market, device, etc.
Building a platform provides much more flexibility. You’re building a core infrastructure, and website and apps act as front-ends on top of it.
Let’s take our search feature as a use-case, available both on YouTube (search for a genre in YouTube search box once you’ve installed the plug-in) or Deezer. Nothing happens on the front-end. Those are just empty shells, sending queries to and parsing results from our cloud-based infrastructure. If we add additional search options, we’ll build them once in the platform, and slightly change the front-ends.
You’ll need some REST
To make the front-ends interact with the platform simply use the best thing since slice bread, the Web. In particular, HTTP and REST. When building browsing apps (e.g. listing artist discographies), read-only operations (GET) are enough. Going further, use DELETE, POST and PUT to update data though the front-ends. This is what happens when you follow someone on seevl, and what makes it instantaneously available on YouTube and Deezer.
Another immediate benefit: all your data and actions are stored remotely and are automatically sync-ed between your apps. Are you when Twitter or Skype notifications appear on your phone while you’ve read messages on your laptop? Well, that doesn’t happen with a “store-everything-in-the-platform” approach.
APIs. APIs. APIs.
Of course, you need to organise those interactions, and the best thing to do is to define your own API. Start with a set of URIs and patterns, for instance
GET /user/likes HTTP/1.1
to get the list artists that a user like, or
PUT /user/likes/foobar HTTP/1.1
to add “foobar” as a favorite artist in the users’ library.
Combine this with a standard schema for replies, and you’ve defined the first steps of the API that will let you communicate between your platform and your apps. To make things easier, you can implement your SDK to let your development team interact quickly with it. Obviously, take care of backwards compatibility – or stuff will miserably break.
In seevl‘s case, we’ve defined a simple URI scheme for all our methods. JSON-LD has been our preferred format for a while, and we’re happy to see it getting more traction with its integration in Gmail and schema.org. Our API and JSON-LD act as a layer between our graph database, redis and solr and our front-ends. Ultimately, complex queries are hidden behind simple URIs, as discussed at a past L.A. SemWeb meet-up.
Another benefit of having an internal API: if you open your data to partners or new customers, the infrastructure is already in place. Need authentication and metrics? Let 3scale, mashery or other API providers handle this for you.
Reducing costs: hosting and development
Last but not least: costs. By having all your logic and computation requirements on the cloud, websites or apps are just HTML and JS files. You can host them as static AWS S3 websites instead of having a full-stack server – largely reducing operating costs.
In addition, front-end and back-end developers will work on separate code-bases as long as they follow the API guidelines you’ve defined earlier. This is obviously not a new concept, and others like Amazon are using a similar approach to manage project integration. Yet, it’s relevant to consider it from day-1, as we’ve done, to keep as much flexibility as possible in your product roadmap.
That being said, here are two things we’ll discuss next:
- First, the challenge of mobile, and how to handle this in your platform with Responsive Design – an approach we’ve taken with our seevl for Deezer.
- That, how to bring your platform to another abstraction layer, and make it domain-independent – building re-usable components that would work whatever your domain area is.
Stay tuned, and don’t forget: the Web is the platform.