Andrew Hall


Future of Web Apps – Session 2 – SDK Product Architect – David Zuckerman

When building an ecosystem, what should you consider

Wix are a html 5 generator for small businesses. If you can use PowerPoint, you can use wix. They have 53 million sites and get 45000 users a day and 34000 apps installed per day which amounts to 70 million http requests a day

What is wix?

Wix provide content via iframes to hosted sites.
They also curate all the apps that enter their revenue share market.

Their SDK is made up of JavaScript libraries, rest Apis, web hooks and client libraries for the rest Apis.

They also have a support organisation which contains support people and dev relations teams.

All of this started from one method over 2 years ago. Html 5 was in its infancy and angular didn’t exist. The landscape looked very different. Wix is about making users happy and they have amazing sites. Wix wanted a way to easily integrate with their system.

The first app they thought of was a blog, with navigation. But they had certain challenges

Wix used a custom JavaScript renderers
Wysiwyg editors are fragile.
No idea who their customers would be
Few resources for the product.

If an external application would go down or break, it would ruin their customers experience as their users werent that technical it would take a lot of effort to fix.

The very first method was reportHeightChange.
They used postMessage to send message across iframes (using polyfills where necessary). They also made sure to use framework agnostic code, so as to not force the customers to use a particular framework.

They used iframes for sand boxing. This was done on purpose to only affect the content required. Web components are not standard (and also don’t work in < IE 9) and this still doesn't provide enough sand boxing - one bad app could bring down a site.
Even today there is not a better solution that iframes for their unique needs.

They used JavaScript as a bridge. They used to command pattern to send Json over the wire and is asynchronous. They use callback and not promises. Wix users range from various different skill sets. They need to make sure they use the right technology for their developers

Developer relations is a very important part of building a platform. They did this by getting large customers and gave them direct targeted support and they became the first customers. They did hackathons to encourage developers to use their platform.

Moving forward they need to be clever how to grow their API. In developer experience, they use user stories to target the APIs for the relevant targeted users. They also make use of use cases to make sure they give straight forward solutions and they also check what their competitors do.
They also check directly with their customers if what they provide is helping them to do what they want
Wix also dogfood their solutions internally before rolling them out to customers.

They try to meet standards where possible. Example they use the correct verbs on rest Apis and they use semantic versioning to make sure that the existing apps still work when doing updates.

Post Mortem

This went well:

Wix API is easy
Self hosting means app integrations are painless
Direct product support means amazing apps
We successfully use it internally

But this was bad:

They don’t use OAUTH for signing Apis
Documentation and example code needs to improve
Without forcing a framework, a user might not know which framework to use

If you want to build an SDK:

You must know your audience
Segment users between skill levels
Provide enough support
Be aware of fads

Don’t make developers hate you

Do the hard work for users
Use known concepts – don’t reinvent the wheel
Be consistent
Being pragmatic can lower barriers for entry

Provide top notch support

Build a clear developer centre
Provide sample code and real world examples
Have engineers who can provide support

Leave a comment or tweet me