Build a platform, not a website nor an app

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.

Building seevl as a platform

Building seevl as a platform

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.

Sounds complicated? It’s not. There are lots of toolkits like AngularJS or Backbone.js making these interactions easier.

AngularJS - A powerful JS framework to interact with remote backends

A powerful JS framework to interact with remote backends

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.

 

Make sure your API changes are backward compatible, he's watching!

Make sure your API changes are backward compatible, he’s watching!

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.

What’s next?

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.

 

Co-founder of seevl. Love music, love data. Follow me on Twitter @terraces.

Tagged with: , , , , , , , , , , , , , , , , , , , , , ,
Posted in Engineering, Products
  • Gary Murphy

    You are certainly on the right track. I would describe your approach as having a good underlying architecture instead of the term “platform.” A good architecture has the right number of abstraction layers at the right places.

    Since REST is a state-transfer, the URLs should refer to “things” not “actions.” It is hard for us procedurally-minded programmers to change that, but

    PUT /music/preference

    is better than

    PUT /music/prefers

    because you are creating a thing (a preference relationship) not invoking an action.

    • http://seevl.net/ Alexandre Passant

      Hi Gary,

      That’s a good point re. the architecture vs platform. I tend to see the architecture as the abstraction layer, and the platform as its instantiation.

      I totally agree with your point re. things vs actions. We’re using “likes” as in “FB like” objects, not as a the “like” action. But the term is probably mis-leading in the example.

      Thanks for the feedback!

  • Pingback: exemples de réseaux sociaux | Pearltrees