 OK, so we're going to continue with our next session, which is by Avinash, who, in fact, is going to talk about something which was brought up during the last talk about designing things that we don't often think about as designers or don't think about as needing design, about APIs and how you can improve the experience for when you think about users, developers are equally users. So he's going to be talking about designing your API and improving the experience for developers. So Avinash works at Support Me, and he's going to take it forward. Before that, I just wanted to ask all of you, if you have a telephone, I mean, all of us have telephones. Could you put it on silent? And if you do have to take a call, if you could go outside, that's great, because it is pretty distracting for any of the speakers and people around you. Also, there are muffins. And Swissnext, who has helped us with travel sponsorships, arranged muffins for us. So make sure you grab some during the next break if you haven't already. They are either here, or they will be, or there are muffins. The muffins are not a lie. Hey, guys. I am Avinash, and I tweeted Avishas3. I work at Support Me, which has helped us solution, which we have been doing it for two years. Most of the things which I talk during this presentation is what I've learned here, building this product. And because it's very API-centric and dev-driven. So the thing which I will be talking on is developer experience of a web API. The question is, what is developer experience? And the second is, why should we be talking about that? So if you take web applications of today's age, obviously, for the last yesterday and today, you guys have been talking about user experience, because users are the consumers of your web applications, or it might be mobile applications. But in the world of interconnected web, there is a domain where your application is consumed by other applications. So to make this happen, who is making this happen? It is the developer. And how they do it? Using the APIs, which you guys expose for them to develop on. So it's actually very difficult to do developer experience. Because when you consider user experience, you are dealing with minimum emotions. A user is happy or consumed or, as someone said yesterday, anxious. And finally, if he can't figure out what to do, he'll close the site. That's it. But developer doesn't have that choice. His boss would have said, OK, you need to integrate this to the site. So he has to somehow figure out how to make it work. So a developer, as even I, go through a lot of emotions before we end up with what we want. Even we go through all the emotions which Ben showcased yesterday on the stage in front of a computer. So it's really, you cannot satisfy all developers. But you can do things so that they use minimum of these emotions. So let's first look at what you can do with the API itself. The first thing you have to do is embrace JSON. Because that's the future. That's not the future. It's already here. But we see applications still using XML. Pivotal tracker, which is supposed to be done in 2009. Evernote, which is, again, to the post 2005 company, everyone still uses XML. So whenever I see XML, it's like looking at this. So I cringe. Immediately as designers, when they see this, they cringe. So when I look at XML, I also get the same reaction. So I don't want XML. So to give you an example, XML is great if you are just extracting data from the web server or from the web service. But if you want to do something or put something in, like create a record or something like that, XML is a problem. One, as you can see, it's heavy. The second, if you see the name tag, it has hello tags. So that tags will screw up your XML format, because it's an invalid XML. And your API will just fail. So there is an extra step which the developer has to take to make this work. He has to sanitize the content, which is put between the name tags. We are all developers. We like to hack. We love to hack. So it might seem it's, oh, I have to call one more method to get this done. But we love to hack when we are free. But when someone says, do this, we want to complete it as quickly as possible and get back to hacking. So you have to make sure that that's possible. So if you see the JSON representation of this, it's pretty simple. It's light. There is no invalid XML or anything. Even if your application requires XML, for example, Evernote, you have to provide a, if you want to create a note, you have to provide an XML or Evernote ML or something like that to create a note. Even then, what they could have done is encapsulate it in a JSON to make the developer experience better. You don't want to use Evernote API if anyone is inclined to use ready for all the emotions which I showed. The second thing is we all use, most of the APIs today are REST, but they are not actually REST. They are less REST-like. Rails and other MVC format frameworks have made it easy for us to go the REST way. But REST is not REST until there is hypermedia. So what you have to consider is the client which consumes your API is like an user. When a user lands up on your application, you have links for him to do something else, like maybe edit something, edit the user profile, create a new user profile. But when you send a JSON, you send only the data. It should also have actions in it. It should also have links in it so that the client knows what to do, where to go when it needs to do something. So this part of REST is called hypermedia. And REST is not REST unless there is hypermedia. So initially, it doesn't make sense to put these. But as you go along the road which I'll be taking you now, this is an important thing. The next thing is this is same as all you user experience guys have been saying. But just apply to the APIs. Make sure the error handling is right. So how do you do error handling in web API services? Use HTTP status codes. It is there for a reason. When it's 500, it's server error. Don't send HTTP code as 1. I've seen people sending HTTP code as 1, 2, 3, 4, or whatever the whims and fancies they have. So use the error handling properly and always attach a message to the status which you are sending. And don't expose the implementation level, maybe a huge stack trace or something like that in your API. Keep your API structure throughout its lifetime stable. If someone is developing using Facebook, how many people think Facebook has a stable API? So they keep on changing. And they put restrictions that if you don't change your API structure by October 30th, your apps will fail. So the simple technique of how to attain stable API is start small. If you have read Reverb, which is a book from Jason Freyd and David Hammer Hansen, they say that when you build a product, when you design a product, don't add features. Every time you want to add a feature, say no to it 10 times. And finally, if it makes sense, then say yes to it. So it's the same kind of philosophy which can be applied to APIs too. So if you want to add a data field into the API, ask it's really required. So when you start off small and go through the journey of building the API, making it more and more complex, you are just adding stuff. You are never removing stuff. So versioning of your APIs and everything becomes very easy. So that's just what you can do with your API structure and the APIs to the core. So but you can do stuff around your APIs to make your developer experience better. You can create wrappers for different languages, Ruby, PHP, Python. For if I can give you an example where this is not considered a good practice, or people who consider this not a good practice, the people at Mailgun say that, oh, everything is a REST API. Use the REST libraries will never write wrappers for you guys. But when it comes to developer experience, its wrappers is a must. This came up in the last talk, interactive docs or how to create docs for APIs so it's usable, actually. It's not just a dump of whatever your API endpoints are. This, a very good example for this is Stripe. Their documentation is, from what I have seen, is complete. So what they do is they have the code and the documentation side by side, which is annotated code, which is pretty famous in this. And they show documentation in every language. It can basically, Ruby, Python. Also, they customize the code to your account. So if you see that Stripe.API key, that API key is your account. So you can copy paste this and write out as quickly as possible. You don't have to copy this or change the key or do something. You just copy paste this, it works. So I don't know any open source projects which give you, give this kind of a documentation. If there is, please let me know. We want it. So this is what you can do with an API. And around an API, you can build tools which will help you better the developer experience. But you can go beyond the API. The first thing is Webhooks. Support Webhooks if you are a web application. So if you are providing just the API, people have to poll your API maybe in 10 seconds, one minute, depending upon what periods they want. But if it's Webhooks, you are actually pushing data to them whenever events happen in your system. So they don't have to sit and poll every time if something is happening or not, to check if something is happening or not. Again, a very good example is Stripe. Stripe has a lot of Webhooks for all payment events which happen in its system. So you can handle it, for example, invoice paid. So when invoice paid is fired, you can send an invoice to your customer because they don't. The next improvement which you can make is ready-made widgets. The best example for this is what Witter has done recently. Embedded timelines, intents were there since a long time. Intents abstract the code which you have to write to get something done. Say if they have exposed an API to do Retweet, you have to actually call Retweet to do the action. But with intents it's just a URL. They take care of everything. So you don't have to do anything. So the next step to go is something like Zapier. So what Zapier has done is it is exposing your API to consumers so that they don't have to go through the pain of actually looking at your documentation. So if you integrate your application with Zapier, it can integrate your application with other applications if someone wants it. So now there is an API which is perfect. Then you have created stuff on that to make it easily embeddable or usable. But if you want to write an API or if you want people to build on your product, extend features on your product, you need an app platform. So to start off, an app platform exposes data plus UI. So an API just exposes data which you can then do actions on it. App platform exposes UI too. For example, if you take Shopify, Shopify apps will let you hook up UI elements in different pages of the store. So that you can add UI on that. This is same as how WordPress allows you to add hooks and add capabilities at different pages. The next step is OK. So the main problem with app platform is you have to host your whatever the app yourself. You have to host it somewhere, link it to the site and everything. So it's a pain. So to take it one step, you need a hosted app platform. So from what I have experienced, the first people who actually did this was GitHub. GitHub have something called service hooks, which allows you to connect to other applications. But these service hooks are hosted by GitHub itself, but written by others. So how do they achieve this? They have a GitHub repo, open source GitHub repo, which you can fork, add some code. Say if you want to integrate your own application, add an app. They have a documentation and everything. And send a pull request. They will review the code and deploy it. And it will start appearing here. You don't have to worry about hosting or anything. You're making developer experience more and more easy. So we at support, we took this one step ahead. GitHub services are primarily used to connect to other services. But we wanted our developers to extend our features, because our core features are minimal. We have kept it that way because 80% of you, we cover the 85% of the use case and 20% of the use case of our customers are different to each customer. So we didn't want to write those apps. So we wanted to release that as a platform. And others, you can make others write that app. For example, this is a camfire application in support B. This whenever a ticket is created, it will send a ping to camfire if you're using camfire as your group chat. It's just 30 lines of code. If you write 30 lines, you have an app which is running on live production for support B. If you, these four lines of code will generate the settings page for this will be exposed to the user when they add the app to their platform help desk in support B. Just by writing four lines of code, you have a whole screen setup. You don't have to worry about HTML, CSS, showing the screen, nothing. And by writing this one line that is notified ticket for an event ticket created, or actually this is the app logic, that's it. You are only creating, you are writing only one line or max of 10 lines of code. So why is it so easy to write an app in such a hosted app platform solution? One is you don't have to do authentication logic. Most of the time when you consume an API, you waste a chunk of time in setting up authentication. When we accept, when someone adds an app to support B, we accept on behalf of whom the app can access the application and we set it up for you when, for you in usage in your app platform code. So if we support OR2, if you say OR GitHub, we redirect the users to GitHub, get the permissions and give you the access token which you can use in your applications to connect to GitHub. We give you relevant data at hand. So if you are using an API, maybe you get a ticket ID, you make a call to the server, get the ticket details, and then act upon it. Here all these things are set up for you. So notify ticket, if you want the ticket, details say payload.ticket, which we have already set up for you to use. You only write what your app needs to do, that's it. Everything else we take care of it in the platform. If your app needs to send a message to camfire, that's the code you have to write, nothing else. Other things are we take care of it. And we make it extremely easy for you to test it locally. So we have a console where you can, the same kind of interfaces rendered here, you can test all these locally. As we add more and more features, we are making, we are going to make sure this is strong. With, this is the same for at any level. If you're just having an API, you have a console as someone asked in the last session, you have a console for them to try out. If you have a platform, give them a console to try out all the things your platform can actually do locally. It has to run locally. So these kinds of things allows us to do stuff like this. This is Pratik Dhal, who is the founder of support me. He wrote an app in 49 minutes from zero code to deployment with screenshots and everything. In 40, 49 minutes, it allows the app platforms allows us to write an app, publish it in production and see it live being used by our customers. Just in 49 minutes. So it has become a competition in our company to time how much time it takes to write an app. Always we time it. This is the record which Pratik has now. But we are not stopping at this. Right now the platform is at this stage. We'll be soon adding storage for apps. So apps can store the data, their own data. For example, if you are creating a Jira integration of maybe support me, then you want to keep the ID of what ticket pertains to the ID of Jira, whatever issue or something. You can store it in the platform itself. You don't have to go and host it somewhere. And we might support webbooks for our platform. So app can be triggered by other applications. Not the core application, but just the app can be triggered. We have a bunch of stuff planned in future. There is a side effect because of what we have done with the app platform. But it was the premise with which we started and moved towards the app platform. It is we wanted to create a help desk software which is extremely usable. The only aim of support me is a usability. So if we are to cater to every customer support, customer out there, that 20% of features will add up to our interface and clutter everything. So what we did was we went the app platform way. If people want an app or want a feature, they will add it to their own desk and it doesn't clutter other customers desk. So that using that we end up at any time our interface is clean. It might not be the best designed app, but it has the best user experience when it comes to customer support. If you want to know more, you can go to developers.developer.supportb.com, or if not all the things which I've said here, we have already done it. So it's still work in progress. If you like to do something about it, you can go to career page and check it out or just contact me. Thank you. I have a question. So you were mentioning webhooks. Now webhooks are a brilliant idea, but they also disrupt the way developers tend to do development, which is normally you work completely offline or you work in a sandbox environment for your development and you can't do that anymore. Now your development setup, your laptop needs to be on the internet for the hook to work. So the question I had for you is one obviously use local tunnel to make this kind of thing work, but that still seems a little sub optimal to me because every time you start local tunnel you get a different address. Then you need to go reconfigure all your services to point here. And if you're using the same service for production, now you've got a problem because you can't take it off production. Then you need a separate account on your service. You use MailChimp or Centred or whatever. You're going to have a production account and a test account and you're probably paying twice. All of these issues start coming up with webhooks. So what should I take on that? So we cannot solve all the problems. Network problems are network problems. We cannot give a local tunnel or you have to root your request through a local tunnel or something like that. But when it comes to test accounts, we provide it for you for free, not yet, but it's the plan in a month where you can set up, in one click you can set up a developer account. It's not a production based account with data, dummy data with it, like Stripe does it. Stripe has dummy data if you want to go, if you go to the test mode. We are going to create a test support beheld us on which you can experiment on. It is a requirement. You can, I don't see how you can circumvent it and solve this problem if you have any ideas. Actually, so this is not a support-based specific thing, but what is your outlook on this test account business with other services? Like Twitter, for instance, no option but to make a test application. GitHub make a test application. But you don't have to make an account on the server. It's like Twitter, you can use your existing account and make a separate app and use that for testing. GitHub, you can do that too again. What is your outlook on, in general, what seems to be the way that people, the industry is doing this? So I have written a bunch of integrations in the last few months. Shopify does this well. Shopify also has something like Twitter and you can, using the existing account, you can add a test shop. Evernote sucks like hell. You cannot, we thought we can write that app in a day. It took like a week to complete. Just, it just sucks. Yeah, in general, from the integrations which I've seen and made, only maybe 10 to 12% have, 10 to 15% have this kind of a feature where using the existing account you can create a test account. I don't know what way we will take, but we have to wait and see. So, and the other part of it, the local tenant thing is also a little cumbersome. Have you seen people use web sockets instead? That your app makes a connection to the server and keeps that socket open until the server pushes something back. Interesting. Now that's part of the PubSubHubbub model of publishing block content. But I've not seen that happen elsewhere and I think it basically solves this problem very cleanly because you don't need a local tenant when you do something like that. Yeah, interesting. Thanks. Have you seen that anywhere? Let's open question because I've not seen it being done. I've not explored it, but it's a good thing to explore for sure. Go ahead. Hi, so, hello here. So you talked about hypermedia, right? And I think this is well debated in the community today. Everyone is talking whether we need it or not. But you talked about app developers being clients, like just like web users coming through the browser. But I'm trying to figure out what problem is hypermedia solving. It's nice to have it, but I'm trying to figure out what is the problem that hypermedia is solving. So initially, I was on the mindset, we were on the mindset of the way you're thinking, oh, it's not required. What is it solving? We are putting a link there. Or usually it slinks. So, but when we went ahead and built the app platform, now to minimize the communication between our core app and our app platform, hypermedia really helps. So for example, if you want to embed the link to a ticket in your app, which is not available in the API. Yeah, so I mean, I get that. But what I'm trying to say is, I'm trying to see if you're a developer, right? Let's say I'm building an app that talks to GitHub, it talks to Twitter, it talks to Facebook. Now, let's say all of these guys in an ideal world have hypermedia. But the thing is, they all probably have different implementations or different thought processes. So I still need to actually poke into the documentation. I cannot extract it in a completely automated fashion. So it still seems like a redundant effort. I mean, I'm trying to understand. Yeah, I think the way to solve it is follow the rest patterns. Like we follow the rest patterns for edit, create and stuff like that. So name the keys in the similar manner. So keep edit, or edit key always gives you the edit URL or edit URL gives you the... I don't know if there is a standard for this or something like that, but I think that's the way to go. If we do it, it's not like everyone is going to follow it, but if we do it, we'll do the rest. So are there any efforts to be standardized? Just think, are you aware? Okay, thanks. Just on that, there are several like Node.js projects that do try and consolidate all the different libraries in like a standard, or the different platforms or APIs in a standard way. So yeah, there's plenty of Node.js stuff out there which does that that I'm aware of, so. So my question is developing like APIs, like RESTful APIs. I know there's like API-ry is a great tool for being able to test them and document your APIs, but for code that we have to run, I know on the CoffeeScript website, they have some documentation that can run the code snippet. Do you know any tools that make that process of writing documentation for executing code easier? Because that seems like, that'll be really beneficial. We have not found out an open-source solution for to get something like Stripe, then I don't think we can get like, that's a one step ahead of that. So if we can get something like that, I think we can improve that code based on that. Does anyone know if there's something like that? Any work has been done on the API documentation, which in a way can fork and put your documentation in it? Okay. There's a tool that Mashry, which is acting another app platform. They have this open-source implementation called IoDocs. What you basically give it is a bunch of your API schema and it generates the whole console kind of thing, but it's not anywhere close to what Stripe is. I think it's somewhere in between. Yeah. You probably check out IoDocs. Yeah, sounds like APR a bit worse for like restrooms. APX plural kind of a thing. So yeah, there are services coming up like we're planning to make money on this documentation of APIs, but yeah, any open-source stuff? All right, cool. So I was trying to follow up on what you said. So the limitation was more from a consumer of these three services, say Facebook, GitHub, and that they might not have a consistent structure involved internally. So, and I think something like the wrapper, which you was talking about having, if we develop consistent wrappers, of course we don't have control over GitHub, but we have control over the wrappers and collaborate on that. That could be a... Yeah, but you end up with the same problem again. Like you are just... As a community, if you take them out of the equation, the service providers and then you write wrappers. Yeah. But they have no incentive to be consistent with Facebook. Actually I had one more thing to follow was with the web socket. So I think that takes one level down in the abstraction. So the advantage of an API is lost if you just have a socket hook coming back. Whereas if you go the rest way, I mean, when you're pulling, it's more of a structured API, but if you just open up a channel of talking back, we lose that advantage. It's almost like a function call with no structured callback. Okay, so wouldn't you, you know, even on your web socket, you still need structure to the data that's sent back and forth. So I'm assuming that you could still be sending JSON data with every packet that you send with a socket. You can't enforce it on the API is the concern. The thing I was wondering was, could you wrap an API in a socket so that instead of a hook, it comes back through an open socket? So yeah, just coming back to the hypermedia question which is being asked earlier. So I just wanted to elaborate a bit more on that. So it's more about self discovery that, okay, we have hit the first endpoint of the API and from this point on, what are your options to do? So it's like in a very brief example, if I have to tell, it's like, if you have three models and you create one model, model one, model two, model three in this order, you cannot direct end of the end hypermedia and when you create upon creation of model one, it tells you specifically, okay, the next step would be either edit model one or create model two because it kind of gives you an indication that you cannot jump to model three directly. So it's more of self discovery of the API. It's like a flow. So when you hit the first endpoint, what are your options next? You cannot directly jump to probably this. So that is the main use of- That's what makes an API at rest. Otherwise it's rest like, it's not rest. No, it's not like- So this is an addition to documentation. This is- No, you cannot quit on documentation. You have to read the documentation anyway. If the documentation is in the way of, how striped does it create? Even our documentation is not up to that level. We are constantly looking at it. Is auto discovery for people or for the programs? So when you mentioned auto discovery. For the programs. Yeah, so I've actually built a couple of rest interfaces, but it looks like a very big goal, like having something to write where you have programs that can auto discover APIs and then follow. Because I've never really not seen a single program which can actually look at- That's because most of the major APIs don't support hyper media. No, I mean- Is it- Everyone calls themselves rest, but no one is rest. Is there any example of a client which can give an API it can auto discover and then figure out? I mean, I see that it's- I mean, I don't see that as a possibility at all. In a month support, we will surely be like that. Okay. Because we require that. Because our structure is app platform, there's a core platform, there's an app platform, app platform needs to know stuff from the core platform. It's better to add hyper media than make one more call between the platform and the core application. I- I have a question. I actually came in late for the presentation, so I'm not exactly aware of all the context which we discussed, but to the point you're saying an API which gives you auto discovery thingy, so you can try WordNIC. API is a built-in swagger. They do that. WordNIC? So WordNIC is a platform in which you can search meanings and definitions of words and the usage and sample usage. Okay. And it's used by companies. So they build a swagger kind of thing. Swagger is open source, implementation of actually exposing APIs through a discovery URL and the library configures into object-oriented patterns in the UI, JS code. After that, you can actually, let's say you want to get a meaning of word. So you do WordNIC.getMeaning and pass the word so the API takes care of itself. So the API was built on fly. So if you follow that pattern, it actually helps you update your API documentations using that library swagger and the response JS and structures and everything automatically. Okay, thank you. But still you need to know that this is how the API is structured. It's not really auto discovery. So it's, no, the library swagger takes that WordNIC as the discovery URL and then builds the API automatically for you to use an UI. So your library builds based on the already-described URL as object-oriented pattern. But still I need to write a separate client for each application, right? No, no, no, no, no. So when you write your code, you just don't, you don't make calls to WordNIC URLs. You just do this.getMeaning, word.meaning. No, that's true, but still the same thing is, in the response, there could be like two, three different URLs. So if you see, for me in the hyper media, it looks like you're trying to imitate what we see in the browser. So when you click on a link, it gives back a page with a set of links and you can click on the link and follow that. If you look, the same thing, possibly... No, I think maybe we're not on the same page, but it would be a better discussion if you both actually, you look at it. Maybe we can get offline, maybe we can discuss it. Yeah, maybe we can take it offline. All right. I have a question. How different or similar is this to Pares? Pares.com? Pares is a service. But the API part sounds pretty much similar. What they do is they take your data and create a JSON web service or API that others can, like any of your applications can use. But they don't allow other, say you create an application on Pares. Your application is running on Pares backend. Can other developers, can you expose API so that other developers can build on that architecture? I don't really... I don't think so too. The main aim of this platform is you have a core application and you want people to build on it. Like add features, not just get data and post data. Add new features, new workflows. So how do you achieve that by keeping the core platform as simple as possible and making your API work? So and do something like a app platform so they can add features into the application. Thank you. Any other questions? Okay, I'll be around. Thank you.